VMware ESXi & vSphere:
a support clock plus a licensing upheaval

Anyone running VMware ESXi or vSphere in 2026 is tracking two separate clocks that happen to be ticking at the same time. The first is the ordinary software lifecycle: vSphere 7.x's general support already ended, and vSphere 8.x's is coming. The second is not a lifecycle event at all — it's Broadcom's restructuring of how VMware is licensed and sold since acquiring the company, which changes what "staying supported" even costs, independent of which version you run. Treating these as one problem, or ignoring either one, is how teams end up surprised.

The Version-by-Version Dates

These figures come from Broadcom's own knowledge base articles on vSphere lifecycle, plus independently reported coverage of the extension Broadcom granted to vSphere 7.x. Confirm the current numbers against Broadcom's live product lifecycle matrix before making a purchasing or migration decision — Broadcom has already moved one of these dates once, and lifecycle pages get updated without much fanfare.

On vSphere 7.x specifically: the end of general support date was originally set for April 2, 2025 — five years after general availability, following VMware's standard cadence. Broadcom extended that window six months, to October 2, 2025, which has now passed. vSphere 8.x's general availability was October 11, 2022; a five-year-from-GA cadence would put end of general support around October 11, 2027, which is the figure most commonly cited, but Broadcom has not committed to that pattern being fixed the way Microsoft's Fixed Lifecycle Policy is — this date should be treated as the best current estimate, not a guarantee, and re-verified periodically on Broadcom's lifecycle matrix.

For the live, continuously updated version table across every ESXi release, see our ESXi lifecycle page.

EoGS vs. EoTG — What Each Phase Actually Means

Broadcom's vSphere lifecycle, like VMware's before it, has two distinct end-of-life phases, and conflating them is a common and costly mistake.

The trap is assuming Technical Guidance is a continuation of normal support with a different name. It is not. During EoTG, you can still open a ticket and get pointed at a knowledge base article, but there is no committed patch cadence and no guarantee that a newly discovered vulnerability gets fixed — Broadcom decides case by case whether a fix is severe enough to warrant one. For a hypervisor sitting under production workloads, planning to run through the entire EoTG window as if it were still "supported" understates the actual exposure.

The Broadcom Licensing Shift

Separate from the version lifecycle, Broadcom restructured how VMware software is sold shortly after closing its acquisition of the company. This has been widely reported across trade press and directly confirmed in Broadcom's own communications to customers and partners.

• Perpetual licenses stopped selling As of December 2023, Broadcom no longer sells new VMware perpetual licenses or Support and Subscription (SnS) renewals. The entire portfolio moved to subscription and term-license sales only.
• Existing perpetual customers are grandfathered — until their support lapses Customers on perpetual licenses with active support contracts remain supported per those contract terms. But once an existing SnS contract expires, it cannot be renewed — the only path forward on that license is moving to a subscription product, generally with a trade-in incentive from Broadcom.
• The practical effect: two clocks converge A perpetual-license customer whose SnS support happens to expire around the same time their vSphere version hits end of general support faces both events at once — a forced licensing conversation and a version upgrade decision, together, with no option to simply renew the old arrangement.

Your Realistic Options

Three paths are commonly evaluated, and none of them is obviously correct for every environment:

• Renew under Broadcom's subscription model Keeps the existing VMware skill set, tooling, and integrations intact. Requires accepting the new licensing terms and, for many customers, a materially different cost structure than the old perpetual-plus-SnS model.
• Migrate to Microsoft Hyper-V A natural fit for shops already deep in the Microsoft stack, particularly with Windows Server licensing already in place. Feature parity with vSphere's more advanced capabilities (like certain HA/DRS behaviors) varies by workload and needs direct evaluation, not an assumption of drop-in equivalence.
• Migrate to Nutanix AHV Positioned as a hyperconverged alternative with its own licensing model, often evaluated by customers already running Nutanix storage or considering an HCI consolidation alongside the hypervisor move.
• Migrate to Proxmox VE An open-source KVM-based option with a genuinely different cost model and a smaller but growing enterprise support ecosystem. See our Proxmox VE lifecycle page for its own version and support timeline. Migration effort from ESXi varies significantly by VM count, storage architecture, and how much automation currently depends on vSphere-specific APIs.

