The pressure to leave VMware is real: subscription-only licensing has raised renewal costs for many organisations. But a rushed hypervisor migration can cause the outages that wipe out the savings. This is the wave-by-wave method we use to move VMs to KVM, on OpenStack or Proxmox, with a tested way back at every step.
Core toolvirt-v2v
MethodWaves by dependency group
Safety netVMware kept live until sign-off
Typical pace20 to 60 VMs per wave
See it working
A migration, one wave at a time
Each coloured square is a VM, grouped by application. Run the waves to see how related VMs are converted, tested side by side on KVM, and only then cut over. In wave 3 a test fails, and you will see what a rollback looks like.
Reference architecture
Source, target and the path between
Scroll sideways to see the whole diagram →Both environments run side by side for the length of the migration. Nothing on the VMware side is switched off until its replacement is signed off.
Part
What it does
Migration toolkit
An inventory (RVTools export plus dependency mapping), virt-v2v for conversion, and a simple tracker showing every VM, its wave and its status.
1 Conversion
virt-v2v copies each VM, swaps VMware drivers for virtio drivers, removes VMware Tools and registers the VM on the target. Windows and Linux are both supported.
2 Disk data
Disks are copied during conversion. Large VMs can be pre-copied and then synced in the maintenance window to keep cutover short.
Backup on both sides
The existing backup keeps protecting VMware. The new backup must already work on KVM before the first production wave.
The method, step by step
Inventory everything. Export from vCenter, then map which VMs talk to which. Converting VMs alphabetically is how migrations find unexpected outages.
Group into waves by dependency. An application's web, app and database VMs move together, so a cutover never splits a live dependency.
Build the target and its operations first. Monitoring, backup and automation for KVM must work before wave one, not after wave three.
Run a pilot wave. A few low-risk VMs prove the tooling, the drivers and the runbook.
Convert, test side by side, then cut over. Each wave is tested on KVM while the VMware copy is still live. Users move only after the application owner signs off.
Keep VMware as the rollback. Source VMs stay intact, powered off, for an agreed period after each wave.
Decommission last. Only when every wave is signed off is the VMware environment retired and its licences dropped.
What usually catches teams out
Drivers and boot. Windows VMs need virtio drivers before or during conversion, or they will not boot. Test every OS version you run in the pilot.
Network identity. MAC addresses usually change. Anything licensed against a MAC address, and any static DHCP reservations, will need attention.
Features you relied on. KVM platforms offer HA restart and live migration, but automatic load balancing like DRS is more limited. Plan capacity with some headroom.
Vendor support. Some appliances and commercial applications are only supported on VMware. Check before you plan their wave. A few may need to stay on a small vSphere island or move to public cloud.
Software licences. Moving to a new hypervisor can change how databases and some operating systems are licensed. Check the terms before cutover, not after.
Storage design. A one-to-one copy of your datastores is rarely the right target. Ceph and NFS behave differently from VMFS and vSAN, so design for them.
Typical tools
Stage
Common choices
Inventory
RVTools, vCenter exports, dependency mapping from network flow data
Conversion
virt-v2v (including direct output to OpenStack), Proxmox VE import wizard for ESXi, Migration Toolkit for Virtualization on OpenShift
Target platform
OpenStack on KVM, Proxmox VE, OpenShift Virtualization
Operations
Prometheus and Grafana, Ansible, backup software that supports your KVM platform
Send us a VM inventory export (RVTools is fine) and a line on what is driving the change. We will come back with a plain first view: what could move where, in what order, and roughly what it would cost to run.