The Broadcom renewal lands, the number is two or three times what you paid last cycle, and the clock is already running. Perpetual licences are gone, subscription is the only door, and the new bill is built on per core licensing with a 16 core per processor minimum that punishes exactly the dense, modern hosts you invested in. The instinct is to act fast and get out. That instinct is where most of the regret comes from.
A VMware exit is one of the few infrastructure decisions where moving quickly and moving well are usually in tension. The renewal gives you a deadline. The architecture gives you none of the shortcuts that deadline tempts you to take. So before you commit to a destination under pressure, it is worth being honest about what actually goes wrong, because the failures are predictable and almost all of them are avoidable.
The renewal clock is not your real deadline
The first mistake is letting the renewal date set the migration timeline. They are not the same thing. The renewal is a commercial event you can shape. The migration is an engineering programme that takes as long as it takes. When you fuse the two, you end up choosing a platform in weeks for a decision you will live with for years.
There is almost always a bridge. A shorter renewal term, a partial renewal that covers only the workloads you cannot move yet, or a negotiated extension buys you the months you need to migrate properly rather than the weeks the quote implies you have. We have seen organisations sign a one year renewal specifically to keep their options open, treating it as the cost of doing the move well rather than a defeat. Analyst reporting points to a meaningful share of VMware workloads moving over the next few years, which tells you the market is settling, not stampeding. You can take the time to be in the deliberate part of that curve.
The hypervisor is the easy part
The second mistake is scoping the project as a hypervisor swap. Replacing the layer that runs the virtual machines is genuinely the straightforward bit. The hard, slow, risky work sits everywhere else, and rushed projects discover it in the wrong order.
Data gravity is the obvious one. Moving the compute is quick. Moving terabytes or petabytes of data, with acceptable downtime and a tested rollback, is not, and it sets the real pace of the whole programme. Then there is disaster recovery. Your DR is almost certainly coupled tightly to the current platform, its replication, its runbooks, its recovery tooling. A new platform means rebuilding and, crucially, retesting all of it, and an untested DR is not DR.
Networking and firewall dependencies are the quiet killers. Years of rules, segmentation, load balancer config and integration points have grown around the existing environment, and much of it is undocumented in anyone’s head rather than on paper. Backup is the same story: your backup and recovery stack is wired into the current hypervisor through APIs and agents that may not exist on the destination. And underneath all of it sits the operational tooling, the monitoring, automation, patching and the runbooks your team runs on muscle memory. None of that transfers for free.
The pattern is consistent. The effort is driven by tooling, data and integration, not by the virtual machines themselves. Teams that learn this after they have committed end up either blowing the timeline or, worse, cutting the testing that the timeline no longer has room for. If you want the detail on how to sequence this properly, our guide on migrating off VMware walks through the phases and the dependencies in order.
Choosing a destination for the wrong reason
The third mistake is picking where you are going for a reason that will not age well. Under pressure, the decision often gets made on a single attribute. The platform a board member has heard of. The one with the cleanest demo. The one the incumbent reseller happens to push. The cheapest line on a spreadsheet that ignores migration cost and operational change entirely.
Nutanix, Azure Local and HPE are all credible destinations, and so are several others, but credible is not the same as correct for you. The right choice depends on your workloads, your team’s existing skills, your data, your regulatory position and your tolerance for operational change, not on which name carries the most comfort in a single meeting. A platform that is excellent for a Microsoft centric estate may be a poor fit for one that is not, and the reverse holds just as firmly. Choosing well means matching the destination to your reality, which takes assessment, not instinct.
Recreating the lock in you are trying to escape
Here is the subtle one. The fourth mistake is leaving VMware to escape lock in and walking straight into a new version of it. If you replace one proprietary stack you cannot easily leave with another proprietary stack you cannot easily leave, you have spent a fortune and a year of effort to change the name on the invoice, not your strategic position.
The question to ask of any destination is not only what it costs to move in, but what it would cost to move out again. Portability of your data, openness of the formats, the breadth of skills in the market, the realistic exit path in three years. If those answers are weak, you are buying your next renewal trap. The whole point of the exercise is to improve your leverage, and leverage comes from having real alternatives, not from swapping captors.
Skipping the parallel assessment
The fifth mistake is treating the decision as binary and sequential: decide to stay or go, then act. The stronger approach runs an alternatives assessment in parallel even when you fully expect to stay one more term. The assessment is not wasted effort if you stay. It is the very thing that gives you a credible walk away position at the negotiating table, and a credible walk away is what actually moves a renewal number.
It also surfaces the real blockers early, while you still have time to address them, rather than at the point where you are cornered and out of road. The organisations that come through this well are the ones that always know what their plan B is, in enough detail to act on it. That is also the honest test of whether staying is the right call: you can only know staying is right if you genuinely understood the alternative. Our decision framework on whether to leave VMware sets out how to weigh that properly.
What keeping leverage actually looks like
Pulling it together, the organisations that exit VMware without regret tend to do five things. They decouple the migration timeline from the renewal clock and buy a bridge if they need one. They scope the project around data, DR, networking and tooling rather than the hypervisor. They choose a destination by matching it to their own workloads and skills, not to the loudest pitch. They check the exit cost of the new platform before they sign, so they are not rebuilding the trap. And they run the parallel assessment whether or not they expect to move, because it is the source of every bit of leverage they have.
None of this is about leaving VMware, and none of it is about staying. It is about making the decision on evidence and on your timeline rather than the vendor’s. That is the difference between a move you are still glad you made in two years and one you are quietly unwinding. We helped a UK enterprise hold its Broadcom renewal uplift well under 80 percent against a projection that ran far higher, precisely by keeping that leverage and that optionality intact, and you can read how that played out.
The renewal will always feel urgent. Your architecture deserves better than a decision made to suit it.
If you want a quick sense of the numbers before you start, our free VMware Renewal Cost Calculator estimates your Broadcom renewal in your browser, with no sign up.