When Broadcom closed its VMware acquisition and moved the portfolio to subscription-only, per-core bundles, it turned a stable line item into an open question for a large share of vSphere customers. The renewal quotes that followed, widely reported at three to ten times prior spend, are what put “migrate off VMware” on so many roadmaps. But the right destination is not the same for everyone, and picking on price alone is how migrations go sideways.
The five credible destinations, and who each suits
Proxmox VE is the most common landing spot for small and mid-size estates. It is open source, KVM-based, and has mature clustering, HA, and its own backup server. The trade-off is that it is community-first: you are trading Broadcom’s invoice for your team owning more of the operational stack, with optional paid support if you want a safety net.
Microsoft Hyper-V makes sense when you are already Windows Server Datacenter-licensed, since Datacenter grants unlimited Windows VMs on the host. It is a known quantity for Windows-heavy shops, though it pulls you deeper into Microsoft licensing rather than out of vendor subscriptions entirely.
XCP-ng (with Xen Orchestra) appeals to teams that want a turnkey, support-backed open platform with a management experience closer to vCenter. Nutanix AHV is the lowest-effort commercial path, a polished HCI platform, but it is a subscription too, so model whether the TCO genuinely beats a renegotiated VMware deal. OpenStack is the heavyweight option: maximum control and zero licensing, but a real platform-engineering commitment that only pays off at scale.
How to actually decide
Start with estate size and in-house skills, not the hypervisor feature matrix. Count your physical cores (vSphere licenses cores, not VMs), get a real renewal quote, and model three-year TCO for two or three candidates using the calculator on each path page. Then weigh the softer factors: how much re-architecture your storage and networking need, whether you require a support SLA, and how much operational load your team can absorb.
The costs that do not appear in the hypervisor comparison
Most VMware exit business cases compare licence cost against licence cost and then get surprised. The hypervisor is rarely the expensive part of leaving; the ecosystem around it is. Four items account for most of the overrun.
Backup. Your backup product is licensed and configured for vSphere, and its VMware integration is usually the deepest integration you own. Check whether your existing licence covers the destination platform at all, and at what tier, before you assume backup is a solved problem. For some estates the backup re-platforming is a larger project than the hypervisor migration.
Networking. If you run NSX, you are not migrating a hypervisor, you are migrating a software-defined network as well, and micro-segmentation policy does not export cleanly to anything. Estates using standard or distributed switches have a far shorter path than estates with a mature NSX deployment, and the difference is measured in months.
Operational tooling. Monitoring templates, automation that calls vCenter APIs, capacity reports, patching workflows, and the runbooks your on-call team has memorised all assume vSphere. None of it is hard to rebuild individually, and all of it takes longer in aggregate than anyone estimates.
Third-party certification. Some commercial software is formally supported only on specific hypervisors. It is worth asking each critical software vendor the question directly and in writing, because discovering a support-matrix problem after cutover is an expensive way to learn it.
When renewing is the better decision
Leaving is not automatically correct, and a tool that only ever said “migrate” would not be worth trusting. Renewing, ideally on a shorter term, is often the better call in three situations.
If your renewal is inside six months and your estate carries real blockers, the honest comparison is not migration against renewal, it is a rushed migration against a renewal plus a properly planned migration next year. The second usually wins on both cost and risk.
If your estate is small, the licence saving may simply not justify the engineering time. A dozen hosts is a different proposition from three hundred, and the migration effort does not scale down proportionally.
And if your team has no Linux depth, moving to a platform that assumes it is a hiring and training decision wearing a technical costume. That can absolutely be the right decision, but it should be made deliberately, with the training budget attached, rather than discovered afterwards.
A credible migration plan also improves your negotiating position materially, which means the work is rarely wasted even when you decide to stay. Every path below opens to a full cost model, a phase-by-phase plan, and an in-depth guide for that specific move.