Chris Engelbert 
There is a buyer in the VMware® estate who does not appear in any exit guide. They are not out of contract, not over budget, and not unhappy. They are running vSphere 8 on hardware they own, with a subscription that is paid up, and nothing in front of them is broken. The only thing that has changed is a date.
Per the lifecycle dates Broadcom publishes for its ESXi releases, general support for ESXi 8.0 ends on 11 October 2027. After that point, staying put is no longer a neutral choice: it is a decision to run production on a release outside standard support. That removes inaction from the option set, which is a very different argument from the cost arguments that have dominated this topic for two years. Cost you can absorb. A support calendar you cannot.
The in-family destination for that estate is VMware Cloud Foundation 9. Everything written about that move describes it as an upgrade, and almost everything written about it contains one sentence to the effect that the change can affect cluster design, storage architecture, networking, and automation. Then the sentence ends and the storage half is never picked up again. This post picks it up.
The clock does not stop when you upgrade
Start with the dates, because they are published and they are checkable. Broadcom maintains the lifecycle policy for its products on its own product lifecycle site, and the community tracker at endoflife.date/esxi mirrors it release by release:
- ESXi 7.0 left general support on 2 October 2025.
- ESXi 8.0 leaves general support on 11 October 2027, with a later technical-guidance phase running to October 2029.
- ESX 9.0, the release that ships with VMware Cloud Foundation 9.0, leaves general support on 17 September 2027.
- ESX 9.1 leaves general support on 12 August 2028.
Read the third line again. The general-support date for the platform release you are being asked to move to is earlier than the date for the release you are being asked to leave, by about three weeks. Landing on 9.0 does not buy runway against the October 2027 deadline. It buys a different deadline that arrives first.
Getting past October 2027 means landing on 9.1 or later, which extends the runway to August 2028, roughly ten months. Then the same conversation happens again. And the technical-guidance phase that follows general support is a wind-down rather than a continuation of fixes, so check what your contract actually entitles you to in that window before you treat it as spare time.
This is the honest framing of the in-family path, and it is not a criticism of any vendor’s release cadence. It is the structural consequence of buying the storage layer as part of a platform version. When the datastore’s version number is the platform’s version number, the datastore inherits the platform’s support calendar. The upgrade is not a destination. It is a subscription to a recurring migration, priced per core, on a cadence you do not set.
What a platform release actually changes below the datastore
vSAN is not a product you patch on its own schedule. It ships with the platform, it is versioned with the platform, and it goes out of support with the platform. That coupling is the whole mechanism, and it is why a platform release is a storage event even when the release notes call it an upgrade.
The specific work sits in four places, and none of it is optional:
- Device eligibility. vSAN’s Express Storage Architecture, introduced with vSphere 8, is the forward-looking design point, and it does not carry the same device assumptions as the original architecture. Every host’s drive set has to be re-validated against the current certification list rather than assumed forward.
- Capacity math. A different storage architecture derives usable capacity from raw capacity differently. Space efficiency, failure-tolerance overhead, and slack-space reservations all move, so the usable terabytes you have promised to application owners have to be recomputed, not carried over.
- Policy and layout. Storage policies, fault-domain layout, and cluster sizing are all expressed against the architecture in use. Changing the architecture means rewriting them and re-testing the failure behaviour they encode.
- Sequencing. Converting a cluster’s storage architecture in place is an evacuate-and-rebuild exercise per cluster, scheduled around whatever your maintenance windows and spare capacity allow.
Add those together and the plan you are executing is a storage migration. It moves data, it changes the layout, it invalidates capacity assumptions, and it needs a rollback story. The only thing separating it from an out-of-family migration is that at the end of it, the storage layer is still welded to a platform version with a support date on it, and the licence is still counted in cores rather than in the terabytes anyone actually provisioned.
Facing a platform-version deadline with a datastore you did not choose? Talk to us before you commit the rebuild effort to a design that inherits the next support date too. Talk to a storage architect
Four paths out, scored on what happens to your storage design
The decision is not “upgrade or migrate.” There are four real options, and they differ far more in what they do to the storage layer than in what they do to the hypervisor.
| Path | Does the storage design get rebuilt? | Licensing and capacity | Does the next platform deadline force another move? |
|---|---|---|---|
| Upgrade in-family to the current platform release | Yes. Device set re-validated, usable capacity re-derived, policies and layout rewritten | Per core, storage bundled with the platform. Capacity growth and core growth are the same purchase | Yes. The clock restarts on the new release, and the first 9.x release expires before vSphere 8 does |
| Step down to the smaller vSphere bundle where it is offered | Partly. The same storage architecture decisions, with fewer components around them | Per core, still bundled. Check availability and entitlements for your region and contract before planning around it | Yes, on the same release cadence |
| Move to another hypervisor-bundled stack | Yes, and it is a full data migration into a different storage format | Per core or per node, storage bundled again. Capacity is bought by adding nodes | Yes, on the new vendor’s calendar instead |
| Land on KubeVirt or Red Hat® OpenShift® Virtualization with the storage layer decoupled | Once, and the resulting design is portable afterwards | Priced like the platform it runs on, by worker-node CPU capacity, and data volume does not change the price | No. Volumes re-attach to the new platform instead of being migrated again |
Table 1: The four available paths, scored on storage consequences rather than on management experience.
Rows one and two keep the coupling. Row three replaces one bundled storage layer with another bundled storage layer, which is a real option and sometimes the right one, but it pays the full migration cost without changing the structural property that caused the problem. Row four is the only one where the storage decision stops being downstream of a platform version.
What decoupling looks like in practice
The argument for decoupling at a version deadline is not that it is easy. It is that the expensive parts are already committed. If you are rebuilding cluster storage, re-deriving capacity, rewriting policies, revalidating applications, and negotiating cutover windows, then you have already paid for a migration. The question is only where it lands.
Landing it on Kubernetes-hosted virtualization with the storage layer provisioned separately changes four things:
- The storage layer keeps its own lifecycle. Volumes are provisioned through CSI against a storage cluster that has no opinion about which hypervisor or platform version sits above it. Upgrading the virtualization platform stops being a storage project.
- Capacity scales independently of compute. Storage nodes and compute nodes grow on separate curves. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. That is the specific coupling the VCF bundle removes and this design restores.
- The fabric is ordinary networking. Volumes are served over NVMe/TCP or NVMe/RoCE, so the storage path does not require a dedicated interconnect. Both hyperconverged layouts, where storage and compute share nodes, and separated layouts, where they do not, run on the same licence metric, so the deployment model stays an engineering decision rather than a commercial one.
- The next platform move is a re-attach. Because snapshots, clones, and volume identity live in the storage layer rather than in a hypervisor datastore format, moving the VMs to a newer platform release means detaching and re-attaching volumes, not copying data again.
The mechanics of getting there are documented rather than theoretical. VM disks import through the KubeVirt Containerized Data Importer as DataVolumes, covered step by step in our guide to migrating VMware VMs to KubeVirt storage. Live migration requires RWX block volumes, which is the requirement most often discovered late. The vSAN replacement side of the design is in replacing vSAN storage on OpenShift and Kubernetes, and the day-2 half, meaning snapshots, backup, and disaster recovery once the VMs are running, is in VMware exit day-2 storage operations.
Two sibling posts cover the other shapes this deadline takes. If your pressure is contractual rather than version-based, see what expires with a VMware perpetual licence. If your estate runs in a hyperscaler region rather than your own rack, see where your storage lands when leaving hosted VMware. And if the question is purely what the bundle costs per core, that is the cost comparison.
Be honest about the trade. Decoupling is a larger day-1 change than an in-family upgrade, it introduces Kubernetes operational skills where they may not exist yet, and it is the wrong answer for an estate with two years of stable runway and no appetite for change. It becomes the right answer at precisely the moment the calendar removes the option of standing still, because that is when the migration cost stops being a difference between the options and becomes a constant across all of them.
Questions and Answers
When does vSphere 8 actually go out of support, and what happens then?
Broadcom’s published lifecycle dates put the end of general support for ESXi 8.0 at 11 October 2027, followed by a technical-guidance phase to October 2029. Verify the dates against Broadcom’s own product lifecycle site for your specific entitlements, since general support and technical guidance are not equivalent and the second phase is a wind-down rather than continued fixes. Practically, the deadline is the point at which staying on the release becomes an active risk decision rather than a default.
Is moving to VMware Cloud Foundation 9 really a storage migration?
Functionally, yes. vSAN is versioned with the platform, and the forward-looking storage architecture in current releases does not carry the same device, capacity, and policy assumptions as the older one. That means re-validating drive sets against the current certification list, re-deriving usable capacity from raw, rewriting storage policies and fault-domain layout, and running an evacuate-and-rebuild pass per cluster. Those are the same activities you would perform to migrate to a different storage layer entirely, which is why the version deadline is the cheapest moment to ask whether the destination should be in-family at all.
Does upgrading to the newest platform release stop this happening again?
No, and the published dates show why. ESX 9.0’s general support ends 17 September 2027, before ESXi 8.0’s own 11 October 2027 date, and ESX 9.1 extends only to 12 August 2028. Each release carries its own expiry, and because the storage layer ships inside the platform, each expiry is also a storage event. The recurrence is a property of the coupling, not of any single release.
What is the alternative to bundled per-core storage on a Kubernetes virtualization platform?
Provision volumes from a storage layer that sits outside the platform and is consumed through CSI. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. It runs in both hyperconverged and separated layouts, and it works under vSphere, Hyper-V, bare-metal Kubernetes, KubeVirt, and Red Hat OpenShift Virtualization, so the storage layer stops being the thing that decides which platform you can move to next.
Could I just use Ceph for this instead?
Ceph is a reasonable choice when performance is not the primary requirement and the team already has the operational depth to run it. It is flexible, well understood, and genuinely free of licence cost. The trade is latency and the operational effort of tuning and maintaining it at scale, which is exactly what hurts when the workloads coming off a vSphere estate are latency-sensitive VM disks with tight IO expectations. If the point of the migration is to keep VM performance predictable while removing the platform-version coupling, an NVMe-native layer is the better fit for that specific goal.
How do we decide between upgrading in-family and decoupling?
Score both against the same three questions rather than against management experience. First, how much of the storage work is common to both paths, because whatever is common is not a reason to prefer either. Second, what the licence metric does over your next three years of hardware refresh, given that core counts per socket are still rising and provisioned capacity is not rising at the same rate. Third, what happens at the deadline after this one. If the answer to the third question is “the same project again,” that is the strongest argument for spending the migration you are already committed to on a design that does not have a platform version attached to it.
