RACK TRAIL
Solutions
VMware MigrationOpenStack at scaleProxmox at scalePrivate AICloud Cost OptimizationManaged Private CloudLarge Scale MigrationBig Data InfrastructureConfidential Computing InfrastructureCephKubernetes WorkloadsCloud Infrastructure for Startups
Why RacktrailGroundworkAbout Talk to an Engineer

Leaving VMware: what to settle before you choose where to go

In short. Most VMware exits choose a platform first and discover their requirements second. The evaluation gets run against a shortlist assembled from what is popular, and the actual constraints — renewal timing, compliance commitments, who can operate the result — surface later and invalidate the choice.

Preparation is not paperwork before the real work. It is the thing that determines which answer is correct. Six items, each of which eliminates options from your shortlist before you spend a day evaluating them.

The wrong decision first

The question arriving on your desk is “what do we move to.” It is the wrong question to answer first, and answering it first is why evaluations get re-run.

A shortlist built before requirements exist gets won by whoever demonstrates best. That is a fair test of a sales team and close to useless as a test of fit. Each of the six items below narrows the field on grounds that survive a demo — and several of them will eliminate a platform you were about to spend three months evaluating.

If you are further along and already governing a programme, the risks that decide whether it lands is the piece for that stage.

1. Start from the date you don’t control

Every migration plan should be built backwards from your renewal date. Most are built forwards from when the team can start, which is how programmes discover in month nine that the decision was made for them.

Two things make this harder than a calendar entry.

Drifting past the date has an explicit price. Distributor guidance indicates Broadcom applies a 20% surcharge on the first-year price for a late subscription renewal. Slipping a renewal while a migration finishes is a decision with a number attached, not an administrative delay.

In Europe, the ground moved underneath the question. Broadcom signalled termination of the VMware Cloud Service Provider programme in Europe in January 2026, effective 31 March 2026, removing all but a handful of hand-picked partners. CISPE filed a competition complaint with the European Commission in March 2026 and is seeking interim measures. If your VMware capacity is delivered through a European service provider rather than bought directly, your provider’s ability to sell you VMware is itself now a variable, and it is not one you or they control.

The terms have also proven changeable in both directions. Broadcom communicated a 72-core order minimum in March 2025 and retracted it by 10 April 2025, leaving the 16-core per-CPU minimum in place. Planning around a term that moved twice inside a month deserves a margin.

What this eliminates. If your renewal is inside twelve months and your estate is large, platforms requiring a long build are out for this cycle — and the choice becomes renewing once more deliberately, with a known cost, rather than discovering the deadline late. A planned bridging renewal is a legitimate strategy. An accidental one is a 20% surcharge.

2. Delete before you move

Migration cost scales with the number of workloads. So does the schedule, and so does the risk in every dependency you have to map.

A Stanford and Uptime Institute study of more than 16,000 servers found roughly 30% in a comatose state — no useful work delivered in six months, fully powered on. Industry estimates for idle or forgotten virtual machines run to 30–40% of enterprise estates. One organisation, shown the evidence, cut its zombie share from 30% to 8% inside a year.

Apply that to a migration and the arithmetic is uncomfortable. If a third of your estate does nothing, you are about to pay to map it, migrate it, test it, and then run it on the new platform. Every one of those is a real cost, and the last one recurs.

A migration is also the cheapest opportunity you will ever get to ask “should this exist.” Under normal conditions nobody has standing to switch off a server whose owner left in 2021. During a migration, everything has to be justified anyway.

What this eliminates. Nothing from the shortlist — but it can materially change the sizing you evaluate against, and sizing changes which platforms are economical. Running an evaluation against an estate a third larger than the one you will end up operating produces the wrong answer at the wrong price.

3. Find out what you have already promised

Somewhere in your organisation are commitments made to customers, regulators or auditors that depend on how infrastructure behaves. A published RTO or RPO. A segmentation control in a compliance attestation. A data location clause in a customer contract.

These are constraints, and constraints eliminate platforms. They are also frequently unknown to the infrastructure team, because they were made by sales, legal or compliance, and nobody wrote them down anywhere the platform team would look.

Data location deserves particular care, because residency and sovereignty are different promises and are routinely treated as the same one. If you have committed to the stronger version, several otherwise reasonable options are already out.

What this eliminates. Potentially a great deal, and early. A disaster recovery commitment you cannot meet without assembling third-party tooling is a cost and a risk that belongs in the evaluation, not in the first DR test after cutover.

4. Define what better means

“Off VMware” is a destination, not an objective. Four different objectives are usually bundled inside it, and they lead to different platforms:

Cheaper. Lower run-rate on comparable capability.

More agile. Self-service provisioning, an API, quotas — infrastructure consumed differently rather than administered differently.

More sovereign. Jurisdiction and operational control as a requirement rather than a preference.

More exitable. Never being here again.

These are not in conflict, but they rank differently, and the ranking decides the answer. Optimising for cost points somewhere different from optimising for exitability. A shortlist can only be evaluated against a ranking, and if you do not supply one, the evaluation will infer one from whoever presents most persuasively.

