Broadcom’s VMware repackaging turned hypervisor licensing into one of the most scrutinized line items in IT. If your workloads are “just VMs”, Linux and Windows guests without deep dependence on NSX, vSAN, or SRM, the premium stack is often hard to justify, and several mature alternatives exist.
Where teams usually land
- Proxmox VE, open source, KVM-based, with built-in clustering, ZFS/Ceph storage, and an integrated backup server. The most common destination for small/mid estates.
- Nutanix AHV, turnkey HCI with the agentless Nutanix Move migration tool; strong if you want a commercial, appliance-like experience.
- Microsoft Hyper-V, natural fit for Windows-heavy shops already licensing Datacenter.
- XCP-ng / Oracle Linux KVM / Harvester / OpenStack, open options for specific needs (Xen, Oracle stack, Kubernetes-native, or private cloud).
Map the concepts first
vCenter has no 1:1 twin, most open targets are peer-to-peer clusters. DRS-style automatic load-balancing usually isn’t present (you place/migrate VMs manually). vSAN maps to Ceph or ZFS replication; distributed switches map to Linux bridges/VLANs or SDN; vSphere HA maps to each platform’s HA manager with fencing/quorum. Decide your storage model early, it drives the migration mechanics.
Some vSphere features have no clean equivalent on any target and need a rebuild rather than a migration: NSX overlays and the distributed firewall become VLANs plus host or perimeter firewalls, SPBM storage policies become a deliberate storage layout, and Fault Tolerance becomes application-level clustering because open targets offer HA restart, not lockstep availability. Catalog these dependencies before you pick a target, because they often decide which target fits.
Importing VMs and the steps people forget
Most targets now offer a built-in VMware importer (Proxmox 8.2+ ESXi import, Xen Orchestra V2V, Nutanix Move). The universal fallback is disk conversion: power off or snapshot, then qemu-img convert/virt-v2v, attach to a new VM, and boot. The steps teams forget are the post-import ones: remove VMware Tools, install the guest agent/VirtIO drivers (slipstream Windows VirtIO drivers before switching to virtio-scsi or the guest won’t boot), and fix NIC/MAC/IP.
Counting cores, and the ownership trade
vSphere licenses physical cores (16-core/CPU minimum); open targets are free with optional per-socket support. Size hosts on physical cores and workloads on the VMs they run. Most teams see a sharp TCO drop and trade it for more operational ownership, plan for the learning curve and, if you need it, buy a support subscription.
Preserve the source, migrate in waves
Run a pilot wave end-to-end (import → drivers → validate → backup/restore → HA failover), document the runbook, then repeat wave-by-wave keeping each source VM intact through hypercare. Stand up your new backup target (e.g. Proxmox Backup Server) early and keep old backups read-only until retention ages out.
The single most important de-risking habit is preserving the source. Because most modern importers copy rather than move a VM, the original stays on vSphere until you delete it, which makes rollback as simple as powering the source back on. Do not delete anything on day one. Only decommission a source VM after its OpenStack, Proxmox, Hyper-V, XCP-ng, or Nutanix copy has passed acceptance and survived a hypercare window. Update DNS, monitoring, and backup jobs to point at the new copy only after cutover, and reclaim the freed vSphere hosts into the new cluster once they are empty so the old estate becomes headroom for the next wave.
Use the calculator and per-path guides on each migration page to model your own numbers and get the exact command-level runbook.