If your VMware exit strategy begins when you receive an unacceptable renewal quote, you've started too late.
By that point, the commercial conversation is already being shaped by something more powerful than the price on the quotation: time. Your workloads are still running, the applications they support still matter, your support arrangements still have an expiry date, and the business quite reasonably expects its infrastructure to continue working while procurement argues about licensing.
You can tell Broadcom that you're considering alternatives. You can tell them that Nutanix is knocking on the door, that Microsoft has an attractive proposition, or that somebody has built an impressive Proxmox proof of concept. But unless those alternatives have progressed beyond PowerPoint, everyone around the negotiating table knows that replacing a mature virtualisation estate is not something you do between receiving the final renewal offer and the contract expiring.
This is why I think many organisations are approaching the VMware pricing problem from the wrong direction.
The objective shouldn't necessarily be to leave VMware.
The objective should be to make leaving VMware a credible option.
That may sound like a subtle distinction, but commercially and strategically it changes almost everything.
The pricing controversy is real, but it shouldn't become the strategy
There has been no shortage of anger since Broadcom acquired VMware. Customers have reported significant increases in licensing costs, changes to packaging have altered the economics of existing estates, and the move away from the old perpetual-licensing model has forced organisations to reconsider infrastructure assumptions that had remained stable for years.
Recent research involving 300 VMware-using organisations found that 90% said higher licensing costs had caused them to explore alternatives. More interestingly, 60% were considering multi-hypervisor strategies rather than simply replacing VMware with a single new platform. Operational complexity, however, remained one of the largest barriers to change.
That tells us something important about the current VMware debate. There is a considerable difference between wanting an alternative and possessing one.
It is also worth separating the commercial argument from the technology. Broadcom's current VMware Cloud Foundation and VMware vSphere Foundation licensing is based around physical CPU cores on licensed ESXi hosts, including a minimum of 16 licensed cores per physical CPU. That can create materially different economics from the licensing assumptions under which some existing VMware environments were designed.
None of this means VMware has suddenly become bad technology.
VMware became entrenched in enterprise infrastructure because it solved difficult problems extremely well. Over decades, organisations built operational knowledge, automation, disaster recovery, backup, networking, security, monitoring and hardware ecosystems around it. That accumulated maturity has value, even if it doesn't appear neatly as a line item on a licensing comparison.
Some VMware partners have consequently reported customers negotiating acceptable contracts and deciding that the broader capabilities of VMware Cloud Foundation still justify remaining on the platform. They also make the reasonable point that replacing the hypervisor does not necessarily replace everything surrounding it.
A CIO therefore shouldn't migrate a stable infrastructure estate because they're angry with Broadcom. Equally, they shouldn't accept an unattractive commercial arrangement because migration looks difficult.
Both responses allow emotion to substitute for strategy.
The proper question is whether VMware still represents the best technical and economic platform for the workloads the organisation actually intends to operate over the next several years.
You cannot answer that objectively if staying is your only realistic option.
Before negotiating VMware, understand how much VMware you actually need
The first stage of a serious renewal shouldn't happen in procurement. It should happen inside the infrastructure estate.
I would want a current and forensic inventory of the VMware environment: hosts, physical cores, clusters, hardware lifecycle, storage, vSAN, NSX, vCenter, backup, replication, disaster recovery, network dependencies, operating systems, utilisation, application ownership, business criticality and growth assumptions.
More importantly, I would want to know why every workload is still there.
Virtualisation made creating servers extraordinarily easy. Enterprises became considerably less disciplined about removing them. The result in many mature estates is an archaeological record of previous projects: development systems that quietly became permanent, applications awaiting retirement, duplicate services inherited through acquisitions, machines retained because nobody is quite sure what will happen if they're switched off, and oversized VMs carrying resource allocations that bear little relationship to what they now consume.
The change in VMware economics makes that inefficiency commercially relevant.
Where licensing is related to the physical cores of the underlying hosts, infrastructure design, hardware configuration and software economics become directly connected. The architecture that made perfect sense under one licensing model may not be the architecture you would design under another. That doesn't mean replacing functioning servers purely to optimise licensing, but it certainly means taking the economics into account when hardware is refreshed and clusters are redesigned.
This is also why I wouldn't begin a renewal by asking how much discount Broadcom is prepared to offer.
I'd begin by determining how much VMware the organisation genuinely needs.
There is little value negotiating a wonderful discount on capacity you shouldn't be licensing in the first place.
Last year's invoice is not your business case
Another common mistake is to turn the renewal into a percentage argument.
Last year's contract cost X. The new proposal costs considerably more than X. Procurement therefore sets itself the objective of moving the new number as close as possible to the old one.
That's understandable, but it can produce the wrong comparison. The licensing model may have changed. The infrastructure has probably changed. The product bundle may be different. Some capabilities may now be included that were previously purchased separately, while other parts of the bundle may have no value whatsoever to your organisation.
I would build at least three economic models before entering a serious negotiation.
The first is the cost of remaining on VMware with the estate substantially as it exists today.
The second is the cost of an optimised VMware estate. That means removing unnecessary workloads, consolidating where appropriate, right-sizing infrastructure, incorporating planned hardware refreshes and determining whether capabilities included in the VMware proposition can genuinely replace products being purchased elsewhere.
The third is the cost of leaving.
All three should cover the same multi-year period. Three years may be appropriate in some organisations; five may reveal the economics more clearly in others. What matters is that the comparison is consistent and includes more than software licences.
The optimised VMware model is particularly important because bundling can distort the conversation in both directions. It is unfair to treat a broader platform as though the only thing being purchased is a hypervisor if the organisation genuinely consumes the additional capabilities. But it is equally wrong to assign strategic value to features simply because they are included.
Shelfware doesn't become strategic value because it arrived in a bundle.
The cost of leaving VMware is not the cost of another hypervisor
This is where some otherwise compelling migration business cases fall apart.
A competing platform can appear dramatically cheaper when the comparison consists of VMware licensing on one side and alternative-hypervisor licensing on the other. But an enterprise virtualisation platform rarely exists in isolation.
The real comparison needs to incorporate backup, disaster recovery, cyber recovery, monitoring, automation, storage, networking, security controls, capacity management, hardware compatibility, support, operational tooling and the people required to run it.
Existing automation may need rewriting. Monitoring integrations may need replacing. Backup architectures may change. Disaster-recovery procedures need testing again. Security tooling has to work with the target environment. Operational teams need training. Application owners need to validate their systems. For a period, both environments may need to operate simultaneously.
That coexistence period is particularly easy to underestimate. Migration programmes often create a temporary peak in cost because the organisation is paying for the old platform, building the new one and funding the transformation at the same time.
VMware partners have understandably emphasised these costs when defending the economics of remaining on VMware. Their commercial interest is obvious, but the underlying argument is still valid: an integrated platform can carry value that disappears from simplistic licence comparisons.
The answer is not to assume VMware will therefore prove cheaper. It is to make both sides of the business case equally honest.
If the alternative remains economically compelling after migration, skills, tooling, coexistence and operational costs have been included, you have a real business case.
If it doesn't, you have discovered something equally valuable before disrupting the estate.
Don't replace VMware with VMware wearing somebody else's logo
Once an organisation decides to evaluate alternatives, there is a temptation to ask which product should replace VMware.
I think that's the wrong question.
The more useful question is what should happen to the workloads currently running on VMware.
A mature estate will almost certainly contain several different answers, and I would classify them broadly into five groups:
Retain → Reduce → Replace → Replatform → Retire
Some workloads should remain on VMware because application certification, operational dependencies, risk or economics make that the sensible answer.
The VMware footprint itself can then be reduced through consolidation, right-sizing and removal of unnecessary capacity.
Other workloads can be replaced relatively conventionally by moving the virtual machine onto another virtualisation platform.
Some should be replatformed. A forced infrastructure review can be the catalyst for moving an application towards containers, PaaS, public cloud, SaaS or a more modern architecture rather than simply transporting its VM elsewhere.
And some systems should finally be retired.
This distinction matters because success shouldn't be measured by recreating the current VMware estate somewhere cheaper.
If an organisation has 4,000 VMware VMs today, the strategic destination doesn't necessarily need 4,000 VMs on a different hypervisor. It may need 1,200 remaining on VMware, 1,500 on another virtualisation platform, 500 replatformed, 300 replaced by SaaS and 500 removed entirely.
That is infrastructure transformation.
Moving all 4,000 VMs unchanged is primarily relocation.
The alternatives are viable, but they solve different problems
There are now enough credible alternatives that CIOs should reject the idea that VMware is impossible to leave. But that doesn't mean there is a single obvious successor.
Nutanix AHV is an understandable candidate for organisations wanting to preserve much of the integrated enterprise virtualisation and HCI operating model. It has mature enterprise positioning, established support and an obvious commercial incentive to make VMware migration straightforward. For organisations whose primary objective is to change platforms without simultaneously reinventing infrastructure operations, that can be attractive.
Microsoft presents a different proposition. A heavily Microsoft-oriented organisation may already possess much of the required knowledge, commercial relationship and management ecosystem. Hyper-V remains relevant, while Azure Local provides Microsoft's hybrid infrastructure model. Microsoft also provides migration tooling through Azure Migrate for moving VMware workloads to Azure Local, with discovery, replication and migration orchestrated through Azure while VM data remains on-premises during the migration process.
That doesn't make Azure Local a drop-in VMware replacement. Its architecture, Arc integration, networking, storage, management and migration constraints need to be understood on their own terms. Microsoft's own documentation identifies prerequisites and limitations that need to form part of the evaluation rather than appearing halfway through a production migration.
Red Hat OpenShift Virtualization becomes more interesting where the VMware discussion forms part of a broader application-platform strategy. Red Hat supports migration of VMware workloads through its Migration Toolkit for Virtualization, including cold and warm migration approaches subject to the relevant prerequisites.
For an organisation already investing in OpenShift and seeking greater convergence between virtual machines and containerised applications, that can be strategically attractive. For an organisation with no Kubernetes strategy, limited OpenShift skills and no intention of changing its application operating model, introducing OpenShift solely to escape VMware pricing could add more complexity than it removes.
Proxmox VE deserves a more serious place in enterprise evaluations than it would have received several years ago. Its KVM-based virtualisation, clustering capabilities and comparatively straightforward commercial model make it understandably attractive in the current market. But enterprise adoption should be based on evidence rather than either enthusiasm or prejudice. Support expectations, ecosystem depth, backup and DR, automation, security integration, hardware relationships, management at scale and internal skills all need testing against the organisation's actual requirements.
A technically capable platform can still be the wrong operational platform for a particular enterprise. Equally, a platform shouldn't be excluded simply because its logo hasn't historically appeared alongside VMware in large-enterprise procurement exercises.
Then there is public cloud, which is often presented as though it were simply another destination for virtual machines. It isn't. Public cloud changes the infrastructure consumption and operating model. Where workloads benefit from elasticity, managed services, geographic reach or genuine application modernisation, that can create substantial value. Moving a static VM unchanged into a hyperscaler and running it continuously may instead preserve most of the architectural debt while exchanging one cost model for another.
There is also a less dramatic option that deserves consideration: retaining VMware technology through a managed or service-provider model rather than continuing to operate the entire platform internally. For workloads that are difficult to migrate, this may provide a bridge while changing the commercial or operational relationship.
None of these platforms therefore “wins” the VMware replacement contest.
There shouldn't be a contest.
The correct destination depends on the workload, the organisation's strategic architecture, existing skills, risk tolerance and the operating model it actually wants to build.
A proof of concept is both a technical exercise and a negotiating asset
This is the point where an exit strategy begins to change the commercial conversation.
Every enterprise software vendor has heard a customer say that a renewal is too expensive and alternatives are being considered. Procurement teams are expected to say it. Vendors discount accordingly.
The conversation becomes different when the alternative has been tested.
A credible exit programme should have classified the estate, identified the workloads suitable for migration, selected realistic target platforms and validated representative workloads. Backup should have been tested. So should disaster recovery, networking, security, monitoring and operational support. Migration tooling should be understood, and the organisation should know roughly how quickly a migration factory could move workloads once the decision is made.
At that point, the organisation no longer has a theoretical alternative.
It has a BATNA — a genuine best alternative to a negotiated agreement.
Perhaps the analysis concludes that 35% of the estate should remain on VMware, 40% can move relatively easily, 15% should be replatformed and 10% should disappear. Perhaps the first several hundred workloads have already been validated on the target platform.
Now the renewal negotiation isn't about convincing Broadcom that you're sufficiently irritated to leave.
It's about agreeing the price at which the VMware footprint you have consciously decided to retain remains economically worthwhile.
That is a much stronger position.
Ironically, the work required to create a credible VMware exit may therefore be precisely what allows you to stay on VMware at an acceptable price.
Time may be your most valuable negotiating asset
For a large VMware estate, I would start this process well before renewal. How early depends on scale, complexity and the extent of VMware-specific dependencies, but months rather than weeks should be the unit of measurement, and very large estates may need considerably longer.
Discovery takes time. Application ownership takes time. Architecture evaluation takes time. Security reviews take time. Procurement takes time. Proofs of concept take time. Building migration skills takes time. Production migrations certainly take time.
Waiting for the renewal proposal before beginning those activities gives the incumbent vendor something extraordinarily valuable: your deadline.
As the contract expiry approaches, technically viable alternatives can become commercially irrelevant simply because there is no longer enough time to execute them safely.
This is why I would treat the VMware renewal date as the end of the strategy process, not its beginning.
By the time serious commercial negotiation starts, the organisation should already understand its options.
Negotiate the architecture, not just the discount
Once that work has been done, there are more levers available than the percentage discount on the quote.
The licensed footprint matters. So does contract duration, expected growth, hardware refresh timing, cluster design and the capabilities contained in the bundle. Workloads scheduled for retirement shouldn't quietly become part of a multi-year capacity commitment. Development and test requirements may deserve different treatment. Hardware decisions should consider the licensing consequences of physical core configuration where relevant.
Broadcom's current 16-core-per-physical-CPU minimum for VCF and VVF is one example of why software licensing and infrastructure architecture now need to be modelled together.
There may also be economic value in capabilities already included within the VMware proposition if they can genuinely replace products or operational complexity elsewhere. If the organisation is paying for functionality it intends to consume, that belongs in the calculation.
But again, only real consumption counts.
The objective isn't to make VMware appear expensive or cheap. It is to establish what the platform is genuinely worth to your organisation.
That number is far more useful in negotiation than the percentage increase from the previous contract.
A renewal can be a bridge without becoming a surrender
Some organisations will complete this analysis and conclude that leaving VMware is strategically correct but operationally impossible before the next renewal.
That isn't failure.
The rational answer may be to renew while executing the migration programme.
A contract can buy the time required to leave safely.
The important distinction is whether the renewal is part of a deliberate transition or merely makes the uncomfortable problem disappear for another budget cycle.
If the organisation needs two years to migrate, the commercial objective should support that reality. If a longer commitment produces compelling economics and VMware remains strategically desirable after the analysis, a longer term may make sense.
What I would avoid is signing a long agreement solely because doing so removes immediate pressure.
The danger is predictable. Commercial urgency disappears, the migration programme loses priority, other projects consume the resources and, several years later, the organisation arrives at the next renewal in exactly the same position.
An exit strategy that only exists while the renewal quote is painful isn't an exit strategy.
It's a negotiating reaction.
Moving thousands of VMs requires a migration factory
The technical difficulty of moving an individual virtual machine is rarely the real problem.
Scale is.
Moving five VMs can be handled as a project. Moving 5,000 requires an operating model.
Large migrations need repeatable discovery, dependency mapping, workload classification, target patterns, application-owner engagement, test criteria, migration tooling, change management, rollback procedures, business validation and decommissioning.
They also need a disciplined approach to exceptions. Every large estate contains workloads whose owners believe they are unique. Some genuinely are. Many simply haven't been examined closely enough.
I would therefore build standard migration patterns and move through waves, beginning with relatively simple workloads but deliberately including representative applications early enough to expose weaknesses in the target architecture. Each wave should improve the factory that follows it.
Most importantly, the migration metric should not be how many VMs have successfully booted on the new platform.
A migrated VM does not necessarily reduce the VMware bill.
The economic benefit appears when enough workloads have left that hosts, clusters, licences and associated infrastructure can actually be removed from the source estate.
Decommissioning is therefore part of migration, not administrative tidying after it.
Without that discipline, organisations can spend heavily building a new platform while continuing to pay for almost all of the old one.
Multi-platform infrastructure is likely, but it needs boundaries
For many large organisations, the end state probably won't involve a ceremonial final VMware shutdown.
It is more likely to be a progressively smaller VMware footprint alongside other platforms chosen for particular workload classes.
The survey evidence pointing towards multi-hypervisor adoption makes sense in that context. But it also contains a warning: respondents identify operational complexity, skills, security and multi-vendor management as significant concerns.
Every additional infrastructure platform creates another lifecycle to manage. It needs monitoring, patching, security, backup, automation, skills, support and governance.
The solution to excessive dependence on one vendor cannot simply be dependence on six.
A multi-platform strategy therefore needs explicit workload-placement rules. The organisation should know why each platform exists, which workloads belong there and under what circumstances an exception is justified.
Otherwise, optionality turns into sprawl.
Vendor independence does not require architectural anarchy.
The decision has a lifecycle dimension as well
The VMware debate isn't only commercial.
Broadcom currently lists 11th October 2027 as the end of general support for a range of VMware version 8 products, including ESXi 8.x, vCenter 8.x and vSAN 8.x, while directing customers towards current VCF or VVF releases.
For organisations with substantial vSphere 8 estates, that creates another strategic decision point alongside renewal.
The choices are not simply renew or migrate. Some organisations will upgrade and remain. Some will renew temporarily while migrating. Some will reduce VMware significantly but retain it for specific workload classes. Others may use the lifecycle event to accelerate a broader infrastructure transformation.
What matters is that the decision is made while there is still enough time to execute it properly.
A multi-thousand-VM migration programme cannot sensibly begin a few weeks before a lifecycle deadline. Neither can a substantial VCF transformation.
The organisations most exposed will be those that spend the next year debating VMware pricing without doing the architectural work necessary to create an alternative.
The Pragmatic View
I don't think every VMware customer should leave.
Nor do I think Broadcom's commercial changes somehow erase the value of a platform that has underpinned enterprise infrastructure for decades.
For some organisations, VMware will remain the right answer. Its maturity, ecosystem, integrated capabilities and the operational knowledge already built around it may outweigh the savings available elsewhere. If the numbers demonstrate that after a proper comparison, staying isn't inertia. It's a rational decision.
For others, the new economics will expose just how dependent the organisation has become on a platform it had stopped questioning. Those organisations may discover that a smaller VMware estate, a second virtualisation platform, greater use of cloud or containers, application retirement and SaaS together produce a much better architecture than simply renewing everything they have today.
But whichever conclusion an organisation eventually reaches, I think the preparation should be largely the same.
Understand the estate properly. Remove workloads that no longer deserve to exist. Determine which VMware capabilities are genuinely valuable and which are simply present. Classify workloads according to what should happen to them rather than assuming every VM needs another VM. Evaluate credible alternatives against the complete operating model, not just licence prices. Prove those alternatives technically. Model migration and coexistence costs honestly. Build the ability to move workloads at scale. And know precisely what conditions would cause you to execute the plan.
Then negotiate.
If Broadcom offers terms that make VMware economically compelling, there is nothing inconsistent about accepting them. The exit work hasn't been wasted. The organisation has cleaned up its estate, understood its dependencies, tested alternatives, reduced concentration risk and created leverage for the next commercial conversation.
If the economics still don't work, the organisation doesn't need another round of threats or executive escalation. It already knows what comes next.
That is why I think the best VMware exit plan may ultimately be the one you never use.
Its value isn't measured by whether every VMware host eventually gets switched off.
Its value is that staying becomes a choice rather than a dependency.
And that changes the nature of the negotiation completely.
The strongest position in any vendor negotiation is not being willing to walk away. It's having somewhere credible to walk to.
