The looming deadline for VMware exits

End-of-support for VMware perpetual licensing is closer than you think

If your organization runs vSphere 8, you have a decision to make — and the window for making it the right way is narrower than the calendar suggests.

Broadcom has set October 2027 as the end-of-support date for vSphere 8, the last version of vSphere that could be perpetually licensed. After that date, no more security patches. No more critical bug fixes. No more compatibility certifications for new hardware. The hypervisor will keep running, but the support and update infrastructure that has surrounded it for two decades will not.

Seventeen months may sound like time. It isn’t. Without modern migration tooling, a typical enterprise virtualization migration — assessing the estate, selecting a target platform, sequencing workloads, executing cutover, validating each application — runs 12 to 18 months on the optimistic end. Organizations that wait until late 2026 to start serious planning will find themselves negotiating with Broadcom from the worst possible position: a hard deadline, no alternative in flight, and a sales team that knows it.

This post is not a “leave VMware” pitch. It is an honest look at the three paths in front of every vSphere 8 customer right now, what each one actually costs, and how to think about the decision before the timeline thinks about it for you.

What end-of-support actually means

End-of-support does not mean shutdown. vSphere 8 will continue to operate normally after October 2027. What stops is everything around it: vendor security patches, critical bug fixes, hardware compatibility testing, and any meaningful technical support from Broadcom.

For organizations in regulated industries, this is where the conversation gets sharper. PCI-DSS, HIPAA, SOX, and ISO 27001 all expect production infrastructure to run on vendor-supported software. Operating an unsupported hypervisor in a regulated environment typically requires formal risk acceptance, documented compensating controls, and — in the worst case — explanations to auditors.

For everyone else, the calculus is about risk accumulation. Newly disclosed vulnerabilities will not be patched. Attackers actively target known-unpatched systems, and that targeting gets more efficient over time. What feels manageable in month three of running unsupported software feels different in month eighteen.

Path 1: Extended perpetual operation with managed risk

The first path is the one that gets the least public attention but is real: stay on vSphere 8 past October 2027, accept the risk formally, and use the extended runway to execute a more deliberate migration.

Several third-party support providers have built businesses around exactly this scenario, offering security guidance, compensating controls, and operational support for organizations running unsupported VMware. For environments with limited internet exposure, lower regulatory burden, or simply more migration complexity than 17 months allows, this can be a credible bridge.

It is not a destination. The risk profile of running unsupported hypervisors compounds over time, and the longer the bridge, the more it costs in security operations overhead, compensating control investment, and eventual migration urgency. Most organizations using this path treat it as a 12-to-24 month extension to one of the other two options, not an indefinite strategy.

This path makes sense when: you have isolated infrastructure, a low-pressure regulatory environment, or a substantive migration program that legitimately needs more runway than the official timeline provides. It does not make sense as a way to avoid the decision.

Path 2: Move to vSphere 9 on a Broadcom subscription

This is Broadcom’s preferred path, and on the surface it is the lowest-friction option. Workloads keep running on familiar hypervisor technology. Operational habits transfer. The migration itself, while non-trivial, is a known quantity for VMware-experienced teams.

The friction is commercial. vSphere 9 is only available through subscription bundles — VMware Cloud Foundation (VCF) or the lower-tier VMware vSphere Foundation (VVF). VCF includes networking and storage virtualization in the bundle whether you want them or not, which is part of why the price moved. Broadcom has also raised the per-server licensing minimum from 16 cores to 72, meaning organizations with smaller hosts now pay for cores they cannot use.

For most organizations, the all-in cost of moving from a perpetual license with active support to a VCF or VVF subscription lands somewhere between three and eight times their previous annual VMware spend. The exact multiple depends on host count, core density, the tier required, and how aggressively the contract is negotiated.

This path makes sense when: you are deeply integrated with VMware-specific features (NSX, vSAN at scale, VCF-specific tooling), or your team has no bandwidth for a platform change in the relevant window. Just go in with eyes open on the commercials, and engage independent licensing advisors before signing — discounts on Broadcom subscriptions are negotiable, and the gap between negotiated and list pricing is meaningful.

Path 3: Migrate off VMware entirely

The third path is the one Broadcom does not advertise but which a growing number of customers are choosing: use the forced migration as the trigger to move to a different platform altogether.

Both paths require a migration. Staying on VMware means migrating to vSphere 9. Leaving means migrating to a different platform. The migration effort is comparable. The cost is not.

Most VMware alternatives — Nutanix, Microsoft Hyper-V and Azure Stack HCI, Red Hat OpenShift Virtualization, or one of the hyperscaler clouds — come in materially below VCF subscription pricing on a three-to-five year TCO basis. The right alternative depends on the workload mix. Nutanix is the most direct replacement for traditional virtualized workloads on-premises. Hyper-V and Azure Stack HCI play well in Microsoft-heavy estates, often using licensing organizations already own. OpenShift Virtualization fits where containers and VMs are converging. And public cloud — AWS, Azure, OCI, GCP — turns the question from “which hypervisor” into “do we still need on-premises infrastructure for this workload at all?”

This path makes sense when: the five-year cost comparison favors leaving, your strategic direction was already trending toward cloud or platform consolidation, or you have workloads that have outgrown VMware-specific dependencies and could run on commodity infrastructure with the right migration tooling.

A decision framework, not a default

The most expensive mistake in this transition is treating it as a technical question. It is at least as much a commercial and strategic one.

Four factors should drive the call:

1. Migration economics. What does staying on VMware actually cost over five years versus leaving? Run the numbers on subscription pricing at realistic discounts, and compare against alternatives at realistic implementation costs. The gap is usually larger than internal teams initially estimate.

   
   

2. Workload portability. How tightly coupled are your workloads to VMware-specific capabilities? The answer determines how much of your estate is genuinely captive versus how much is portable to a less expensive platform.

   
   

3. Regulatory posture. What does your compliance framework require, and what is your actual tolerance for any window of unsupported software? This shapes how much runway you have.

   
   

4. Strategic direction. Where was your infrastructure trajectory headed anyway? A forced migration is a bad reason to make a strategic decision, but it is a perfectly good catalyst to execute one you were already trending toward.

The best decisions in this transition come from working the framework first and letting the vendor conversation follow.

How RackWare helps

For years, moving VMware workloads to public cloud or alternative hypervisors carried real uncertainty — application compatibility questions, performance unknowns, recovery posture gaps. That uncertainty is largely gone. There is now a deep operational track record of VMware workloads running successfully on AWS, Azure, OCI, GCP, Nutanix, and Hyper-V, with the migration mechanics well understood and the post-migration performance and resilience profile proven at scale. The remaining question is execution, not viability.

Execution is where most organizations underestimate the work. Application dependencies, network and storage configurations, IP addressing, recovery point and recovery time objectives, and the cutover sequence itself all have to be handled without disrupting the business. RackWare’s platform is purpose-built for exactly this workload movement. Organizations use RackWare to migrate VMware workloads to AWS, Azure, OCI, GCP, Nutanix, and other hypervisors with minimal downtime and without rebuilding applications at the target — the same image moves, with the configuration and integrity preserved. The platform handles the discovery, the replication, the cutover, and — critically — the disaster recovery posture that has to be in place from day one on the new platform.

If you are working through the path-forward decision and want a clear-eyed view of what the migration side actually looks like for your estate, reach out. The earlier the conversation happens, the more leverage you have on every other piece of this decision.