VMware vSphere Licensing Changes Under Broadcom
Standalone vSphere is gone from the catalogue for most customers. Per-core pricing replaced per-CPU. The product is now sold inside VVF or VCF. Here is what changed, why it matters, and what existing vSphere customers should do at their next renewal.
The vSphere product that existed before November 2023 and the vSphere product that exists today are licensed in fundamentally different ways. Standalone vSphere Enterprise Plus, the catalogue centrepiece for two decades, is no longer sold to most customers. The per-CPU pricing model that made vSphere economics intelligible at a glance has been replaced with per-core pricing. The Support and Subscription contract that customers attached to perpetual licenses has been phased out. And the product itself is now delivered inside one of two bundles — VMware vSphere Foundation (VVF) or VMware Cloud Foundation (VCF) — rather than as a standalone purchase.
For customers running vSphere at any scale, the licensing changes are not cosmetic. They affect renewal economics by factors of two to four times for typical environments, they constrain future product mix, and they shift the audit-risk profile materially upward. This guide covers what changed, why, and how to think about your next renewal event.
What was removed from the catalogue
The simplest way to understand the change is to list what disappeared. Standalone vSphere Enterprise Plus is no longer sold for new commercial deployments. The historic vSphere editions matrix — Standard, Enterprise Plus, Platinum, with various add-ons — has collapsed. Perpetual licenses are no longer available for any new vSphere purchase. New Support and Subscription contracts on existing perpetual licenses are not being issued; SnS renewals on perpetual entitlements ended in late 2024 for most regions. The retirement of these SKUs has been progressive across 2024 and 2025 and is essentially complete in the current catalogue.
vSphere Standard remains in the catalogue as a standalone option intended for small environments, with deployment caps that make it unsuitable for any meaningful enterprise estate. Some legacy SKUs persist in renewal motions for existing customers but are not offered to new customers. For practical purposes, if you are a typical enterprise customer with more than a few hundred cores of vSphere, your only realistic purchase paths are VVF or VCF.
What replaced it: VVF and VCF
vSphere is now delivered as a component of two bundles. The complete VMware licensing guide covers both in depth; the summary for vSphere-focused readers is as follows.
VMware vSphere Foundation (VVF)
VVF is the vSphere-centred bundle. It contains the vSphere hypervisor, a small quota of vSAN capacity (typically 100 GB per core), and a limited subset of Aria management tooling. It does not contain NSX. For customers whose primary VMware use is the vSphere hypervisor with traditional shared storage, VVF is the natural replacement for standalone vSphere Enterprise Plus and is what most pre-acquisition vSphere customers are being directed toward at renewal.
VMware Cloud Foundation (VCF)
VCF is the full-stack bundle. It contains vSphere, vSAN at full functionality, NSX, and the full Aria suite. VCF is positioned for customers running a multi-product VMware estate or building a private cloud. For pure-vSphere customers, VCF is typically over-buying; the additional bundled products are valuable only if the customer plans to deploy them.
VCF carries roughly two-times-or-more the per-core cost of VVF and bundles vSAN at full capacity, NSX, and full Aria. If you are not deploying these, you are paying for unused entitlements. The exception is customers who are credibly planning to deploy vSAN or NSX inside the term — in those cases, the bundle economics can be favourable. Make the decision against three-year forward requirements, not current state.
Per-core pricing replaces per-CPU
The unit of licensing for vSphere is now the physical core. The pre-acquisition model priced vSphere per physical CPU socket, with no upper bound on core count per socket. The current model prices per physical core, with a minimum of sixteen cores per socket even if the socket has fewer cores. This means a server with two sockets, sixteen cores per socket, requires thirty-two core licenses. A server with two sockets and twenty-four cores per socket requires forty-eight cores. A server with two sockets and eight cores per socket also requires thirty-two cores, because of the sixteen-core minimum.
The economic consequence is significant for customers running high-core-count modern servers. A pre-acquisition vSphere Enterprise Plus customer running dual-socket servers with thirty-two cores per socket was paying for two CPU licenses. Under the new model, the same server requires sixty-four core licenses. Even at a lower per-core list price than the per-CPU price divided evenly, the unit count increase typically produces a material cost increase. The combination of unit count growth, the move to subscription, and list-price changes is the source of the price increases customers report.
Conversion ratios from legacy entitlements
Customers renewing from per-CPU entitlements convert at a published ratio. The ratio has shifted across the catalogue's lifetime. Early renewals in 2024 saw conversion at eight cores per CPU. Later in 2024 the ratio shifted to sixteen cores per CPU. Negotiated outcomes in the field vary — well-prepared customers have secured better-than-published ratios, particularly on larger deployments. The conversion ratio is the single largest determinant of post-renewal cost for legacy-entitlement customers and is the variable most worth negotiating hard.
Subscription replaces perpetual
vSphere is now a subscription product. The historic perpetual model — buy the license outright, attach an annual SnS contract for support and updates — has been retired. Subscription terms are typically three or five years. The license expires at term end; without renewal, the customer cannot run supported vSphere in production.
Existing perpetual licenses remain valid — customers can continue running them indefinitely — but without an active SnS or subscription, they run unsupported. This is the choice many smaller customers have made: continue running existing perpetual vSphere unsupported, accepting the security and update risk in exchange for avoiding the cost of the subscription model. The practical viability of this depends on workload risk profile and on the timeline to a migration alternative.
Term commitments and price protection
Three-year terms attract modest discounts on headline pricing; five-year terms attract larger discounts. Longer terms also lock in pricing for that period, which is valuable as Broadcom has historically used renewal events to drive significant price increases. Securing explicit price-protection language for the term after this one — a defined cap on annual uplift, typically five to ten per cent, with a multi-year cumulative cap — is among the most important contractual provisions for vSphere customers.
The Support and Subscription change
Support has been restructured alongside licensing. The pre-acquisition SnS contract is no longer offered on perpetual entitlements. Customers with active SnS at the point of transition were given options to renew within a subscription bundle. Customers who did not renew now run unsupported on their perpetual licenses.
Inside the new subscription bundles, support is included. The historic tiering — Production, Premier, Mission Critical — has been consolidated. The current structure is a standard included support level plus a higher-tier offering with named contacts and faster non-Severity-1 response. The functional difference for typical customers is modest in Severity 1 cases (which Broadcom has continued to handle competently) and more pronounced in lower-severity issues, where response times have lengthened in customer reports.
Audit risk for vSphere customers under the new model
The audit-risk profile for vSphere customers is meaningfully higher than it was. Three drivers explain this. First, the per-core model multiplies the number of countable units, which multiplies the surface area for compliance gaps. Second, the conversion event from per-CPU to per-core has created a wide population of customers whose entitlements are ambiguous — what their per-CPU entitlement actually maps to in per-core terms depends on conversion ratios, transitional arrangements, and contractual language that varies customer-to-customer. Third, Broadcom's audit organisation is larger and more procedurally rigorous than VMware's was, and is operating on the analytical assumption that most VMware customers have not reconstructed their entitlement position post-conversion.
The practical consequence is that customers running vSphere should expect either an audit or an audit-adjacent compliance review within the first three years post-conversion. Our guides on the audit process and audit triggers cover this in detail. The single most valuable preparation is a current, defensible inventory of vSphere deployments mapped against entitlements under the conversion arithmetic.
The renewal decision for vSphere customers
For a vSphere-focused customer reaching a renewal event, the decision framework has four components.
VVF versus VCF
For pure vSphere use, VVF. For credible planned adoption of vSAN at scale or NSX, VCF may be economic. Decide against a three-year forward plan, not current state.
Core-count commitment
The committed core count for the term should reflect realistic three-year-forward consumption. Over-commitment is expensive and not recoverable in-term. Under-commitment requires mid-term true-up at less favourable pricing. Build the projection conservatively, with explicit provisions for divestiture-driven reductions.
Term length
Three years is the common choice for customers uncertain about VMware direction. Five years is appropriate for customers who are confident about staying. Customers actively planning migration alternatives should take three years.
Price protection
The renewal-event pricing for the term after this one is the most consequential contractual variable. Secure a defined cap on annual uplift and a multi-year cumulative cap. Without this, the next renewal is open-ended.
What vSphere customers should do in the next 90 days
Three practical actions are appropriate for any vSphere customer in the current environment.
First, reconstruct your entitlement position under the new model. Map your historic per-CPU entitlements to per-core entitlements at the conversion ratio in your contract. Identify any gaps, transition arrangements, or ambiguities. This is the foundation for any subsequent decision.
Second, build a current deployment inventory. Use vCenter as the source of truth, supplemented by procurement records and asset-management data. Map deployed cores against entitled cores. Identify discrepancies and resolve them before renewal or audit.
Third, model your renewal cost under VVF and under VCF. Build both scenarios using realistic discount assumptions based on engagement size. Compare both against the all-in cost of your current entitlements at current support rates. The comparison will frame your renewal negotiation.
Common vSphere-licensing mistakes to avoid
Across the engagements we have reviewed since the acquisition closed, the same handful of mistakes recur on the customer side of the licensing relationship. Knowing what they look like is the simplest way to avoid them.
Conflating logical CPUs and physical cores
The per-core licensing model counts physical cores in the host, not logical CPUs reported by the operating system. Hyperthreading does not double the licensing requirement; it does not change the licensing requirement at all. Customers who size their renewal against the logical CPU count reported by vCenter without disabling hyperthreading from the calculation typically overbuy by a substantial margin. The correct count is physical cores per socket, multiplied by sockets per host.
Missing the sixteen-core-per-socket minimum
The minimum applies even where the physical socket has fewer than sixteen cores. Customers running older hardware with eight-core or twelve-core sockets pay the full sixteen-core minimum per socket regardless. The correct strategy on aging hardware is not to absorb the minimum-cost penalty indefinitely but to plan refresh to higher-core-count modern hardware that uses the minimum efficiently, or to consolidate workloads onto fewer hosts.
Sizing against current-state rather than target-state
vSphere consumption is typically growing in enterprise estates — new workloads, new clusters, new business unit demand. Sizing the subscription against current-state core count almost always under-commits and produces mid-term true-ups at less favourable pricing. Sizing against target-state with a conservative growth assumption and explicit divestiture provisions is the more durable approach.
Accepting the standard contract template without negotiation
Broadcom's standard contract template is designed to maximise vendor flexibility and minimise customer protections. Provisions on audit notice, scope, data sharing, and renewal-time pricing are all default-set in Broadcom's favour. Each is negotiable. Customers who accept the template as-tabled forfeit value that is recoverable with modest negotiation effort.
vSphere licensing on edge and remote deployments
The standard per-core economics work poorly for edge deployments — small clusters at branch locations, retail sites, manufacturing floors, or remote-office sites. The sixteen-core-per-socket minimum and the bundle-only catalogue position make small-host licensing disproportionately expensive relative to the workload value.
For these deployments, three options are worth evaluating. The standalone vSphere Standard SKU, where available, can be appropriate for small edge clusters. Consolidation of edge workloads back to the central data centre is often economically rational once the edge licensing cost is fully loaded. Migration of edge workloads to alternative platforms — Hyper-V, Proxmox, or cloud-native edge platforms — is increasingly common for cost-pressured edge estates.
Capacity planning for the next subscription term
For customers committing to a multi-year vSphere subscription under VVF or VCF, capacity planning over the term is more consequential than it was under the perpetual model. Three planning dimensions matter most.
First, the committed core count needs to reflect realistic growth over the term. Under-commitment requires mid-term true-up at less favourable pricing; over-commitment is generally not recoverable. The right number is a conservative growth assumption built off current-state and forward demand, with explicit downside provisions for divestiture-driven contraction.
Second, the hardware refresh cycle interacts with licensing. New hardware typically has higher core counts per socket, which increases per-server licensing under the per-core model. Refresh planning should explicitly include the licensing-cost dimension; refreshing to higher-core-count hardware without expanding the licence commitment produces a compliance gap.
Third, workload consolidation should be planned in. The per-core model rewards consolidation: fewer hosts with higher utilisation pay less than more hosts with lower utilisation. Customers running at conservative utilisation levels — common in pre-acquisition vSphere estates — have meaningful room to reduce licensed-core count by improving utilisation, particularly through DRS tuning, vMotion-driven workload balancing, and right-sizing of guest VMs.
Related reading
For deeper coverage of related licensing topics, see the VMware licensing complete guide, the end of VMware perpetual licensing, the subscription conversion pricing guide, and VCF licensing explained. For the audit-defence dimensions, see our VMware audit defence guide.