VMware vSphere 8 and ESXi 8 reach end of general support on 11 October 2027. After that date, Broadcom stops shipping patches, bug fixes and security updates for them. If your production estate still runs on vSphere 8, you have twelve months to decide where it goes next, and for most infrastructure teams that is about one budget cycle.

The default answer is to upgrade to VMware Cloud Foundation 9. For many organisations, that means a much bigger bill, a subscription with no way back to perpetual licences, and a platform renewed on Broadcom’s terms for years to come.

This article covers what the end of support means in practice, why the VCF 9 route buys less time than it seems, and how Apache CloudStack and ShapeBlue Migrate give you a realistic way off VMware without stopping the business.

 

What happens in October 2027

ESXi 8.0 leaves general support on 11 October 2027, and the first release of ESXi 9 leaves it a month earlier (endoflife.date).

After general support ends, there are two more years of “technical guidance” (to October 2029 for ESXi 8.0): workarounds and self-help, but no new patches or security fixes. For a hypervisor sitting under every production workload, that is a risk few security teams will sign off for long. ESXi 7.0 already crossed that line in October 2025, so anyone still on 7 is behind the date everyone else is worried about.

 

Staying on VMware means VCF 9, on Broadcom’s terms

Staying with VMware past October 2027 means moving to VCF 9. Before you treat that as the safe option, look at what comes with it.

• VCF 9 is subscription only. It is sold as one per-core subscription covering vSphere, vSAN, NSX, HCX, VCF Operations, VCF Automation, the Kubernetes service and Private AI Services. Perpetual licences can’t be upgraded to VCF 9; they have to be converted to a subscription first (Schneider IT).
• Small estates pay for cores they don’t have. Since April 2025 the minimum order is 72 cores, up from 16, and renewing late adds a 20% surcharge (Techzine).
• Bills go up, often by a lot. Gartner’s Paul Delory puts typical increases at 300% to 400% (The Register). European cloud providers in CISPE have reported much worse (Born City).
• And 9.0 won’t last you long. ESXi 9.0 leaves general support on 17 September 2027, almost a month before ESXi 8.0 (endoflife.date). If you upgrade, you really need 9.1, which is supported until August 2028.

 

You won’t be the only one leaving

Most VMware customers are already reducing their footprint. Very few have finished.

Source	Sample	What it found
CloudBolt, via Network World (Jan 2026)	302 IT decision makers, North America, 1,000+ employees	86% are reducing VMware use; 44% have moved 25% or more of their estate; only 2% have moved 75% or more
Virtified, via The Register (Mar 2026)	450 VMware users, 14 countries	50% plan to reduce VMware use by 2028
Gartner, via The Register (Sep 2025)	Analyst forecast	35% of VMware workloads will run elsewhere by 2028; a full migration takes three years or more

The gap between intent and progress tells you where the difficulty is. As Matt Kimball of Moor Insights puts it, “there is no such thing as a frictionless migration from VMware”. Gartner’s Paul Delory warns that teams which leave often end up running more than one hypervisor for years.

So the plan has to start now, and it has to assume VMware and the new platform will run side by side during the move. Rimini Street is right that end of general support is not a switch-off date (Rimini Street). But crossing it with a shrinking VMware footprint and a migration already under way is a very different position from being caught with no plan at all.

 

The alternative: Apache CloudStack

Most lists of “VMware alternatives” compare hypervisors. Apache CloudStack sits one layer up: it is an open-source cloud management platform that runs several hypervisors under one control plane, natively KVM, VMware vSphere and XCP-ng, and through its Extensions Framework also Proxmox, Hyper-V and other platforms. That matters for the side-by-side period described above, because one platform can run your existing vSphere clusters and your new KVM clusters while workloads move between them.

• CloudStack can manage your existing vSphere clusters, so users get the same self-service portal, API and quotas before any VM changes hypervisor.
• Terraform, the CloudMonkey CLI and the CloudStack API behave the same whatever hypervisor sits underneath, so you don’t rewrite pipelines for each platform.
• There’s no licence on the control plane. CloudStack is an Apache project; you pay for support if you want it, not per core.
• It runs at any scale. CloudStack works on a handful of physical hosts and on large, geographically distributed deployments, all managed from a single control plane, and it was designed to be run by small operations teams. That sets it apart from OpenStack, which Gartner calls “too big, too complex” for typical IT departments.
• The Extensions Framework brings in platforms beyond the native hypervisors. CloudStack ships in-built extensions for Proxmox and Hyper-V (CloudStack docs), and because an extension is any external program that implements CloudStack’s actions, the same approach can bring in others, such as Firecracker microVMs (Extensions Framework). Instances managed through extensions support a subset of CloudStack features, so check the documentation for what applies to your use case.
• It isn’t limited to x86. Since version 4.20, a zone can mix x86-64 and ARM64 KVM clusters, and templates are tagged by architecture so each VM lands on a matching host (CloudStack docs). Version 4.21 added KVM on s390x, for IBM Z and LinuxONE (4.21 release notes).

