| It's a very scalable and almost fun task once you get into it. Alternatives to VMware can run VMware VMs almost immediately, by translating the configuration and with only a few (or sometimes no) changes to the guest. Usually those changes are scriptable. I've done it a few times, moving between VMware and KVM of Windows guests pretty much just worked; the rest was optimisation, i.e. guest driver changes, etc. Live migration is not realistic between different hypervisors, but a very short downtime per VM is realistic if the new hypervisor can adopt the old disk images directly, which some can. If you want, you can convert formats in the background while the VM is running on the new hypervisor. E.g. KVM and things built on KVM can do all these things. So to each guest, it looks like a quick reboot with a quick hardware upgrade. If that's coordinated properly, with a generic HA or Kubernetes setup, there's absolutely zero service downtime (if there are no serious mistakes), as it's just nodes within a cluster taken down one at a time while the others keep the services running, and state migrates among the nodes which are live. Most of the things you'll change when migrating are the same for large numbers of VMs that are configured the same way except for their disk images, and easily minor things like MAC/IP. So after you've verified a small number, you can go right ahead and script the migrations for another thousand VMs, even doing them in parallel. You don't need to migrate all VMs at the same time, and you shouldn't do that anyway. So the temporary hardware / cloud cost can be in the low single-digit percentage (for a few weeks to months at 40k VM scale, a few hours to days at 10 VM scale). You probably have some slack in there already, though, so might not need any additional hardware. |