Broadcom VMware licensing.

What Broadcom actually changed.

Broadcom completed its acquisition of VMware in November 2023 and, within weeks, replaced the entire commercial model. The change has three load-bearing parts: perpetual licences were withdrawn from sale and replaced by term subscriptions; the long product catalogue was collapsed into a small number of bundles, principally VMware Cloud Foundation and vSphere Foundation; and pricing moved decisively to a per-core basis with a 16-core-per-CPU minimum. For most buyers the combined effect at the first renewal under the new regime has been a substantial increase in annual cost, frequently in the range of two-to-five times the prior outlay and considerably more for estates that ran low-core-count hardware or held only a narrow vSphere entitlement.

Admodum is an independent, buyer-side software licensing advisory. We represent the organisation that buys VMware, never Broadcom, and we hold no reseller margin, referral commission or partner status. This pillar page sets out the post-acquisition licensing model in full so that a procurement leader can read a Broadcom quote, understand why the number is what it is, and identify the levers that remain. The deeper mechanics live in five companion pages, linked throughout: the end of VMware perpetual licences, VMware Cloud Foundation versus vSphere Foundation, the 16-core-per-CPU subscription minimum, VMware support, SnS and the named-account model, and how to read a Broadcom VMware renewal quote.

Perpetual is gone: what subscription means.

Under the historic model a buyer purchased a perpetual licence — a one-time payment that conferred a permanent right to run the software — and then paid an annual Support and Subscription (SnS) fee, typically around a fifth of the licence price, for updates and technical support. Stop paying SnS and the software still ran; you simply lost updates and support. The capital sat on the balance sheet as an asset and the marginal cost of continuing to run was low.

A subscription inverts that. The buyer pays an annual or multi-year term fee for the right to run the software at all, with support and updates included. Stop paying and the right to run lapses. There is no permanent asset; the entire cost recurs every term. This is the single largest reason the renewal number jumps: under the old model the buyer who had already paid for perpetual licences was only renewing SnS, perhaps a fifth of licence value each year. Under the new model that same buyer is paying for the licence itself, every year, in full.

The transition mechanics — what happens to existing perpetual entitlements, whether they can still be run, and how Broadcom positions the move at renewal — are covered in detail at the end of VMware perpetual licences.

The two bundles: VCF and VVF.

Broadcom collapsed dozens of standalone VMware products and editions into a short bundle catalogue. The two that matter for the overwhelming majority of buyers are VMware Cloud Foundation and vSphere Foundation.

VMware Cloud Foundation (VCF)

VMware Cloud Foundation (VCF) is the full private-cloud bundle. It combines vSphere for compute virtualisation, vSAN for software-defined storage, NSX for software-defined networking and security, and the Aria suite for management, automation and operations, into a single integrated software-defined data centre stack. VCF carries the highest per-core price and is positioned at organisations running, or intending to run, a complete private cloud. Its vSAN storage allowance is generous and bundled at a per-core ratio that suits storage-heavy estates.

vSphere Foundation (VVF)

vSphere Foundation (VVF) is the smaller bundle for organisations that primarily need compute virtualisation with operations management, but not full networking and automation. VVF includes vSphere, vCenter, a capped vSAN allowance — historically around one tebibyte of vSAN capacity per core licensed, far less than VCF — and Aria operational tooling. It sits at a lower per-core price than VCF and is the natural landing place for estates that previously ran vSphere Standard or Enterprise Plus without the wider stack.

Choosing the wrong bundle is one of the most expensive mistakes available in a Broadcom renewal: VCF priced across an estate that only needs VVF inflates cost with no benefit, while VVF chosen for an estate that genuinely runs vSAN and NSX at scale can leave the buyer re-purchasing components separately. The full comparison, including the vSAN allowance arithmetic and the add-on path, sits at VMware Cloud Foundation versus vSphere Foundation.

The bundle catalogue also explains why so many legacy line items disappeared. vSphere Standard, vSphere Enterprise Plus, vSAN as a standalone product, NSX Data Center, the vRealize and Aria components and a long tail of editions no longer exist as separate purchasable SKUs for most buyers; they have been folded into VCF and VVF or, in a few cases, offered as add-ons. A buyer reconciling an old entitlement against a new quote will not find a like-for-like mapping line by line, which is precisely why the renewal feels opaque. The correct method is to start from what the estate actually runs — compute only, or compute plus storage, or the full software-defined data centre — and map that consumption to the bundle that covers it, rather than trying to trace each historic SKU into the new catalogue.

