Rob Pankow 
Most VMware® coverage written since the move to subscription licensing addresses a buyer who has already decided to leave. That skips the decision that comes first. A large installed base still holds perpetual licenses, is holding a support renewal quote, and is trying to work out a narrower question: what happens if we simply do not sign this.
The answer is more nuanced than either side of the argument usually admits. A perpetual license is an owned asset and it does not lapse. The support and subscription contract attached to it is an annual purchase and it does. Nothing stops working on the day support ends, which is why “keep running it” is a genuinely viable position and not just denial. But the estate does begin to age in a specific, predictable way, and the component that ages worst is the storage layer, because it is bolted more tightly to the hypervisor version than anything else in the stack.
This post separates the two contracts, explains what you actually lose when support lapses, and makes the case that the hardware refresh, not the renewal date, is what sets your real deadline.
What a Perpetual License Still Entitles You To
A perpetual license is a permanent right to run a specific version of the software on a defined quantity of hosts or cores. It was sold as a one-time purchase, and the entitlement does not evaporate because the vendor changed its commercial model. After Broadcom’s acquisition, new perpetual licenses stopped being sold and the catalogue moved to subscription bundles, but that change applies to new purchases. It does not retroactively cancel what was already bought.
Concretely, with an expired support contract and a valid perpetual license you keep:
- The right to run the licensed version indefinitely, on the licensed host or core count.
- The binaries and license keys already in your possession, installed and operating.
- Your existing clusters, VMs, vCenter inventory, and vSAN datastores, all functioning exactly as before.
- The right to reinstall the version you own on the hosts you licensed, provided you retained the installation media.
That last point carries a practical trap worth acting on before a contract lapses rather than after. The entitlement is to the version, but the distribution channel for that version is part of the support subscription. Once the contract ends, portal access to download builds and patches generally goes with it. Teams that never archived their own ISOs, offline bundles, and patch payloads find themselves entitled to software they can no longer obtain a copy of. Pulling a complete local archive of the exact builds you run, plus the matching drivers and firmware bundles, is the single cheapest piece of insurance available in this whole decision.
The other genuine constraint is the license count. It is fixed at what was purchased. A frozen estate cannot grow, so any capacity expansion means either a new subscription purchase for the additional hosts, or moving the incremental workload somewhere else. In practice, this is what quietly converts a “we will just keep running it” decision into a hybrid estate within about two years.
What Actually Expires When Support Lapses
The support and subscription contract, not the license, is the thing with an end date. It bundles several distinct entitlements that teams tend to think of as one, and they matter unequally:
- Security patches and bug fixes. The most consequential item. A hypervisor is a high-value target and a frozen version accumulates unpatched CVEs indefinitely. For an estate that terminates internet-facing traffic or sits inside a regulated scope, this is usually the item that forces the timeline, well ahead of any commercial consideration.
- Version updates and upgrades. No moves to newer releases, so the estate is pinned to its current version permanently.
- New hardware certifications. The compatibility guide keeps being updated, but only for supported versions. Your frozen version’s certified hardware list stops growing on the day it stops being a supported release.
- Vendor escalation. No technical support case path when something breaks in a way your team cannot diagnose alone.
- Download and portal access. Covered above, and worth solving before the lapse rather than after.
Then there is the renewal quote itself, which is where the money actually moves. Support renewals on legacy perpetual estates are frequently repriced onto current metrics and current bundle structures, which is how a maintenance line item that was flat for years arrives with a step change in it. Some renewals are quoted only as a migration onto a subscription bundle, meaning the perpetual asset you own stops being relevant to the price you are being asked to pay. That is the moment to price the alternatives properly rather than treat the quote as a fixed cost of doing business. We worked the subscription-side arithmetic in detail in our vSAN exit cost analysis, and the per-core mechanics there apply directly to a repriced renewal.
Compliance exposure deserves a clear-eyed mention, without drama. Running a version you own with no support contract is legitimate. Running builds or features you are not entitled to is not, and the distinction gets blurry in estates where patches were applied over years by different people. Audit activity around unentitled use has been widely reported across the industry since the licensing transition. Before letting a contract lapse, reconcile what you are actually running against what you actually own, host by host. A frozen estate is a defensible position only if you can document it.
Holding a renewal quote and weighing whether to freeze, renew, or leave? Talk to us before the storage layer becomes the constraint that decides the timeline for you. Talk to a storage architect
Why the Hardware Refresh Sets the Real Deadline
Here is the part missing from most discussions of this decision, and it is a storage argument rather than a licensing one.
A frozen, out-of-support estate does not fail on the day support ends. It fails at the next hardware refresh. The mechanism is the compatibility guide. Hardware certification is version-specific: new server generations, new NICs, and new NVMe drive models get certified against current hypervisor releases, not retroactively against the release you froze on. Your supported hardware list is therefore a snapshot taken on the day your version left support, while the market you buy replacement hardware from keeps moving. Two or three years on, the drives you can actually purchase are largely models that were never certified for the version you are running.
Storage is where this bites first and hardest, for three reasons:
- The storage data plane is inside the hypervisor. vSAN is not an application running on top of ESXi, it is kernel-level functionality shipped as part of it. Its device support, drivers, and firmware qualification move with the ESXi version. You cannot update the storage layer’s hardware support without updating the hypervisor, and updating the hypervisor is precisely what an expired support contract prevents.
- Drive qualification is strict and specific. Modern all-flash designs are validated against named NVMe device models and firmware revisions, not against a general class of device. “It is an enterprise NVMe SSD” is not a qualification. Substituting an uncertified drive into a storage layer that keeps redundancy and consistency guarantees is a materially different risk from substituting an uncertified NIC.
- Failed drives are not optional purchases. Compute refresh can be deferred by running servers longer. Drive replacement cannot: flash wears out, and a degraded storage cluster needs a replacement device that is both available to buy and certified for the version you run. That intersection shrinks every year.
The 2026 procurement environment sharpens all of this. Enterprise SSD and DRAM contract prices moved sharply upward through the first half of the year, driven by demand that the supply side has met with margin rather than expanded capacity, and the usual assumption that per-terabyte cost falls each year no longer holds for planning purposes. So the hardware refresh trigger is arriving at the same moment that the hardware itself got more expensive, and buyers have less room to solve a certification problem by simply overspending on whatever is qualified and in stock. If capacity efficiency is the lever you need to pull, our guide to NVMe storage cost optimization covers the erasure coding and thin provisioning mechanics in depth.
Four Paths, and What Each One Costs You
The renewal decision is usually presented as a binary, renew or migrate. There are four positions worth pricing, and the third is the one that rarely appears on the table.
Table 1: Renewal options for a perpetual VMware estate, compared on the four dimensions that actually differ.
| Path | Cost exposure | Hardware refresh headroom | Security patch posture | Reversibility |
|---|---|---|---|---|
| Freeze and run unsupported | Lowest near-term, no recurring fee | Shrinks yearly, hard stop when certified drives leave the market | None, CVEs accumulate on the hypervisor | High on paper, but falls as the estate drifts further from current versions |
| Renew support as quoted | Highest recurring, repriced at each renewal | Preserved while you keep paying | Fully patched | Low, each renewal resets the clock and defers the decision |
| Decouple storage first, then decide | One capacity purchase, priced per usable TB/yr | Restored, storage hardware choice no longer gated by the hypervisor version | Unchanged for now, but the constraint on upgrading is removed | Highest, hypervisor choice stays open and unhurried |
| Full platform migration now | Largest project cost, compressed into one window | Fully restored | Fully patched on the new platform | Low once underway, and schedule risk is concentrated |
The third row is the one that changes the shape of the problem. Everything that makes the first two rows uncomfortable traces back to the same coupling: the storage layer’s hardware support is welded to the hypervisor version, so the hypervisor decision has to be made on the storage layer’s schedule. Break that coupling and the two decisions come apart. You are no longer choosing between paying whatever the renewal costs and running a stack that quietly expires at the next drive failure.
Decoupling the Storage Layer Before the Hypervisor
The move is to take the data off the hypervisor’s storage stack and put it on a storage layer that does not care which hypervisor version, or which hypervisor, sits in front of it.
Simplyblock runs as a software-defined storage layer that presents volumes over an NVMe fabric, using NVMe/TCP on standard Ethernet or NVMe/RoCE where the network supports it. Because it terminates storage outside the hypervisor, three things change at once:
- Drive qualification becomes yours again. The storage layer certifies its own hardware. Whatever NVMe devices are available and cost-effective in a given quarter can go into storage nodes, independent of whether they ever appear in a hypervisor compatibility guide. The frozen version’s snapshot list stops governing what you can buy.
- Compute and storage scale separately. Capacity growth stops dragging a licensed host purchase along with it, which matters when the license count is fixed and both component classes are inflating. Adding usable terabytes does not add hypervisor cores.
- The hypervisor decision becomes reversible. With volumes living on an external fabric and provisioned through CSI, the same storage serves VMs on your existing platform and containers or VMs on Kubernetes, KubeVirt, or Red Hat® OpenShift® Virtualization. Migration turns into re-attaching volumes to new consumers on your schedule instead of a copy-everything-at-once event. Our KubeVirt migration guide walks the destination-side mechanics, and the vSAN replacement on OpenShift post covers the storage layer swap specifically.
The licensing model matters to this argument, so it is worth being precise. 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 distinction is the whole point in this context: the storage layer has no capacity tiers and no bundle terms of its own, so densifying hardware to fight rising component prices never triggers a storage re-price, and the same licence follows the estate through a platform change instead of being stranded by it.
Practically, the sequence looks like this. Stand up the storage layer alongside the existing estate. Move the workloads whose data is largest and whose storage dependency is heaviest, since those are the ones that would otherwise dominate a later migration window. Let the perpetual licenses keep doing their job on a now much smaller storage-critical footprint. Then make the hypervisor decision on the evidence, with the renewal quote as one input rather than the deadline. When it is time, the platform comparison and the day 2 operations picture are both easier to assess, because storage has stopped being the variable that constrains every other choice.
None of this makes freezing an unsupported hypervisor a good long-term security posture. It is not. What it does is convert a decision made under a renewal deadline into one made on a hardware and workload timeline you control, which is usually the difference between a migration that goes well and one that goes fast.
Questions and Answers
Does a VMware perpetual license expire?
No. A perpetual license is a permanent right to run the licensed version on the licensed host or core count, and it does not lapse. What expires is the separate support and subscription contract, which supplies patches, version upgrades, new hardware certifications, and vendor support. New perpetual licenses are no longer sold, but that does not cancel entitlements already purchased.
What do you lose when VMware support expires but the perpetual license remains valid?
Security patches and bug fixes, the ability to upgrade to newer versions, newly certified hardware for your version, technical support escalation, and normally the portal access used to download builds. Everything currently installed keeps running. The most urgent practical step before a lapse is archiving a complete local copy of the exact builds, drivers, and firmware bundles you run, since the entitlement to a version does not include a way to obtain it later.
Is it safe to keep running VMware without a support contract?
It works, and it is legitimate provided you only run what you are entitled to. It is not a durable security posture, because unpatched hypervisor CVEs accumulate with no remediation path. The harder constraint is usually operational: your version’s certified hardware list is frozen, so the next drive or server refresh runs into components that were never qualified for the release you are pinned to.
Why does storage decide how long a frozen VMware estate stays usable?
Because vSAN is kernel-level functionality inside ESXi rather than a layer on top of it, so its device support and drivers move with the hypervisor version. You cannot extend the storage layer’s hardware support without upgrading the hypervisor, and an expired support contract is exactly what prevents that. Drives also fail on their own schedule, so replacement is not a purchase you can defer the way a compute refresh can be.
What is the best first step if the renewal quote is unacceptable but a full migration is not feasible yet?
Decouple the storage layer before the hypervisor. Moving data onto a software-defined layer that presents volumes over NVMe/TCP or NVMe/RoCE restores your freedom to buy whatever NVMe hardware is available, lets capacity scale without hitting a licence tier, and turns the eventual platform migration into re-attaching volumes rather than copying everything at once. 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.
