VMware Exit Strategy Framework: A Practical Guide for 2026

Broadcom's acquisition of VMware closed in November 2023 and within ninety days the licensing model was rewritten. Perpetual licences were withdrawn from sale. The product catalogue collapsed from more than 8,000 SKUs into five subscription bundles. Channel partners were terminated in waves. Many enterprise customers who had a stable VMware estate as recently as 2023 are now paying two to ten times their previous run-rate for the same workloads. For a substantial number of those customers, the rational response is no longer to negotiate harder — it is to exit.

This article sets out a practical exit framework. It is not an argument that every enterprise should leave VMware; many cannot, and many should not. It is a structured way to evaluate whether exit is feasible, how long it will take, what it will cost, what risk it carries, and how to sequence the migration so that the period of dual-tenancy is short enough not to consume the savings the exit was meant to produce.

When exit is the right answer

An exit decision should be triggered by one of three economic patterns. The first is a quoted renewal increase above 200% with no realistic negotiation leverage — typically because the workload count is small, the contract value is below Broadcom's strategic-account threshold, and there is no commercial reason for the vendor to discount. The second is a forced bundle escalation in which a customer who needs only vSphere is being pushed into VMware Cloud Foundation (VCF), tripling the per-core cost and adding components (vSAN, NSX, Aria) that the customer does not deploy. The third is a contract term change — typically the elimination of true-up provisions, the introduction of audit clauses with statutory damages, or the removal of perpetual rights — that the customer's procurement and legal teams cannot accept regardless of price.

If none of those three triggers applies, exit is usually the wrong answer. The migration cost, dual-running cost, and operational risk of exit will exceed the savings. A negotiated outcome — possibly with assistance from a specialist advisor — is the better path.

The four-stage exit framework

Stage 1 — Estate discovery and workload classification

Exit planning begins with a complete inventory: every VM, every host, every cluster, every dependency. Most enterprises discover during this stage that their VMware footprint is 20-40% larger than their CMDB suggests, because development, test, and lab clusters were never properly registered. Classify each workload by tier (mission-critical, business-important, supporting, development) and by portability — Windows guests are highly portable, Linux guests are highly portable, anything that uses VMware-specific features (NSX micro-segmentation, vSAN stretched clusters, SRM, vRealize Automation blueprints) is not.

The output of Stage 1 is a single table with one row per workload and columns for criticality, portability, dependency map, and target platform. Without this table, every subsequent stage will produce inaccurate numbers.

Stage 2 — Target platform selection

There is no single "VMware replacement." There are four credible families of target: hyperscaler (Azure, AWS, GCP — usually in their native hypervisor, not in VMware-on-cloud); on-premises hypervisor alternatives (Nutanix AHV, Microsoft Hyper-V with System Center, Red Hat OpenShift Virtualization, Proxmox VE); container platforms for workloads that can be refactored (OpenShift, Kubernetes on bare metal, EKS, AKS); and traditional bare-metal redeployment for the small number of workloads that should never have been virtualised in the first place.

Most exit programmes settle on two or three of these targets — typically a primary hypervisor replacement (often Nutanix AHV or Hyper-V), a cloud track for workloads that can move to native cloud services, and a small bare-metal track for performance-sensitive databases. The selection should be driven by skills already present in the operations team. A migration to a platform your team does not know how to operate will save money on licences and lose it on incidents.

Stage 3 — Sequencing and dual-tenancy

The single largest hidden cost in any VMware exit is dual tenancy: the period during which the new platform is operational, but VMware is still licensed because some workloads have not yet been migrated. Broadcom's subscription model bills on the entire entitled core count, not on the active workload count. If you have 4,000 cores entitled and you have migrated 2,000 cores, you are still paying for 4,000. Dual tenancy therefore needs to be measured in weeks, not months.

The most effective sequencing pattern is "thick first": migrate the largest, simplest, most portable workloads first to draw down the entitled core count as quickly as possible. Then attack the long tail. Many exit programmes go in the opposite direction — they start with the smallest, simplest workloads as "proofs of concept" — and discover at month nine that they are still paying full VMware fees on a 90%-empty cluster.

Stage 4 — Decommission and contract exit

The final stage is the part Broadcom hopes you never reach: clean decommission of every VMware host, formal notification of contract non-renewal, return of any licence material that needs to be returned, and a written confirmation that the customer is no longer entitled to VMware updates or support. This step matters because some enterprises maintain VMware "in case we need it" long after the migration is complete, and pay subscription fees for years on an estate that has no production load.

Cost categories you must model

A defensible exit business case must include all of the following. Omitting any one of them will produce a number that doesn't survive contact with the CFO.

• New platform licensing — subscription, perpetual, or capacity-based, depending on the target.
• Hardware refresh — many enterprises discover that their existing hosts are out of warranty or are not on the target platform's compatibility list.
• Migration tooling — HCX, Veeam, Zerto, Carbonite, Nutanix Move, or custom scripts. Plan for at least one paid migration product.
• Integration rework — backup, monitoring, automation, identity, and DR all need to be reconnected to the new platform.
• Dual-tenancy VMware fees — the most-underestimated line item; budget for at least 12 months of overlap.
• Professional services — internal staff cost, external consulting, and partner-led migration services.
• Training and operational readiness — the team needs to be certified on the new platform before production workloads move.
• Productivity loss during migration — change-window overhead, freeze periods, and reduced velocity on other projects.

A common rule-of-thumb is that the all-in exit cost for a mid-size VMware estate (1,000-5,000 cores) lands between $1,200 and $2,800 per core, spread over 18-30 months. Compare that to the run-rate of staying on VCF — typically $350 to $900 per core per year — and the payback period is usually three to five years.

Risk register

Every exit programme should maintain a live risk register. The risks that most consistently cause exit programmes to stall or fail are these:

