Most shortlists start with hypervisors and end in a surprise, because the hypervisor was never the expensive part. This guide works through what a VMware replacement actually has to cover, the routes teams genuinely take, and the questions that decide between them.
Where we stand: edgeContinuum runs on OpenStack, so the route we build for is open infrastructure with a managed layer on top. The other routes are described here because a shortlist you cannot trust is no use to you, and because knowing why one fits tells you a lot about whether ours does.
The phrase hides two very different projects. One is replacing a hypervisor: you run ESXi, you want something else to run virtual machines on the same servers. The other is replacing a platform: you run ESXi plus vCenter plus Tanzu plus NSX plus vSAN, and your teams consume all of it as one thing.
The first project is a weekend for a small estate and a well-trodden path for a large one. The second is where budgets and timelines go wrong, because the bundle quietly supplied capabilities nobody wrote down. Broadcom's shift to bundled per-core subscriptions has pushed a lot of organizations into the second project while they were still costing the first.
So the first thing worth doing is deciding honestly which one you are in. If vCenter was a convenience and one team ran everything, a hypervisor swap may genuinely be the whole job. If several teams self-served, if you billed anyone internally or externally, or if Kubernetes came from Tanzu, you are replacing a platform, and the shortlist has to be judged on that basis.
Before comparing products, write down what is actually in your entitlement and, separately, what you actually use. These are rarely the same list, and the gap between them is the cheapest saving available.
Two questions against each line. Who consumes it, an operator or a development team? And if it disappeared next quarter, would you rebuild it, buy it, or discover you never needed it? Anything nobody would rebuild is a saving, not a requirement, and it should not appear in a comparison.
The most direct route: something else runs your virtual machines on the same servers. Five candidates come up consistently.
OpenStack is the one most estates of any size end up on. Nova with KVM replaces ESXi directly, on the hardware you already own, and Cinder speaks to the SAN and NVMe arrays already under it. It is open source with no licence meter, and unlike everything else on this list it does not stop at the hypervisor: the same platform brings multi-tenancy, regions and an API that automation can rely on. Its cost is operational rather than financial, which is what option 3 is about.
Proxmox VE is the one small estates shortlist most often: KVM and LXC, clustering, live migration and backup, no licence cost. XCP-ng is the Xen equivalent, with Xen Orchestra as its management pane. Hyper-V is worth considering only if you are already committed to Windows Server and System Center. Nutanix AHV keeps the polished, integrated experience closest to vSphere, at the cost of remaining on a vendor-controlled stack licensed per node, which is frequently the property being escaped.
Those last four share a ceiling, and it is why this route stalls for larger estates: they replace the hypervisor and nothing above it. Multi-tenancy stays shallow, quotas do not hold across teams, managed Kubernetes and databases are not part of the offer, and several sites means several installations to operate. If your estate outgrows one cluster, or anyone outside the infrastructure team consumes it, you will be having this conversation again within a year. Our Proxmox and Nutanix pages set out exactly where each stops.
If most of your roadmap is containerized, running virtual machines as Kubernetes objects is coherent. OpenShift Virtualization is the mature expression of it, and the Tanzu successors point the same way.
Two things to weigh. First, your virtualization layer inherits Kubernetes' upgrade cadence, which is a real operational change for teams used to long-lived VM estates. Second, per-core pricing tends to follow, which means workloads that are not containers at all are billed on a container platform's meter. If your estate is mostly legacy VMs with a container programme alongside, this route often costs more than it saves. Our OpenShift alternative page works through the economics.
OpenStack is the only option on this list designed from the start for multi-tenancy and multiple sites, and it runs on the servers and storage arrays you already own. That is why it keeps appearing in serious exit plans: it replaces the platform rather than just the hypervisor, and nothing about it is vendor-controlled.
Its well-known cost is operational. The primitives are excellent, and the layer your teams actually touch is yours to build: a self-service experience, managed services, a tenancy model, and the day-two automation behind all of it. Deployments that stall stall here, not on capability.
That gap is the specific thing edgeContinuum closes. The platform sits on the OpenStack you operate, connected through its standard APIs, and adds what the VMware bundle used to supply:
Three properties matter for a VMware exit specifically. Nothing is forked, so your OpenStack stays standard and your operators keep Horizon and their existing tooling. Pricing is a subscription per managed resource rather than per core or socket, so consolidating onto denser hosts reduces cost instead of raising it, which is the opposite of the arithmetic you are leaving. And the same platform runs from a hosted control plane to a fully air-gapped site, so sovereignty requirements do not force a different product later.
This is the route to weigh when you are replacing a platform rather than a hypervisor, and particularly when several teams or external clients consume the infrastructure. OpenStack vs VMware compares the two operating models directly, and the VMware alternative page maps each piece of a vSphere estate to what it becomes.
Worth stating plainly because it is sometimes right. Lifting VMs into a hyperscaler removes the infrastructure question entirely, and the managed VMware offerings make the move mechanically easy.
It is usually the wrong answer when data residency, latency to physical sites, or steady-state cost dominate. Predictable always-on workloads are the case public cloud serves worst economically, and they are exactly what tends to be sitting on a mature vSphere estate. Sovereignty requirements frequently rule it out before cost does.
This is the part missing from most shortlists. Swap ESXi alone and four things quietly become your problem.
None of these is a reason to stay on VMware. They are the difference between a comparison that holds up in month six and one that does not.
Who provisions? If the answer is an administrator handling requests, a hypervisor with a good console is enough. If teams should serve themselves within limits you set, you need a platform, and that decision eliminates most of the list immediately.
How many tenants, really? Count teams that need genuine isolation and separate quotas, and count external clients as tenants twice over. One tenant makes Proxmox or XCP-ng viable. Several makes multi-tenancy a hard requirement rather than a feature comparison.
Where does Kubernetes come from afterwards? If Tanzu supplied it, something must replace it, and "the team will run upstream Kubernetes" is a staffing commitment rather than a plan. Decide whether clusters are a product you consume or a system you operate.
What does the meter count? Per-core and per-socket licensing punishes exactly the consolidation that makes virtualization efficient. Check what happens to the bill when you double a host's cores, and whether the model changes if you later go air-gapped.
How many sites? One data centre is a different problem from twenty edge locations. If sites must keep running when the link drops and resync afterwards, most of the shortlist never supported that and the requirement should be stated up front.
Exits that work run in waves and keep both stacks live for a while. A workable shape: stand the new platform up beside the existing estate on a small hardware footprint; move a low-risk, well-understood workload group first and let the team learn on it; sequence the remaining waves by renewal pressure rather than by technical tidiness; redeploy Tanzu workloads onto standard CNCF clusters when their turn comes, which is straightforward because conformant clusters take your existing charts and operators unchanged; and leave single-instance legacy systems that need long change windows until last.
Budget explicitly for the parallel-running period. It is the line most business cases omit and the one most likely to be quoted back at you. The VMware to OpenStack migration guide covers the execution phases, and the VMware alternative page covers what each piece of a vSphere estate becomes.
Managed Kubernetes, PostgreSQL and VMs on open infrastructure you own, priced per managed resource instead of per core. Bring your inventory and your renewal date, and our engineers will map your vSphere estate onto it.
