Since Broadcom completed its acquisition of VMware in late 2023, few infrastructure topics have generated as much boardroom attention. Perpetual licenses ended, products were bundled into subscriptions billed per core, and renewal quotes rose sharply for many customers. Predictions of a mass exodus followed. Two years on, the reality is more nuanced: most organizations have not left, but a large majority are actively reducing their dependence. For IT leaders, the question is no longer whether to have a VMware strategy, but how to execute one without destabilizing the systems that run the business. This guide sets out the options, the evidence and a practical, phased decision process for 2026 and beyond.
Where the Market Stands in 2026
The best recent data comes from a CloudBolt survey of 302 IT decision-makers at North American enterprises with more than 1,000 employees, fielded in January 2026 and reported by Network World and CIO. Its headline findings paint a picture of gradual, deliberate reduction rather than flight:
- 86% of respondents said they are reducing their VMware usage, and 88% worry about future license price increases.
- Only 14% saw license prices more than double, but 59% reported increases above 25%.
- 44% had migrated a quarter or more of their environment away from VMware; just 2% had moved 75% or more, and heise’s analysis of the same survey reported that only 4% had fully replaced VMware.
- Among those moving workloads, 72% chose public cloud IaaS, 43% Hyper-V or Azure Stack, and 34% SaaS replacements.
- The main deal-breakers were migration complexity and risk (25%), higher-than-expected costs (23%) and technical limitations (21%).
Perceived disruption is easing, and 60% reported more confidence in their VMware strategy than in 2024. Yet 63% had changed strategy at least twice, and executive pressure to act had risen for 41%. Analysts quoted in the coverage made a point worth internalizing: because VMware sits beneath critical systems, migration is a multi-year program, not a procurement switch. Heise also cited a Gartner forecast that VMware’s share of the virtualization market will fall from roughly 70% in 2024 to around 40% by 2029.
The Strategic Options
There is no single “exit.” Most organizations end up with a portfolio of destinations. The realistic options fall into six groups.
1. Stay, Optimize and Renegotiate
For some estates, especially those using much of the VMware Cloud Foundation stack, staying can be rational. Rightsizing core counts, consolidating clusters, retiring unused hosts and negotiating multi-year terms can soften the increase. This option buys time but does not reduce strategic dependence.
2. VMware in the Public Cloud
Hosted VMware offerings, such as Azure VMware Solution, Google Cloud VMware Engine and Amazon Elastic VMware Service (generally available since August 2025), let you move VMs to a hyperscaler without re-platforming. This exits the data center quickly but keeps you on VMware licensing; in some offerings you bring your own VCF subscription. It is often a bridge rather than a destination.
When evaluating a hosted option, check the supported VCF versions, the instance types and regions available, how licensing is handled and what the exit path looks like. Amazon EVS, for instance, runs VCF inside your own VPC on bare-metal instances, supports bringing existing VCF licenses through a portability entitlement, and launched in six AWS Regions across North America, Europe and Asia-Pacific. Those details shape both cost and how easily workloads can later be converted to native services in the same network.
3. Rehost to Native Cloud IaaS
Converting VMs to native instances on AWS, Azure or Google Cloud is the most common destination in the CloudBolt data. Mature replication tools make the mechanics routine for standard Windows and Linux servers, and agentic AI tools now automate much of the assessment, network translation and wave planning (covered later). The trade-off is that you need landing zones, cloud operations skills and cost governance in place.
4. Alternative On-Premises Hypervisors
For workloads that must stay on-premises for latency, data gravity, sovereignty or cost reasons, the main alternatives are Microsoft Hyper-V and Azure Local, Nutanix AHV, Red Hat OpenShift Virtualization (KVM-based, running VMs alongside containers), Proxmox VE, SUSE Harvester and OpenStack. Each has different strengths in ecosystem, management tooling, backup integration and support model.
5. Modernize to Containers or PaaS
Applications under active development may be better candidates for containerization or managed platforms than for a like-for-like VM move. This delivers the greatest long-term benefit but takes the most effort, so reserve it for applications with clear business value.
6. Replace With SaaS or Retire
Every VMware estate contains servers running commodity functions that a SaaS product could replace, and servers that nobody uses. Retiring and replacing is the cheapest migration of all.
Decision Criteria: Triage the Portfolio, Not the Platform
The most effective programs avoid a single platform decision and instead triage each workload. Score every application or VM group against these criteria:
- Business criticality and change tolerance: how much downtime and risk can the business accept during migration?
- Technical fit: operating system and version support, specialized hardware (GPUs, USB dongles, raw device mappings), clustering and licensing constraints such as per-host database licensing.
- Dependency complexity: how many other systems does it talk to, and how well are those dependencies documented?
- Data gravity and residency: data volume, latency sensitivity and regulatory location requirements.
- Lifecycle stage: invest, maintain or retire? Applications nearing end of life rarely justify modernization.
- Operational readiness: do target-platform skills, tooling and support contracts exist today?
A simple outcome matrix works well: retire or replace low-value workloads; rehost standard servers to cloud IaaS; move latency-sensitive or regulated workloads to an alternative hypervisor; bridge hard-to-move systems through hosted VMware; and modernize strategic, actively developed applications.
Choosing an Alternative Platform: What to Evaluate
When part of the estate must stay on-premises, the choice of hypervisor deserves the same rigor as any major platform decision. Proof-of-concept testing with your own workloads is essential, because vendor feature matrices rarely reveal operational friction. Evaluate candidates against these dimensions:
- Management experience: how close the day-to-day tooling is to what operators know, and how well it handles templates, live migration, high availability and capacity planning at your scale.
- Ecosystem integration: certified support from your backup, disaster recovery, monitoring and security vendors, and from the vendors of packaged applications you run.
- Migration tooling: the availability of reliable VM conversion tools, such as Red Hat’s Migration Toolkit for Virtualization or Nutanix Move, and how they handle drivers, guest tools and network mappings.
- Storage and networking model: hyperconverged versus external storage, software-defined networking capabilities and how micro-segmentation will be reimplemented.
- Container convergence: whether you want VMs and containers on one platform, which favors options such as OpenShift Virtualization or Harvester, or prefer to keep them separate.
- Commercial model and vendor risk: licensing metrics, price predictability, support quality and the risk of simply recreating the same dependency with a different vendor.
Many organizations deliberately run two target platforms during transition, such as public cloud for most workloads plus one on-premises hypervisor, to avoid putting every workload back into a single vendor’s hands. CloudBolt respondents reported both sides of this trade-off: 65% saw an improved risk profile from diversification, while 52% found multi-platform complexity a problem, according to heise.
Building an Honest Cost Model
The renewal quote is only one side of the equation. Many failed business cases undercount the cost of moving. A credible model compares at least a five-year horizon and includes:
- Current and projected VMware subscription costs under realistic core counts.
- Target platform costs: cloud compute and storage with reservations or savings plans, or alternative hypervisor licensing and support.
- Hardware refresh avoided or required, and data center exit savings if applicable.
- Migration labor, tooling, dual-running periods and testing.
- Re-licensing for operating systems, databases and backup tools, which can change significantly between platforms.
- Operating model changes: training, new monitoring and backup tooling, and staffing.
- Risk contingency for complex applications, typically the long tail that consumes most of the effort.
Be wary of business cases that assume every workload moves in year one. Heise’s analysis of the CloudBolt findings notes that resolving dependencies typically takes 18 to 24 months in large estates. Model a realistic ramp, and remember that partial reduction still lowers renewal exposure.
A Phased Execution Plan
Phase 0: Secure Your Negotiating Position (0–3 Months)
Before signing a long renewal, gather accurate inventory and core counts, identify quick-win retirements, and model at least two credible alternatives. A shorter renewal term that matches your migration timeline is often worth more than a modest discount on a long one.
Set up governance at the same time. Executive interest is high (CloudBolt found the CEO, board and CFO were the most-cited sources of pressure), so establish a steering group with finance, infrastructure, security and application owners, a single program owner, and a monthly dashboard showing VMs moved, cores reduced and spend avoided. Clear visibility prevents the strategy churn that so many survey respondents reported.
Phase 1: Discover and Triage (1–4 Months)
Combine automated discovery (RVTools exports, vCenter data, network flow analysis) with application owner interviews. Build dependency maps, assign each workload a disposition and destination, and group workloads into move groups that can migrate together. AI-assisted tooling has shortened this phase considerably: AWS Transform, for example, ingests RVTools exports and other inventory sources, maps dependencies and generates wave plans and network designs, and since December 2025 it can also translate NSX and common third-party firewall configurations into target network designs. Treat these outputs as strong first drafts that still need validation with application owners.
Phase 2: Build Targets (2–6 Months, in Parallel)
Stand up cloud landing zones and/or the alternative hypervisor platform, including networking, identity, backup, monitoring and security tooling. Translating NSX micro-segmentation and firewall rules into the target model deserves early attention; it is frequently underestimated.
Phase 3: Pilot and Industrialize (4–9 Months)
Migrate a pilot wave of low-risk workloads end to end, measure effort per server, refine runbooks and automation, then scale into a migration factory with a predictable cadence. Define rollback criteria for every wave in advance, and keep source VMs powered off but intact for an agreed period after cutover so a failed migration can be reversed quickly.
Phase 4: Tackle the Long Tail and Shrink the Footprint
Move complex and critical systems with dedicated plans, consolidate remaining VMware clusters, and reduce core counts at each renewal. Some organizations deliberately keep a small, well-optimized VMware estate for workloads that are not worth moving.
A Worked Example: A 1,200-VM Estate
Imagine a hypothetical manufacturer with 1,200 VMs across two data centers, facing a renewal in fourteen months. Triage produces the following picture: about 15% of VMs are retired or replaced by SaaS (old file servers, a legacy intranet, duplicate test environments); about 50% are standard Windows and Linux servers suitable for rehosting to native cloud IaaS; about 20% are factory-floor and latency-sensitive systems that stay on-premises and move to an alternative hypervisor; about 10% are complex ERP-adjacent systems bridged to a hosted VMware service while they are re-architected; and about 5% are actively developed applications that are containerized.
The company signs a shorter renewal covering a reduced core count, aligned to the migration plan. It builds cloud landing zones and an on-premises KVM-based platform in parallel, pilots with sixty low-risk VMs, then runs biweekly waves. By the next renewal, the remaining VMware footprint is limited to the bridged systems and a handful of exceptions, and the company has a clear plan for those. The total program spans more than two years, consistent with what analysts describe, but cost exposure falls at every step.
Pitfalls to Avoid
- Making a platform decision before a portfolio decision. One destination rarely fits every workload.
- Underestimating networking and security translation, especially NSX rules and micro-segmentation.
- Forgetting backup, DR and monitoring tooling, many of which are tightly integrated with vSphere.
- Ignoring licensing knock-on effects for databases and operating systems on new platforms.
- Skipping skills planning. A third of CloudBolt respondents reported a lack of in-house expertise, according to heise, and multi-platform complexity rises during transition.
- Treating a hosted VMware bridge as permanent without a plan to exit it.
A VMware exit is a portfolio program, not a platform swap. Triage every workload, model costs honestly, align renewals to a realistic migration ramp, and reduce exposure step by step.
Conclusion: Reduce Dependence Deliberately
The Broadcom era has turned virtualization from a settled utility into a strategic decision. The evidence from 2026 shows most enterprises choosing gradual, deliberate reduction: retiring what they can, rehosting standard workloads to cloud, moving latency-sensitive systems to alternative hypervisors and modernizing selectively. Organizations that triage their portfolios, build honest five-year cost models and execute in waves will lower both cost and dependency, while those waiting for a perfect single answer will keep negotiating from a position of weakness.
How Hanoi Technology Can Help
Hanoi Technology helps organizations triage VMware portfolios, build cost models and run migration factories to cloud IaaS, alternative hypervisors or modern platforms.
Further Reading
- Some enterprises are dropping VMware, just not all at once – CIO
- Two years after Broadcom acquisition: VMware exodus fails to materialize – heise online
- AWS announces general availability of Amazon Elastic VMware Service – AWS
- AWS Transform adds new agentic AI capabilities for enterprise VMware migrations – AWS