1. Application incompatibility — discovered during cutover, usually because the application team was not engaged early enough.
2. NSX micro-segmentation rebuild — if NSX is in production, the firewall rule base has to be reimplemented on a new platform; for some estates this is a six-month project on its own.
3. VAAI / vVol dependency — storage arrays integrated with vSphere may need replacement or reconfiguration.
4. Compliance and audit findings — regulated industries (financial services, healthcare, government) need to revalidate every control after the platform change.
5. Staff attrition — VMware administrators with subscription-driven anxiety often leave during the migration, taking institutional knowledge with them.
6. Broadcom audit during the exit window — Broadcom is actively auditing customers who have signalled exit intent. Assume you will be audited and prepare accordingly.

Negotiation while you exit

A counterintuitive but consistently effective tactic is to negotiate with Broadcom as if you are staying, while you execute the exit. Broadcom's commercial team responds to credible exit signals with substantial discounts — typically 30-50% off the initial quote. A customer who is genuinely exiting can use that discount to extend the dual-tenancy runway, reducing the cost of exit. A customer who has decided to stay can use the same discount to lock in a multi-year deal at a tolerable price.

The two postures look identical from Broadcom's side of the table. The difference is internal: in one case the discount funds the exit; in the other, it funds the stay.

What success looks like

A successful VMware exit programme produces three artefacts. First, a decommissioned VMware estate — zero hosts in production, contract non-renewed, support terminated. Second, a target platform running the migrated workloads at parity or better operational maturity, with documented runbooks, monitoring, backup, and DR. Third, an audit defence file — a complete record of the migration timeline, the workloads migrated, and the licensing position at every milestone — that the customer can produce if Broadcom raises a post-exit audit claim within the three-year window during which most contracts permit it.

The third artefact is the one most exit programmes forget. It is also the one Broadcom most often relies on when raising terminal-state audit claims. Build the file as you go, not after.

Bottom line

VMware exit is not a slogan. It is a capital project on the order of a major data centre migration, and it carries similar risk, similar duration, and similar political weight inside the enterprise. Done well, it produces durable annual savings of 40-80% of the previous VMware spend. Done poorly, it produces a stalled programme, an angry CFO, and a Broadcom contract that has been silently renewed because no one cancelled it in time. The framework above — discovery, target selection, sequencing, decommission — is the one that most consistently produces the first outcome rather than the second.

Common objections to exit — and how to respond

"Nutanix and Hyper-V can't run our workloads"

This objection is almost never technically accurate. The market-share data from 2025-2026 shows that workloads which run on vSphere also run on Nutanix AHV, Hyper-V, OpenShift Virtualization, and Proxmox without modification, with the exception of a small number of NSX-dependent applications and some VMware Tools-tied automation. The objection is more often a proxy for skills concern: the team knows how to run vSphere and does not know how to run the alternatives. That is a training question, not a platform question.

"Our software vendors don't support anything except VMware"

Vendor support matrices have shifted substantially in 2024 and 2025. The major enterprise software vendors (Oracle, SAP, Microsoft, IBM, Red Hat) now support their products on multiple hypervisors. Some niche vendors still certify only on vSphere, but the certification is typically conservative; running unsupported is often technically fine. Document the support exposure as a risk register entry, not as an exit blocker.

"We just renewed for three years"

A multi-year Broadcom contract makes exit less urgent but no less feasible. The exit programme can be sequenced to complete at the renewal cliff, with the migration cost amortised over the contract period. Customers in this position should start exit planning at month 18 of a 36-month contract, not at month 32.

Governance and CFO communication

A VMware exit programme of any meaningful size requires CFO-level sponsorship. The single most effective governance structure is a steering committee chaired by the CIO and CFO jointly, meeting monthly, reviewing the business case, the migration velocity, the dual-tenancy cost, and the risk register. Without that structure the programme tends to drift — technical teams optimise for low-risk migration, finance optimises for cost suppression, and the two pull against each other until the programme stalls.

CFO communication should focus on three numbers: total programme cost (capex + opex over the migration window), peak monthly dual-tenancy spend (which is what the bank covenant or quarterly target will feel), and the breakeven date (when annual run-rate savings exceed annual programme cost). All three numbers will move during the programme; the steering committee's job is to keep them moving in the right direction.

Frequently asked questions about VMware exit

How long does a VMware exit really take?

For a mid-size estate (1,000-5,000 cores), 18-30 months from board approval to final decommission is typical. Faster timelines are achievable for smaller estates with simpler workloads. Larger estates with significant NSX or vRealize dependency commonly run 30-42 months. The single biggest determinant of duration is the rate at which the customer can sustain change-window throughput, which is a function of operational maturity rather than technical capability.

Should we tell Broadcom we are exiting?

Not directly, and not in writing. A formal "we are leaving" communication invites audit attention, deprioritises the customer in Broadcom's support queue, and forecloses the negotiation leverage that comes from credible exit posture. The right posture is to negotiate hard, mention alternatives credibly, and let Broadcom infer the exit intent without confirming it. Many of the most successful exit programmes we have observed never told Broadcom they were exiting until the final non-renewal notice was sent.

What about VMware support during the migration?

Maintain Broadcom support contractually through the migration period. The cost of incidents during a migration without vendor support is much higher than the cost of the support itself. Plan for support to expire on the same day the last VMware host is powered down, not before.

Can we do a partial exit?

Yes, and many customers should. A partial exit — moving 60-80% of workloads to an alternative platform while retaining a smaller VMware footprint for the workloads that genuinely require it — can produce most of the financial benefit with substantially lower risk. The strategic question is whether the retained VMware footprint is large enough to justify the contract overhead. Below approximately 500 cores, the per-core cost of a small VMware contract often makes complete exit more economic.