None of these is a neutral default. The right call depends on existing licensing commitments, in-house expertise with each platform, storage architecture, and how much operational tooling is built around vSphere-specific APIs (vCenter automation, vSAN, NSX integrations, and similar). A realistic evaluation weighs migration effort against the actual cost delta of the new VMware subscription terms — for some environments, staying on VMware under the new model is still the lower-effort, lower-risk path; for others it isn't.

Risk Framing, Honestly

A hypervisor sitting past end of general support is a different category of risk than most end-of-life software, because of what runs on top of it. ESXi hosts typically carry many guest VMs across multiple applications and teams — a single unpatched hypervisor vulnerability can be a much larger blast radius than an unpatched application server. That argues for treating the vSphere 7.x EoGS date (already passed) and the approaching vSphere 8.x date with more urgency than a similarly-dated single-application EOL, not less.

At the same time, "unsupported" is not synonymous with "actively exploited today." A well-segmented, patched-as-of-EoGS vSphere 7.x environment with restricted management-plane access is a materially different risk than an internet-exposed, unpatched one. The honest framing is: end of general support removes your vendor's ongoing commitment to fix newly found vulnerabilities — it does not retroactively break what's already patched, and it does not mean compromise is imminent. It does mean the clock on your specific exposure only grows from here, with no vendor patch coming to shrink it back down.

Your Action Checklist

• Inventory every ESXi host and vCenter instance by versionConfirm exact build numbers, not just major version — patch level affects both support status and available upgrade paths.
• Check your Support and Subscription renewal date separately from your vSphere versionA perpetual license with lapsed SnS cannot be renewed under any circumstances — that clock matters independently of end-of-general-support dates.
• Re-verify current EoGS/EoTG dates on Broadcom's live lifecycle matrixBroadcom has adjusted these dates before. Do not plan a migration against a figure you haven't confirmed within the last few months.
• Get a real quote under Broadcom's current subscription termsBefore evaluating alternatives, know the actual cost of staying — comparisons against a vague sense of "VMware got expensive" lead to worse decisions than comparisons against a real number.
• Scope a genuine migration estimate for at least one alternativeHyper-V, Nutanix AHV, or Proxmox VE — pick based on existing skills and infrastructure, and get a real effort estimate rather than assuming any of them is a drop-in replacement.
• Prioritize hosts by blast radius, not by convenienceHosts carrying the most guest VMs, the most sensitive workloads, or the most external exposure should move first regardless of which decision (renew or migrate) you ultimately make.
• Document the decision and date for your risk registerWhether you renew, migrate, or run out the Technical Guidance window deliberately, put the reasoning and the date in writing before an auditor or incident forces the conversation.

Frequently Asked Questions

When did vSphere 7.x reach end of general support?

October 2, 2025. This date applies to ESXi 7.x and vCenter Server 7.x, both of which shipped April 2, 2020. The original end of general support date was April 2, 2025; Broadcom extended it six months to October 2, 2025.

When does vSphere 8.x reach end of general support?

Broadcom's published date is October 11, 2027, with end of technical guidance following two years later, October 11, 2029. Confirm the current figure on Broadcom's own lifecycle matrix before budgeting against it, since Broadcom has adjusted vSphere support windows before.

What is the difference between end of general support and end of technical guidance?

End of general support (EoGS) is when new patches, updates, and standard support requests stop. End of technical guidance (EoTG) is a further period — typically about two years past EoGS — where Broadcom will still answer support questions and point to existing self-help content, but issues new patches only in rare, severe cases. Neither phase includes new features or guaranteed security fixes for newly discovered vulnerabilities.

Can I still buy a perpetual VMware license?

No. Broadcom stopped selling new VMware perpetual licenses and Support and Subscription (SnS) renewals in December 2023, moving the portfolio to subscription-only sales. Existing perpetual-license customers with active support contracts remain supported per their contract terms, but once that support lapses, renewal is not available — only a move to a subscription product.

What are the alternatives if I don't want to stay on VMware?

The commonly evaluated alternatives are Microsoft Hyper-V, Nutanix AHV, and open-source options like Proxmox VE. Each has a different licensing model, feature set, and migration effort from ESXi/vSphere — there is no single drop-in replacement, and the right choice depends on workload type, existing tooling, and in-house expertise.