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.
Choosing a target
- 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.
Migration mechanics
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.
Sizing & cost
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.
De-risking
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.
Use the calculator and per-path guides on each migration page to model your own numbers and get the exact command-level runbook.