Per-core pricing and the 16-core minimum.

Both bundles are priced on a per-core subscription basis: the buyer licenses every physical core in every server that runs the software, and pays an annual subscription fee per core. This replaced the older per-CPU-socket model, under which a populated socket was licensed regardless of how many cores it held.

The decisive twist is the 16-core-per-CPU minimum. Broadcom requires that every populated CPU socket be licensed for at least sixteen cores, even when the installed processor has fewer. A server with two physical processors of eight cores each holds sixteen physical cores, but is billed as if it held thirty-two, because each socket is rounded up to the sixteen-core floor. The minimum is, in effect, a penalty on low-core-density hardware and a reward for consolidation: an estate running many small, older, low-core servers pays disproportionately, while an estate running fewer, denser processors pays closer to its real core count.

This single rule reshapes capacity planning and hardware refresh economics. The buyer who consolidates workloads onto fewer high-core-count hosts before renewal can materially reduce the billed core count; the buyer who renews against a sprawl of two-socket, eight-core boxes pays the minimum on every one of them. The full arithmetic, worked examples and the consolidation playbook sit at the 16-core-per-CPU subscription minimum.

What sits inside each bundle.

The value, and the trap, of the bundle model is that it forces a single price across a fixed component set. Understanding what is included answers the recurring buyer question: am I paying for products I do not use?

VCF bundles the complete stack — vSphere, vSAN, NSX and Aria — at a single per-core price. For an organisation genuinely running software-defined storage and networking, this can be cheaper than buying the components separately under the old model. For an organisation that ran only vSphere, it means paying for NSX and a large vSAN allowance that may never be switched on. VVF bundles vSphere, vCenter, a capped vSAN allowance and Aria operations, omitting NSX and the full automation suite; it is the leaner fit for compute-led estates, but its smaller vSAN allowance can require a separately licensed vSAN add-on for storage-heavy clusters.

Two features deserve specific mention because they anchor buyer questions. vMotion — the live migration of a running virtual machine from one physical host to another with no downtime — remains a core capability of vSphere and is therefore present in both bundles; it is not a separately gated add-on. High availability, distributed resource scheduling and the core clustering features likewise travel with vSphere. What differs between the bundles is the surrounding storage, networking and automation, not the compute fundamentals. Where a buyer needs more vSAN capacity than the bundle allows, or NSX on a VVF estate, those are bought as priced add-ons rather than by stepping the whole estate up to the more expensive bundle.

The practical discipline is to separate the question of capability from the question of consumption. Almost every estate that ran VMware before the acquisition was entitled to a wide range of features it never switched on, because the old per-edition model bundled generously. Under the per-core subscription, the buyer pays for the bundle whether or not the components are used, so the only way to recover value is to either use the components — genuinely migrating storage onto vSAN, or networking onto NSX, to retire third-party tools — or to right-size down to the bundle that omits them. Paying VCF rates for an idle NSX entitlement is pure leakage; so is buying a vSAN add-on for capacity that already sits within the VCF allowance. Mapping consumption cluster by cluster is what turns the bundle decision from a guess into an evidenced choice.

Support, SnS and the named-account model.

Under the old model, support and updates were bought as a separate annual Support and Subscription (SnS) contract layered on top of the perpetual licence. Under the Broadcom model, support and updates are included in the subscription price; there is no longer a separable SnS line. The change is more than cosmetic, because it removes the buyer's historic option to drop support to save cost while continuing to run.

Broadcom has also restructured how support is delivered. The largest customers are managed directly under a named-account model, while smaller customers are routed to the channel — VMware's authorised resellers and partners — for both purchasing and front-line support. For organisations accustomed to a direct VMware account team, this can mean a less direct relationship and a renewal conducted through a partner rather than the vendor. The practical implications for support entitlement, escalation and renewal leverage are set out at VMware support, SnS and the named-account model.

For procurement the named-account distinction matters beyond the support desk, because it changes who controls the commercial conversation. A buyer inside the named-account tier negotiates with a Broadcom account team that can move on price within sanctioned bands; a buyer outside it negotiates with a reseller whose margin depends on the deal size, and who may have limited authority to discount. Knowing which side of the line an organisation sits on, and whether the renewal can be escalated to a direct conversation, is itself a piece of leverage. The loss of the separable SnS line also removes a tactic buyers used in the perpetual era — dropping support on stable, low-risk workloads to save cost — so the only remaining route to lower the support component is to reduce the licensed footprint it is calculated against.

