Broadcom / VMware Practice
Perpetual options, after Broadcom.
Your perpetual vSphere licenses still work. What ended is support renewal. Four options remain, and each has a defensible profile in 2026.
Your perpetual vSphere licenses still work. What ended is support renewal. Four options remain, and each has a defensible profile in 2026.
Broadcom ended perpetual license sales and support renewals, but the licenses themselves survive. Perpetual owners hold four options: run unsupported, buy third party support, convert to subscription, or migrate off.
Perpetual license owners hold a permanent right to run the licensed version, and that right survived the Broadcom transition; what they lost is the ability to renew support or buy new perpetual licenses. The transition details sit in Broadcom's own announcements and the Broadcom support portal.
Without active support, there are no new patches, no severity tickets, and no upgrade rights. The license runs; the safety net is gone.
Broadcom's own guidance confirms this position. Its knowledge base article on perpetual license functionality after SnS expiration states that ESXi hosts and vCenter keep operating normally, with vMotion, snapshots, and every licensed edition feature intact. What closes is the portal: no new patch downloads, no service requests, no major or minor releases.
One narrow lifeline survives expiry. Broadcom committed to providing critical zero day patches for vSphere 8.x perpetual customers with expired support contracts, defined as fixes for security alerts scoring 9.0 or higher on the CVSS scale.
Read the boundaries before relying on it. The commitment covers vSphere 8.x only, not 7.x or earlier. Everything scoring below 9.0 stays unpatched, and that 7.0 to 8.9 band is where most exploitable hypervisor CVEs land.
The decision clock is not the license; it is hardware refresh and CVE accumulation. Most stable clusters can run 2 to 4 years frozen before either forces a move.
Hardware sets the harder boundary. A frozen vSphere 8 build carries a frozen compatibility list, so a 2027 or 2028 server refresh can strand it on uncertified silicon. Plan the exit date around the refresh cycle, not the license paper.
Broadcom closed the VMware acquisition in November 2023 and announced the end of perpetual license and support renewal sales within three weeks, then kept adjusting terms every few months. The sequence matters because your plan has to survive the next change, not just the last one.
| When | What changed | What it meant for perpetual owners |
|---|---|---|
| Nov 2023 | Broadcom closes the VMware acquisition | Existing SnS contracts run to term but will not renew |
| Dec 2023 | End of sale announced for perpetual licenses and SnS renewals; the portfolio collapses into VCF and VVF subscriptions | The four options in this guide become the whole decision space |
| Jan to Feb 2024 | End of availability takes effect; the free ESXi hypervisor is discontinued | Entitlements freeze; labs and small sites lose the free tier |
| Apr to May 2024 | Zero day patch policy published for expired support on vSphere 8.x; support moves to the Broadcom portal | Critical fixes at CVSS 9.0 or higher stay reachable; everything else does not |
| Mar 2025 | VMSA-2025-0004 discloses three ESXi zero days exploited in the wild | Unsupported 7.x estates had no vendor patch path at all |
| Apr 2025 | A 72 core per order minimum and late renewal surcharges circulate through channel communications; a free ESXi edition returns with 8.0 Update 3e | Small orders and lapsed renewals get more expensive on paper |
| Jun 2025 | VCF 9.0 ships; vSphere 9 is available only inside VCF and VVF subscriptions | Perpetual 8.x owners have no upgrade path to 9 without converting |
| Late 2025 | The reported 72 core order minimum is walked back after customer pushback | Terms move in both directions; dated quotes go stale fast |
The buyer side lesson: most restrictive changes arrived through channel communications rather than contract amendments, and at least one was reversed under pressure. Treat any quote older than a quarter as stale.
One more signal deserves attention. Multiple enterprises reported cease and desist letters in 2025 after support expired, off limits patch reminders included, with audit rights reserved. The letters change nothing about the perpetual right itself, but they show Broadcom watches expired estates.
The four options are run unsupported, third party support, subscription conversion, and migration, and they are not mutually exclusive across an estate. The right answer is usually a portfolio split by workload criticality.
VMware perpetual options compared, 2026
| Option | Relative cost | Risk profile | Fits |
|---|---|---|---|
| Run unsupported | Near zero | CVE exposure grows over time | Stable, ring fenced clusters with exit dates |
| Third party support | 40 to 70 percent below subscription | No new versions; advisory based patching | Stable production needing a safety net |
| Convert to VCF or VVF | 2 to 5 times prior support spend | Full support; per core subscription lock | Strategic, growing virtualization core |
| Migrate off | Project cost now, lower run rate later | 12 to 24 month execution risk | Workloads with credible alternatives |
Broadcom sells VMware Cloud Foundation and vSphere Foundation per core with a minimum per CPU. Core dense hosts multiply the bill, so the conversion decision is a hardware density decision as much as a licensing one.
The counting rules are published. Broadcom's core counting guidance licenses every physical core across every host, with a floor of 16 cores per CPU. A two socket host on 8 core processors therefore licenses as 32 cores, double its physical count, while a two socket host on 32 core processors licenses as 64.
Storage entitlements shift the math between tiers. VCF includes 1 TiB of vSAN capacity per licensed core; VVF includes 0.25 TiB per core, with additional TiBs sold separately. Estates with heavy vSAN footprints sometimes find VCF closes the gap faster than the headline per core rate suggests, so model raw TiB deployed before picking the tier.
Hypervisor alternatives are production credible in 2026, but enterprise migrations run 12 to 24 months once tooling, operations retraining, and application validation are counted. The option is real only if started before renewal pressure peaks.
Budget beyond the hypervisor swap itself. Backup integrations, monitoring agents, DR runbooks, and automation pipelines all carry VMware assumptions, and each one is a workstream Broadcom prices against.
Every perpetual SKU maps to one of a handful of subscription offers, and that mapping fixes most of your quote before any discount conversation starts. Map to what you actually deployed, not to what the bundle sheet promotes.
| Perpetual product | Subscription path | What to check before signing |
|---|---|---|
| vSphere Standard | vSphere Standard subscription | Per core with the 16 core per CPU floor; feature set broadly unchanged |
| vSphere Enterprise Plus | VMware vSphere Foundation (VVF) | Bundles vCenter, Operations, and 0.25 TiB vSAN per core you may not use |
| vSphere plus vSAN | VVF plus vSAN capacity, or VCF | VCF includes 1 TiB per core; compare against raw TiB actually deployed |
| vSphere plus NSX or Aria Suite | VMware Cloud Foundation (VCF) | Full private cloud stack; count which components each cluster really runs |
| Site Recovery Manager | VMware Live Recovery, sold as an add on | Subscription only; confirm the metric on the quote against protected VM counts |
| Aria and vRealize Suite | VCF Operations and Automation inside VCF 9 | Standalone Aria subscriptions folded into VCF; no like for like renewal |
The trap sits in forced bundle upgrades. If one cluster uses NSX, mapping the whole estate to VCF pays for network virtualization everywhere. Carving that cluster out and mapping the remainder to VVF or vSphere Standard is often the single largest saving available in the negotiation.
Check the version door too. vSphere 9 ships only inside VCF and VVF subscriptions, so a cluster that needs 9.x features must map to one of those tiers. That is another argument for splitting the estate rather than converting it whole.
Third party providers take over severity response, configuration support, and security advisory coverage for a frozen VMware estate, at 40 to 70 percent below the Broadcom subscription quote on the stable tiers we benchmarked. The model is mature; it has operated in the Oracle and SAP world for well over a decade.
It does not fit estates that need new versions or vendor binaries. Providers cannot ship Broadcom patches or move you to vSphere 9; they mitigate around vulnerabilities rather than patch them, and they cannot restore portal entitlements.
Regulated buyers should test the compliance angle in diligence: the provider's written mitigations become your audit evidence under frameworks like PCI DSS. Ask for sample advisories before signing, and price the contract per tier rather than per estate.
The risk is real but tierable: an unsupported hypervisor accumulates unpatched CVEs, and the March 2025 ESXi zero days showed what that means. VMSA-2025-0004 disclosed three vulnerabilities, led by CVE-2025-22224 at CVSS 9.3, with exploitation already observed in the wild.
That advisory is the reference case for this decision. Perpetual vSphere 8.x owners could claim the fix under the zero day carve out; 7.x owners could not. A guest to host escape on an unpatched hypervisor is an estate level event, not a cluster level one.
Assume no vendor patches below the critical line. Broadcom restricts portal downloads to entitled customers, and 2025 brought reports of expired perpetual accounts losing download access they previously had. Below CVSS 9.0, the next high severity CVE on your frozen build will simply not be patched.
For regulated workloads the bar is documentation. Auditors under PCI DSS or DORA accept compensating controls when they are written, tested, and time bound. An undocumented unsupported cluster fails the assessment; the same cluster with a control sheet and an exit date usually passes.
Split the estate by workload criticality and hardware runway, then assign each cluster the cheapest option that meets its risk bar. Whole estate answers are almost always wrong in one direction or the other.
Run each cluster through four questions in order; the first no ends the branch and assigns the option.
The standard advice is that running unsupported hypervisors is reckless and conversion is the only responsible path. We disagree. In roughly a third of the VMware estates Fredrik Filipsson advised in 2024 to 2025, ring fenced stable clusters ran unsupported or on third party support with no production incident attributable to the choice, while saving 40 to 70 percent against the conversion quote. The buyer side move is risk tiering, not blanket conversion. Broadcom's pricing assumes fear does the negotiating; a tiered estate plan takes that lever away.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Broadcom priced the renewal assuming you have no plan. The estate that arrives tiered, with exit dates per cluster, pays a different number.
For the wider Broadcom picture, start with the Broadcom VMware advisory practice. For an always on review lane across all your vendors, see Vendor Shield.
Yes. Perpetual licenses grant a permanent right to run the licensed version, and that right survived the Broadcom transition. What ended is support renewal, patches, and upgrade rights.
It depends on the cluster. Stable, ring fenced, low change clusters with compensating controls ran without attributable incidents across our 2024 to 2025 engagements. Internet adjacent or fast changing clusters carry real CVE exposure.
Quotes in our engagement file ran 2 to 5 times prior support spend, priced per core with per CPU minimums. Core dense hosts multiply the bill, which makes hardware density the key cost input.
Yes, for stable estates. Providers deliver severity response and security advisories at 40 to 70 percent below subscription cost. The trade is no new versions and advisory based rather than vendor patching.
Twelve to twenty four months at enterprise scale, counting tooling, operational retraining, and application validation. The option is only real if started before the renewal deadline removes your calendar.
No, with one narrow exception. Broadcom restricts portal downloads to active entitlements, but critical zero day fixes scoring 9.0 or higher on CVSS remain available for vSphere 8.x perpetual customers. Everything below that threshold requires a subscription or a documented mitigation.
Yes. The audit clause in the perpetual license agreement survives support expiry, and the cease and desist letters reported in 2025 explicitly reserved audit rights. Keep entitlement proofs, deployment records, and core counts current even on frozen clusters.
VVF is enough for estates running vSphere plus moderate vSAN. It bundles vSphere, vCenter, Operations, and 0.25 TiB of vSAN per core; VCF adds NSX, Automation, and 1 TiB per core. Map each cluster to what it actually runs, not to the promoted bundle.
It circulated through channel communications in April 2025 and was walked back later that year after customer pushback. The durable published rule is the 16 core minimum per CPU. Confirm current minimums on the quote itself, because Broadcom terms keep moving.
Not with new licenses; Broadcom no longer sells perpetual entitlements. You can redeploy unused existing entitlements within your license terms, but net growth requires subscription licensing or an alternative platform. Growth clusters are usually the first conversion or migration candidates.
Subscription tiers, core counting math, third party support decision model, and the tiered estate strategy for perpetual owners.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