Write the ranking down before the first vendor conversation, and circulate it. It is the single cheapest thing on this list and the one most often skipped.

What this eliminates. Depends on the ranking — which is the point. If exitability ranks first, anything without a documented, contractual exit path is out immediately, and that is a short conversation rather than a three-month evaluation.

5. Be realistic about who will run it

The platform you choose has to be operable by the team you will have in eighteen months — not the team in the proposal, and not the team you intend to hire.

Three questions settle it. What can the current team run without external help? What is the hiring market for the skills the shortlisted platforms need, in your location and at your salary band? And if the person who leads this leaves in month nine, what happens?

The answers do not have to be flattering. They have to be accurate, because platform engineering is the largest recurring cost in an open infrastructure estate, and the difference between “we will hire” and “we have hired” is where business cases go wrong.

What this eliminates. Either some platforms, or the self-managed option entirely. If the answer is that you cannot staff it, that is not a failure — it means the real shortlist is of managed providers and vendor distributions, which is a different and much shorter evaluation than the one you were about to run.

6. Negotiate your next exit now

This is the item almost nobody includes, and it is the one your successor will care about most.

You are leaving VMware because leaving was hard and expensive. The mechanism was not technical: it was licensing terms that changed, a catalogue that collapsed into bundles, and pricing that moved by multiples. Whatever you choose next, the question that matters is what makes leaving it easier than leaving this one.

The moment of maximum leverage over any provider is before you sign. It is the only moment you will ever be able to negotiate an exit, and it is precisely when nobody wants to discuss one.

Four things to require in writing during evaluation, not after:

  • A named upstream distribution and version, so you know what you are running and could run it elsewhere
  • Configuration expressed as code you hold, rather than settings in someone’s portal
  • Data egress terms agreed in the contract at a rate, rather than referenced to a page the provider can change
  • A written exit process with formats and timelines — what you get back, in what shape, how quickly

A provider who will not put these in writing has told you something useful at no cost to you.

What this eliminates. Anything that will not answer. That is a faster and more informative filter than most technical evaluations, and it costs one email.

We publish our own answers to these because we would rather be measured against them: VMware migration.

What preparation costs

Weeks, not months, for most estates — and mostly the time of people who already have the answers rather than new work.

The dependency mapping is the exception and the item worth resourcing properly, because it is both the longest and the one that most often turns out to have been the difference between a programme that landed and one that slipped.

The reason to do this before the shortlist rather than during it is unglamorous: every one of these findings changes what you should be evaluating. Discovering a compliance constraint in month four of a six-month evaluation does not adjust the evaluation. It restarts it.

Where these numbers come from

The 20% late-renewal surcharge and the 16-core per-CPU minimum come from distributor and licensing-advisory reporting rather than from Broadcom’s published terms. Check them against your own contract before relying on either; your agreement governs, not an article.

The 72-core minimum announced and retracted in 2025 is well documented in trade coverage and is included as evidence that terms have moved, rather than as a current term.

Reported price increases vary enormously by source and by customer: Gartner has cited typical increases of 300–400%, CISPE reported 800–1,500% to the European Commission, and AT&T stated 1,050% in court filings. These describe different customers in different positions and should not be averaged. Use your own renewal quote.

The 30% comatose server figure is from a Stanford and Uptime Institute study of more than 16,000 servers. It is the most robust number in this article and also the oldest — treat it as an order of magnitude for your own estate rather than a prediction, and measure yours.

The CISPE complaint is a filed competition complaint, not a finding. No outcome had been reached at the time of writing.

If any of this is wrong or has moved, tell us and it will be corrected with attribution.

Frequently asked questions

Work backwards from your renewal date rather than forwards from when the team is free. For a large estate the preparation described here takes weeks and the programme itself can take considerably longer, so the renewal date is usually the binding constraint rather than technical readiness.

Sometimes, and it is a legitimate strategy when chosen deliberately with the cost understood. What is expensive is arriving at the renewal date without having decided, since distributor guidance indicates a 20% surcharge on the first-year price applies to late renewal.

Establish six things: your renewal date, which workloads should be retired rather than migrated, what you have already committed contractually or to regulators, how you rank cost against agility, sovereignty and exitability, who will operate the result, and what exit terms each candidate will put in writing.

Less than all of it. A Stanford and Uptime Institute study found roughly 30% of servers comatose, delivering no useful work for six months while fully powered. Migration cost and schedule scale with workload count, so retiring first is usually the highest-return preparation activity available.

It has. Broadcom signalled termination of the VMware Cloud Service Provider programme in Europe in January 2026, effective 31 March 2026, and CISPE filed a competition complaint with the European Commission in March 2026. If your capacity is delivered through a service provider rather than bought directly, their ability to supply you is a variable in your planning.

Negotiating the exit from the next platform while you still have leverage — a named upstream distribution, configuration as code you hold, egress terms in the contract, and a written exit process. A provider unwilling to commit to these in writing has answered a question worth asking.