Why the renewal price shocked the market.

The increases reported across the market are not the product of a single price rise; they are the compound effect of three structural changes landing at once. Reading them separately is the first step to negotiating any of them.

First, the move from perpetual-plus-SnS to full subscription re-prices the licence itself every year, as set out above. Second, the 16-core-per-CPU minimum inflates the billed core count on any estate that is not built from high-core-density hardware. Third, bundle consolidation pushes a buyer who previously licensed only vSphere into VCF or VVF, paying for a wider component set. An estate can be hit by all three simultaneously: a vSphere-only customer on two-socket eight-core servers, moving from SnS-only renewals to a full VCF subscription billed at the 16-core minimum, sees each factor multiply against the others.

For procurement, the value of decomposing the increase is that each factor has a different counter. The subscription shift is irreversible but its term length, ramp and discount are negotiable. The core minimum is addressable through hardware consolidation. The bundle choice is addressable by right-sizing VCF down to VVF where the wider stack is unused. The full line-by-line method sits at how to read a Broadcom VMware renewal quote.

Co-term, true-forward and multi-year terms.

Subscription contracts introduce timing mechanics that perpetual buyers rarely had to manage. Two recur in every Broadcom negotiation: co-termination and true-forward.

Co-termination aligns the end dates of multiple subscriptions to a single renewal date, so that add-ons purchased mid-term expire alongside the original term rather than running their own clock. It simplifies administration but concentrates all leverage and all spend into one renewal event, which the vendor prefers. True-forward is the mechanism by which usage growth during a term is reconciled: where an estate grows beyond its licensed core count mid-term, the additional cores are charged from the point of growth forward, rather than retroactively back to the start of the term, and the renewal baseline steps up to include them. Unlike a true-up, which can claw back retroactively, true-forward is forward-looking — but it still ratchets the baseline upward and rarely steps back down when usage falls.

The interaction of term length, co-termination and true-forward determines how much flexibility a buyer retains across a multi-year deal. A long term with aggressive co-termination and an unfavourable true-forward clause can lock an estate into a rising baseline with no annual exit. These mechanics, and the clauses to negotiate, are examined in the exit-strategy cluster at VMware co-term and true-forward mechanics.

The defensive position for a buyer is to treat term length as a discount lever rather than a default. A three-year term will attract a larger headline discount than a one-year term, but it also fixes the per-core rate, the bundle and the baseline for the full period, removing any annual opportunity to right-size as workloads change. Where an estate is stable and consolidation has already been completed, a longer term can be rational; where the estate is in flux, or where a migration is genuinely under evaluation, the flexibility of a shorter term is often worth more than the discount foregone. The point is to choose the term deliberately, with the true-forward and co-termination clauses read in full, rather than accepting the multi-year proposal because it shows the lowest annual figure.

The compliance surface under Broadcom.

A subscription model with a hard per-core minimum and bundle-defined entitlements creates a sharper compliance surface than the perpetual era. The buyer must be able to demonstrate that licensed cores match deployed cores, that the bundle in use matches the bundle paid for, and that add-on consumption sits within entitlement.

Broadcom has signalled a more assertive posture on compliance than VMware historically took, and the consolidation of products into bundles makes mismatches easier to detect: running NSX or a large vSAN footprint on a VVF entitlement, or exceeding the licensed core count after a hardware change, are the kinds of gaps a review will surface. The buyer-side discipline is to maintain a current reconciliation of physical cores per host, bundle entitlement per cluster, and add-on usage, so that any review is met with the buyer's own evidence rather than the vendor's inference. The audit playbook, including what a Broadcom review tends to examine and how to prepare, sits at VMware audit and compliance under Broadcom.

The subscription model also closes a gap that perpetual buyers relied on. Under perpetual licensing, an estate that drifted slightly over its entitlement could often be corrected quietly at the next true-up with limited consequence, because the licence asset was already owned. Under subscription, the right to run is contingent on a current term, and a lapse or an over-deployment is a live compliance exposure rather than a deferred accounting adjustment. This raises the cost of poor record-keeping: the buyer who cannot evidence its core count and bundle usage on demand negotiates from a position of uncertainty, and uncertainty in a Broadcom review tends to be resolved in the vendor's favour. Keeping the reconciliation current is therefore not housekeeping but a commercial control.