You can also keep more of your hardware than VCF 9 allows. Servers whose core components are fully end of life, such as those with Haswell and Broadwell CPUs, drop off the VCF 9 compatibility list (VMware blog). KVM is part of the Linux kernel, so hardware support comes from the host distribution, not from a hypervisor vendor’s certification list. RHEL 9 and its rebuilds need an x86-64-v2 CPU, which takes in Intel processors back to around Nehalem (Phoronix). Those machines can still run as KVM hosts under Apache CloudStack, which supports Oracle Linux, Alma Linux, Rocky Linux, RHEL, Ubuntu LTS, Debian, openSUSE Leap and SUSE Linux Enterprise Server for KVM (CloudStack compatibility matrix). Whether you want production running on servers that old is a separate question, but it becomes your decision rather than a licensing one.

 

Getting there: ShapeBlue Migrate

CloudStack has had a native VMware to KVM import since version 4.19 (CloudStack docs). It works well for a pilot or a few dozen VMs. It is not designed to plan and run hundreds or thousands of migrations across several vCenters with tight maintenance windows.

That is the gap ShapeBlue Migrate fills. The thinking behind it is that, at scale, the hard part is keeping downtime short, more than copying data fast. It automates each stage from discovery to cutover (product overview):

• Agentless discovery across multiple vCenters, filtered by folder, resource pool or tag, so you start from a complete inventory.
• Wave planning that groups VMs by dependency and risk into ordered waves.
• Warm migration with Changed Block Tracking: data syncs while the VM keeps running, and the final delta cutover takes minutes, whatever the disk size.
• Scheduled cutovers, graceful or hard, planned around your maintenance windows.
• IP and MAC addresses preserved, so guests come up on the new platform without network reconfiguration. Reusable first-boot scripts handle any other adjustments.
• A rollback path: the source VM stays untouched until the cutover is verified.
• Network, storage, offering and boot settings you can override globally, per wave or per VM.
• Live per-VM progress, throughput and ETA, with high availability, RBAC, encrypted credentials, audit trails and automatic retries for the migration platform itself.

It also offers four transport methods, selectable per VM or per wave (ShapeBlue):

Method	How it works	Needs VDDK
CBT	Warm sync of changed blocks, short final cutover	Yes
VDDK	Direct conversion with virt-v2v	Yes
OVF	Export handed to CloudStack’s import	No
OVERLAY	Zero-copy qcow2 overlay on shared NFS (CloudStack 4.22.1+)	No

The last column matters more than it looks. Broadcom has removed its public VDDK download pages without explanation, and many VMware migration tools rely on that library. Two routes that don’t need it give you a way forward if getting hold of VDDK becomes harder.

 

A realistic plan for the next twelve months

Twelve months is not long enough to move a large estate, but it is enough to cross October 2027 with a plan that is already working.

1. Q4 2026: inventory and renewal date. List every cluster, VM, OS version and dependency; ShapeBlue Migrate’s discovery can build this inventory across your vCenters. Find out when your current VMware agreement renews, because that date, not October 2027, is often the real deadline for a decision.
2. Q4 2026 to Q1 2027: classify the workloads. Sort them into move early, move later and stay for now. Flag anything with vendor certification or VMware-specific feature dependencies.
3. Q1 2027: proof of concept. Stand up Apache CloudStack with KVM next to vSphere, connect it to the same network and storage where you can, and move a representative sample of VMs. Measure sync time, cutover downtime, performance and what breaks.
4. Q2 2027: first production wave. Move the easy group in planned waves, using warm migration to keep cutover windows short. Update runbooks, monitoring and backup as you go, not afterwards.
5. Q3 2027: size the VMware that remains. With real migration numbers in hand, negotiate the renewal for the smaller footprint you actually need, or plan third-party support for the systems that stay.
6. Q4 2027 onwards: keep going. Later waves continue at the pace your application owners can handle.

Starting now won’t get a large estate moved by October 2027. It does mean next year’s decisions rest on your own test results rather than on a renewal quote.

 

Don’t wait for the renewal quote

October 2027 is a real deadline, and moving to VCF 9.0 doesn’t push it back. A year from now you’ll either be choosing between options you’ve tested on your own workloads, or signing whatever renewal is put in front of you.

Apache CloudStack gives you an open-source platform that can run your VMware and KVM estates side by side while you move. ShapeBlue Migrate gives you a controlled way to get there: discovery, wave planning, warm migration and scheduled cutovers, with a rollback path at every step. Pick a sample of your own VMs, run them through a proof of concept this quarter, and base next year’s decision on the results. To start that conversation, contact ShapeBlue at info@shapeblue.com.