Leaving VMware: the real alternatives, and how to migrate without breaking production

Broadcom completed its acquisition of VMware at the end of 2023. Perpetual licenses gave way to subscriptions, products were consolidated into broad bundles, and minimum billable thresholds went up. For a company quietly running two or three virtualized servers for the last decade, the invoice stopped bearing any relationship to actual usage.

Hence a question that keeps coming up: what do we move to, and how do we do it without breaking production. Here is the state of the ground, and the sequence that works.

First, the question to ask before leaving

Leaving on reflex is the mirror image of doing nothing, and it is just as expensive.

If your environment is heavily tooled around the VMware stack, with backup, monitoring, automation and written procedures all built for it, the real cost of exit sometimes exceeds the increase you are absorbing. This is not simply about moving machines: the whole chain has to be requalified, the operating procedures rewritten, and the team retrained.

So price the migration before deciding. That number does two things: it tells you whether leaving pays, and it gives you leverage if you choose to renegotiate instead. A renewal negotiated without a costed alternative in hand is not a negotiation.

The upheaval did produce one useful side effect. It forced a lot of organizations to ask a question they had never asked: what do we actually need? A meaningful number discovered they had been paying for years for high-availability features they never used. Start there, with an inventory of what you genuinely consume.

Why organizations are leaving

Three reasons come up, in this order, and only the first is financial.

The billing model changed: perpetual licenses became subscriptions, products were folded into broad bundles, and minimum billable thresholds rose. A company running a handful of virtualized servers ended up paying for a bundle sized for someone else.

The negotiating position changed with it. Where a renewal used to be a conversation, many teams now describe being handed a number. That is what pushes an infrastructure decision onto a finance agenda.

And the assumption of permanence broke. VMware had been the safe default for fifteen years. Once a safe default stops feeling safe, teams start pricing the alternatives even when they intend to stay. Most of the evaluations we see end in a renegotiation rather than a migration, and that is a legitimate outcome, provided the number behind it is real.

The credible alternatives, by family

The choice is not a ranking. It is a question of which operating model you are willing to hold. Three families, and the answer usually becomes obvious once you say out loud which one you can staff.

Classic hypervisors: you replace the layer, you keep the model

Proxmox VE. Open source, built on KVM (Kernel-based Virtual Machine) and LXC (Linux Containers), managed through a web interface, with an optional paid subscription for support and the stable repositories. Today it is the most common exit for small and mid-sized companies. It assumes you will either build the internal skill or hand the operations to someone. Watch out for a thinner third-party tooling ecosystem, and documentation that is partly community-written and therefore uneven.

Microsoft Hyper-V. A role in Windows Server, so often already covered by licenses you hold. It holds up well in a strongly Microsoft environment, with a directory in place and teams trained on those tools. Watch out for Windows licensing coherence, which deserves close checking before committing, because that is where the surprises live.

XCP-ng. Open source, Xen-based, usually managed through Xen Orchestra, with optional paid support. Relevant for targeted needs and teams comfortable at the command line. Smaller community, so fewer ready-made answers when something unusual comes up.

Integrated appliances: you buy the stack, someone else holds it together

Nutanix AHV (Acropolis Hypervisor). The hypervisor comes with the Nutanix platform, which combines compute, storage and networking under one vendor. Suits organizations that want one throat to choke rather than an assembly of parts. Watch out for a high entry cost, and for lock-in on the vendor’s stack that simply replaces the lock-in you are leaving.

Scale Computing HyperCore. An appliance model built around KVM, deliberately narrow in scope, aimed at small estates and edge sites with no one on-site. Watch out for the same trade-off in a different shape: simplicity bought by staying inside one vendor’s design.

Kubernetes-native: you change the model, not only the layer

Red Hat OpenShift Virtualization. Built on KubeVirt, it runs virtual machines next to containers on a Kubernetes platform. It makes sense when Kubernetes is already your center of gravity and the remaining machines are the exception. It is a poor fit when it is not: you would be adopting a platform to host machines that have no reason to live there.

OpenStack, including managed distributions. A private-cloud framework rather than a hypervisor. It fits large estates with a dedicated platform team, and it is a well-known way to hurt yourself without one.

The comparison, on the criteria that actually decide

None is better in the abstract. The deciding criterion is not technical, it is organizational: what can you operate, and what would you rather hand to someone else? A poorly monitored hypervisor with untested backups is more dangerous than a more expensive platform that is properly held.

What the migration actually costs

Four line items, three of them routinely underestimated.

Moving the machines. The visible one, and the simplest. Disk formats differ, but conversion tooling exists and works.

The drivers inside the guests. Changing hypervisor changes the input/output drivers the guest operating system sees. Every machine has to be opened, modified and restarted. Across thirty machines, that stops being trivial.

Requalifying the backups. The most dangerous item, precisely because it is invisible. Your backup tooling knows the old platform, not the new one. It has to be reconfigured, and then a real restore has to be tested. A successful migration whose backups no longer work is an incident that has not happened yet.

The operating procedures. Everything your team knows how to do becomes obsolete overnight: restarting a machine, adding disk, taking a snapshot, failing over to a degraded mode. Those runbooks need rewriting, and testing by someone who did not write them.

The sequence that works

Five steps, in this order, none skipped.

1. Inventory the real workloads. Not the machines, the workloads: what business role, what criticality, what depends on it. That inventory determines the target, not the other way round. Many migrations start from the choice of hypervisor, which is the surest way to discover mid-project that it does not fit.

2. Migrate one machine with no stakes, all the way to a restore. One machine, unimportant, but taken through the entire chain: cutover, monitoring, backup, then a tested restore. That machine validates the whole apparatus, not merely the technical feasibility.

3. Advance in waves, each with a rollback window. Each wave groups machines that depend on each other, and each has its rollback plan written before it starts. The question it answers: how do we return to the previous state, in how long, and what data is lost.

4. Requalify the backups before calling it finished. This is a milestone, not a closing formality. Until a restore has been tested on the new platform, the migration is not done, even if every machine is running.

5. Rewrite the procedures and retrain the team. The last milestone, and the one sacrificed when the schedule has slipped. Sacrificing it means creating a dependency on whoever ran the migration.

The trap of running this alongside the day job

A hypervisor migration needs sustained attention and intervention windows. Handed to an internal team already holding the daily load, it stretches, and a stretched infrastructure project accumulates intermediate states: part of the estate migrated, part not, two platforms to monitor, two sets of procedures. That is the riskiest configuration there is.

If the internal bandwidth to do this in one push is not there, it is exactly the kind of work to hand to someone on a bounded scope. That is what our legacy modernization engagements exist for.

Further reading

• Legacy modernization: the engagement format for a bounded migration
• Fractional CTO: when the decision itself needs someone senior on your side
• Technical due diligence: pricing the options before committing a budget
• Modernize or renegotiate: price the exit first: the decision above this one
• Fractional CTO vs interim vs consultant: who should hold this call
• Forty-seven alerts one morning, forty-three of them false: what a status check never sees after a migration
• Self-hosted model or vendor API: the same hosting calculation, applied to AI