Should You Leave VMware? An Honest Decision Framework
Since Broadcom changed the VMware commercial model, leaving has gone from unthinkable to a serious board level question. But the honest answer is not a slogan in either direction. For some estates staying is plainly right, for others leaving is overdue, and the difference comes down to a handful of factors you can actually assess. Here is the framework we use, vendor neutral, with no platform to sell you.
This is the question we are asked more than any other right now, and it usually arrives in a slightly panicked form. A renewal quote has landed that is two or three times the previous one, someone has read that everyone is leaving VMware, and the instinct is to treat exit as the obvious answer. It is not obvious. Leaving VMware can be the right move and it can be an expensive mistake, and which one it is for you depends on your estate, not on the headlines. So before you commit to anything, it is worth slowing down and deciding on evidence.
Start with the question behind the question
Almost nobody actually wants to leave VMware. What people want is to stop overpaying, to regain leverage, and to feel they are not trapped. Exit is one way to get those things, but it is not the only way, and it is rarely the cheapest or the fastest. So the first move is to separate the real goal from the assumed solution. If the goal is a defensible renewal cost, that may be achievable while staying. If the goal is genuine independence from a single vendor's pricing power over the next decade, that points more firmly toward exit. Naming the goal honestly changes the answer.
It also matters that this is no longer a neutral default. Before Broadcom, staying on VMware needed no justification. Now the commercial terms have moved enough that staying is a decision you should be able to defend, the same as any other. That does not mean leave. It means stop assuming, and decide.
There is no universal answer. Staying on VMware is the right call for a meaningful share of estates, and leaving is the right call for another meaningful share. Anyone who tells you confidently that everyone should leave, or that nobody should, is selling something. The work is in deciding which group you are in.
What actually changed, in one paragraph
Since Broadcom acquired VMware, perpetual licences have been withdrawn and subscription is the default. Licensing is now per physical core, with a minimum of 16 cores per processor, and you license every core in the server. The product has been consolidated into two bundles, VMware vSphere Foundation (VVF) and the fuller VMware Cloud Foundation (VCF). Version 9 adds a compliance reporting obligation, where failure to submit regular verified reports can degrade management functions and suspend support. The net effect for many is a renewal that costs far more for the same workload, which is what has put exit on the table at all. If you want the detail on the numbers, our renewal cost guide and the renewal calculator are the place to start.
The five factors that actually decide it
Strip away the noise and the stay versus go decision turns on five things. None of them on its own gives you the answer, but together they point clearly in most cases.
1. Estate size and the shape of your renewal
Large estates that already use the broad VMware stack tend to find staying more rational, because they are getting real value from the components they pay for and they have the scale to negotiate. Smaller estates, and estates with a lot of low core count or edge hardware, often see the sharpest percentage uplift and the least to show for it, which makes exit more attractive. The raw size matters less than the ratio of what you pay to what you genuinely use.
2. Feature use, honestly assessed
This is the factor people get wrong most often. The question is not what VMware can do, it is what you actually use. If you run core virtualisation and vSAN and little else, you are paying for a great deal of capability that never touches your workloads, and the case to either right size the bundle or leave is strong. If you genuinely use the networking, automation, Tanzu and hybrid management in VCF, the stack is earning its keep and leaving means rebuilding all of it elsewhere. Be ruthlessly honest here, because this single assessment moves the decision more than any other. Our VCF or VVF guide walks through mapping real feature use to the right bundle.
3. Renewal uplift, as a real number
Modelled increases under the new terms commonly land anywhere from 80 to 410 percent, but the figure that matters is yours, validated against your actual cores and entitlement rather than a vendor quote taken at face value. A 30 percent uplift on a fairly priced stack you fully use is a very different decision from a 300 percent uplift on capability you barely touch. Get the genuine number before you weigh it, because the quoted number is rarely the floor.
4. Risk appetite and operational maturity
Migration is real work and it carries real risk, most of it in the places people underestimate, data gravity, disaster recovery coupling, networking and firewall dependencies, backup interlock and operational tooling rather than the hypervisor swap itself. An organisation with strong platform engineering and a healthy tolerance for a managed project can absorb that. One that is already stretched, or that cannot afford disruption to critical services, should weight staying more heavily, at least for now. Honesty about your own capacity to execute is part of the decision.
5. Regulatory and contractual position
Regulated workloads change the maths. Running unsupported infrastructure is rarely acceptable for long, so if any of your estate is on an unsupported version, for example vSphere or vSAN 7.0, where general support ended in October 2025, stabilising that is urgent regardless of the bigger stay versus go call. Equally, some licences acquired through OEM or bundled constructs carry portability constraints that affect how cleanly you can leave. Know your contractual ground before you assume either path is open.
Who tends to be better off staying, and who leaving
No profile is destiny, but these patterns hold often enough to be a useful starting point. Find the one closest to you, then pressure test it against the five factors above.
Lean toward staying, done well
Large, stack heavy, feature rich estates
You run a broad VMware footprint, genuinely use the networking, automation and hybrid capabilities, and have the scale to negotiate. For you the work is not exit, it is right sizing VVF against VCF, negotiating the renewal hard, and handling the version 9 compliance obligation cleanly. Leaving would mean rebuilding capability you actually rely on. See staying on VMware, done well.
Lean toward leaving over time
Smaller, edge heavy or lightly featured estates facing a sharp uplift
You mostly use core virtualisation and storage, the renewal uplift is steep, and you are paying for a stack you do not touch. For you a planned exit to a destination such as Nutanix, Azure Local or HPE can be the stronger long term position. It is rarely a this year project, but starting the assessment now restores leverage. See migrating off VMware.
The architecture question underneath
VxRail and hyperconverged estates
If you run VxRail or another hyperconverged platform, there is a second decision beneath the VMware one: whether the fused compute and storage model still fits, or whether disaggregating to separate hosts and an external array would decouple your refresh cycles and step outside the vSAN tied portions of the licensing. See the VxRail guide and disaggregating from HCI.
Genuinely undecided
Mixed estates where the factors pull in different directions
Most organisations are here, and that is fine. The answer is not to guess, it is to run a short, evidence based assessment that establishes the real number and the real blockers, then split your workloads into hold, migrate later and evaluate for faster exit. You do not have to decide the whole estate at once.
How to decide, rather than guess
The mistake we see most is deciding the strategy before establishing the facts. The better sequence is to understand the reality first, then choose on evidence. This is the Decide stage of our IDEAL framework in practice, and it does not need to take long.
- Run an entitlement audit by cluster and by node, confirming core counts, version rights and who owns the support contract, so you know your true baseline rather than the quoted one.
- Assess feature use honestly, mapping what you actually consume against what each bundle includes, so you can tell right sizing from exit.
- Model the real renewal exposure under more than one scenario, then compare it against the genuine cost and risk of migrating, not a hand wave on either side.
- Stabilise anything unsupported as a priority, since that is urgent whichever way the larger decision goes.
- Start a parallel alternatives assessment even if you expect to stay, purely to restore negotiating leverage and surface the real blockers before a renewal corners you.
That sequence keeps control with you rather than the renewal clock, and it means that whatever you choose, you chose it on evidence. We have done exactly this for clients facing the decision, and the outcome is often better than either extreme suggested. In one engagement, independent audit and negotiation held a renewal uplift well under 80 percent against a figure that had been projected far higher, and bought a one year term that kept every option open. You can read that VMware licensing case study for how it played out in practice.
Doing nothing is a decision too, and not always a safe one. Letting a renewal auto process, or running on an unsupported version because change feels risky, quietly removes the leverage and the options you would want later. If you take one thing from this guide, let it be that the choice deserves to be made deliberately rather than by default.
Where to go next
This guide is the map. Each path below is the detail, written to the same vendor neutral standard. Start with the one closest to your situation.
- Staying on VMware, done well, if the broad stack earns its place and the task is to optimise and negotiate.
- Migrating off VMware, for the honest how of moving without breaking production.
- VMware to Nutanix and Azure Local as a VMware alternative, for two named destinations and where each fits.
- VCF or VVF, to map your feature use to the right bundle and stop paying for capability you never use.
- Disaggregating from HCI and the VxRail guide, if your real question is about the storage architecture, not just the hypervisor.
- The renewal cost guide and the renewal calculator, for the numbers, as a no signup first step.
Not sure which group you are in?
Tell us your situation and we will give you an evidence based view: where your entitlement actually stands, what the real renewal number is, and whether staying or leaving makes more sense for your estate. Independent, with no platform to sell and no preferred vendor. We have sat on the other side of the table.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
Should we leave VMware?
It depends on five things: your estate size and renewal shape, how much of the VMware stack you genuinely use, the real size of your renewal uplift, your appetite and capacity for a migration project, and your regulatory and contractual position. Large estates using the broad stack often do better staying and optimising. Smaller, lightly featured estates facing a sharp uplift often do better planning an exit. The honest first step is an evidence based assessment, not an immediate decision either way.
Is everyone really leaving VMware?
No. Analyst reporting shows meaningful workload movement and wide renewal increases, but that is not the same as everyone leaving. A large share of estates are staying and optimising, because for them the stack still delivers value and a negotiated renewal is cheaper than rebuilding everything elsewhere. The headline movement is real, but it does not tell you what is right for your specific estate.
How do I know if staying is the right call?
Staying tends to be right when you have a large estate that genuinely uses the broader VMware capabilities such as networking, automation and hybrid management, when you have the scale to negotiate, and when the cost of rebuilding that capability elsewhere would exceed the renewal. If you mostly use core virtualisation and storage and are facing a steep uplift, that points the other way. Mapping your actual feature use is the single most useful test.
What does leaving VMware actually involve?
Far more than swapping the hypervisor. The hard parts are data gravity, disaster recovery coupling, networking and firewall dependencies, backup interlock, storage replatforming and operational tooling. A realistic exit is a phased project of assessment, pilot, execution and closure, not a single cutover. Our migration guide covers the honest detail of doing it without breaking production.
Can I just stay on an old VMware version and avoid the new model?
Not safely for long. Running an unsupported version, for example vSphere or vSAN 7.0 where general support ended in October 2025, means no security fixes and no support, which is rarely acceptable for regulated or critical workloads. Doing nothing also quietly erodes your leverage and options. It is a decision, and usually not a good one.
Should we decide the whole estate at once?
No. The strongest approach is to split workloads into three groups: hold and optimise, migrate later, and evaluate for a faster exit. You can stay on VMware for the workloads where it still fits while moving others, and you do not have to commit the entire estate to one path. This keeps risk down and leverage up.