A worked example of the price shock.

The mechanics are easier to hold against a concrete estate. Consider a mid-sized buyer running twenty two-socket hosts, each populated with two sixteen-core processors, licensed historically under vSphere Enterprise Plus on a per-socket basis with annual SnS.

Under the old model, the buyer had long ago paid the perpetual licence cost and was renewing only SnS each year — roughly a fifth of licence value — for forty CPU sockets. The annual cash outlay was modest because the licence asset was already owned. Under the Broadcom model, the same estate is licensed per core: twenty hosts, forty sockets, sixteen cores per socket, gives 640 physical cores, all of which now attract a full annual subscription fee rather than a fractional support fee. Because the processors are sixteen-core, the 16-core minimum does not inflate the count further in this case; the penalty would bite harder on eight-core or twelve-core hardware, where the count would round up.

Layer on the bundle decision. If this buyer ran only vSphere, moving to VVF licenses 640 cores of compute virtualisation; moving to VCF — whether by choice or because the renewal is framed around it — licenses 640 cores of the full stack including vSAN, NSX and Aria, at the higher per-core rate, much of which may go unused. The compound result is the two-to-five-times increase reported across the market: the licence is now priced in full annually, the per-core base is large, and the bundle may carry components the estate does not run. The arithmetic shows where the counters apply: consolidate the twenty hosts onto fewer denser servers to cut the core count, and right-size the bundle to VVF if the wider stack is genuinely idle.

The mistakes buyers make.

Across documented engagements, the same avoidable errors recur in Broadcom VMware renewals. Naming them is the cheapest form of preparation.

The first is accepting the billed core count without verifying the physical inventory. Quotes are frequently built from stale or over-stated asset records, and the 16-core minimum makes every uncounted or decommissioned host expensive; a current, verified core inventory is the precondition for every other lever. The second is defaulting to VCF when the estate only uses vSphere — paying for vSAN, NSX and Aria that will never be switched on — because the renewal was framed exclusively around the full bundle. The third is treating the multi-year term as free money: taking the headline discount without reading the true-forward and co-termination clauses that fix a rising baseline for the period.

The fourth, and most consequential, is negotiating without a credible alternative. Broadcom's list pricing assumes the buyer has nowhere to go, and a renewal conducted on that assumption concedes the largest single source of leverage. A costed migration or hybrid plan — even one the buyer ultimately chooses not to execute — changes the conversation, because it makes the threat of departure real. The fifth is leaving the renewal to the incumbent reseller without independent scrutiny, particularly under the named-account and channel model, where the party quoting the deal also earns from it. Each mistake has a direct counter in the six artefacts set out below, and each is recoverable with enough lead time before the renewal date.

The companion exit pillar develops the alternative in full at VMware exit and renegotiation strategy, the business case at building the VMware exit business case, and the negotiation choreography at the VMware renewal negotiation playbook.

What the buyer holds at renewal.

A procurement leader walking into a Broadcom VMware renewal should hold six artefacts. Each one converts a vendor assertion into a buyer-controlled fact.

First, a verified physical-core inventory per host, with the 16-core minimum applied, so the billed core count can be checked rather than accepted. Second, a consolidation model showing the core count achievable by packing workloads onto fewer, denser hosts before the term begins. Third, a product-usage map against bundle contents, identifying whether the estate genuinely needs VCF or can be right-sized to VVF. Fourth, a renewal model under each bundle and term length, so the trade-offs are quantified. Fifth, a documented alternative — a costed migration or hybrid option — because a credible exit is the strongest single lever in a Broadcom negotiation. Sixth, a clause review covering co-termination, true-forward and term length, so the deal does not lock in a rising baseline.

The renewal moment routes to the Renewal Programme; the wider engagement sits at the Broadcom / VMware practice; the aggregated reading list sits at the Broadcom knowledge hub and the cluster index at the Broadcom and VMware hub. Where the answer is to leave rather than renew, the companion pillar covers the route end to end at VMware exit and renegotiation strategy, with the alternatives at VMware alternatives: Nutanix, Hyper-V, Proxmox and cloud. Engagement opens at contact.