A multi year rate lock freezes the core count too, and 10 to 25 percent of those cores could have been retired
Multi year commitments are sold as the way to hold the rate, and they do hold it. What nobody says out loud is that the commitment holds the core count with it, so a term signed before the consolidation work locks in every core you were going to retire.
Prepared by Redress Compliance · August 16, 2026 · Broadcom VMware advisory. 25 to 40 estates benchmarked, 2024 to 2025.
Executive summary
A multi year rate is a two part commitment. The discount is the part on the quote. The core count it is applied to is the part that goes unexamined, and it is fixed for the same three to five years.
10 to 25 percent of licensed cores sat on hosts consolidation could have retired. Estates licensed every populated core because that is what the hypervisor export shows, not because that is what the workload needed.
The per core minimum drags hardest on low core CPUs, lifting the effective rate on exactly the hosts a consolidation pass would have removed first.
Bundle mismatch compounds it. Customers bought VCF for features used on a fraction of the estate and then paid the full bundle across every licensed core, including the ones due for retirement.
How the vVF core math actually bills
vSphere Foundation licenses per physical core, not per socket and not per virtual machine, so the core count is the price. Everything else in the negotiation multiplies that number.
| Element | How it bills | Buyer impact |
|---|---|---|
| Per core license | Every physical core on a host running the software | Hypervisor exports overstate this, routinely |
| Per processor minimum | 16 cores per CPU, or actual cores if higher | Low core CPUs pay for capacity that does not exist |
| Bundle scope | vVF below VCF, narrower feature set | The gap between the two is the largest single lever |
| Subscription term | Annual or multi year, no perpetual option | Multi year holds the rate and the core count together |
The sequence matters more than any single number. A consolidation pass changes the core count. A term commitment fixes the core count. Run them in that order and the discount applies to a smaller base for the whole term. Run them the other way and you have bought a good rate on hardware you intended to decommission, with no mechanism to reduce the commitment until it expires. The rate is the number everyone negotiates; the base is the number that decides the bill.
What to fix before the term is signed
- Scrub the core inventory against the live estate first, because 10 to 25 percent of licensed cores in the estates we benchmarked sat on hosts that a consolidation pass could have retired.
- Consolidate onto denser hosts before you commit, since the per processor minimum penalises low core CPUs and those are the hosts a consolidation would remove first. Two savings, one exercise.
- Price vVF against VCF on your actual feature use, not on the bundle that covers every eventuality. Customers bought VCF for features used on a fraction of the estate and paid the full bundle across all cores.
- Model the multi year rate against a consolidation plan, not against today's footprint, so the committed core count reflects the estate you intend to run rather than the one you inherited.
- Ask what happens if the core count falls during the term, and get the answer in the paper rather than in a conversation. In most Broadcom terms the answer is nothing, which is precisely why the sequence matters.
- Treat right sizing as an ongoing discipline, because subscription converted a sunk cost into a recurring commitment. The core count is now a number you manage every year, not one you set once.
The Broadcom VMware negotiation brief
The bundle comparison, the per core arithmetic, the minimum core rule, and the renewal moves that hold against a Broadcom opening position.
Get the brief →A term discount is a rate lock and a baseline lock, sold as one thing
Multi year commitments are presented as the buyer's lever, and on the rate they genuinely are. Broadcom will hold a per core price across three or five years in exchange for the certainty, and for a stable estate that is a fair trade. The part that goes unexamined is that the commitment does not only fix the rate. It fixes the quantity the rate applies to, and a subscription has no mechanism to give quantity back mid term. You have therefore bought two things and negotiated one.
This matters because the quantity in a first Broadcom quote is almost always wrong in the same direction. Estates license every populated core, because that is what a hypervisor export produces and because nobody has been asked to distinguish hosts carrying workload from hosts that exist. Across the estates benchmarked through the transition, 10 to 25 percent of licensed cores sat on hardware that a consolidation pass could have retired. That is not an unusual finding, it is the normal condition of an estate that grew under per socket licensing where core count carried no price.
The per processor minimum then compounds the error in a way that is easy to miss. Low core CPUs bill at the floor regardless of what they actually contain, which lifts the effective rate on precisely the hosts a consolidation would eliminate first. So the cores most worth retiring are the cores costing the most per unit of work, and a term signed before the retirement locks that arithmetic in for the full commitment. Bundle mismatch sits on top: pay VCF rates across cores you meant to decommission and the three errors multiply rather than add.
The practical instruction is a sequence rather than a tactic, and it takes a quarter rather than a meeting. Scrub the inventory, consolidate what consolidation can reach, decide vVF against VCF on real feature use, and only then take the multi year rate against the resulting number. That ordering costs nothing and it is the difference between a discount on the estate you run and a discount on the estate you inherited. The point in time version of this arithmetic is in the 2026 cost breakdown, which covers licensing running cores rather than owned ones; this page is about what happens when you sign a term before doing that work. The bundle comparison sits in VCF against vSphere Foundation and the wider library in the Broadcom practice.
- RVTools in, core sizing out: three pricing scenarios across discount bands
- Renewal uplift exposure modeled over the full term, with the cap to ask for
- Every risky clause in the new paper flagged with replacement language
What the transition renewals showed, 2024 to 2025
Across roughly 25 to 40 VMware estates benchmarked through the Broadcom transition, the per core model reset every prior assumption:
Licensed cores sitting on hosts that a consolidation pass could have retired before the count was fixed.
The per processor floor, which lifts the effective rate on the low core CPUs a consolidation would remove first.
The third pattern was bundle mismatch. Customers bought VCF for features used on a fraction of the estate and then paid the full bundle across every licensed core. Combined with an unscrubbed count and a multi year term, that is three compounding errors held in place until the commitment expires.
Perpetual licences with optional support became subscriptions you must renew, which converts a sunk cost into a recurring commitment. Right sizing the core count stopped being a one time exercise the day that changed.
Watch the briefing · 4:44The VMware VCF Renewal: How to Prepare Before Broadcom Names the PriceThe core inventory and bundle mapping that has to happen before any term is committed.
Your first five moves
- Export the core inventory and reconcile it against hosts genuinely carrying VMware workload, separating populated cores from working ones.
- Run the consolidation pass before the quote, targeting low core CPUs first because they carry both the minimum drag and the retirement case.
- Decide vVF against VCF on measured feature use, component by component, rather than on the bundle that covers every eventuality.
- Model the multi year rate against the post consolidation core count, and compare it to an annual term at the same number.
- Get the mid term reduction position in writing before signing, so you know what a falling core count is worth. The Broadcom practice runs the scrub with you.
Frequently asked questions
What is VMware vSphere Foundation?
vVF is the packaged offering that bundles vSphere with vCenter and a defined management feature set under Broadcom. It sits below VMware Cloud Foundation in both scope and price, and it licenses per physical core on subscription rather than per socket on perpetual terms.
How does vVF licensing bill?
Per physical core, not per socket and not per virtual machine, with a per processor minimum of 16 cores. A CPU carrying fewer than sixteen cores still bills at sixteen, so the core count is the price and the hardware profile decides how much of it you pay for nothing.
Does a multi year commitment actually help?
On the rate, yes. It also fixes the core count that rate applies to for the same three to five years, and a subscription has no mechanism to hand quantity back mid term. So it helps when signed after the consolidation work and hurts when signed before it.
How much core inflation is normal?
Across the estates we benchmarked, 10 to 25 percent of licensed cores sat on hosts a consolidation pass could have retired. That is the normal condition of an estate that grew under per socket licensing, where core count carried no price and nobody had reason to scrub the inventory.
Why does the per core minimum matter so much?
Because it lifts the effective rate on low core CPUs, which are exactly the hosts a consolidation would remove first. The cores most worth retiring are therefore the cores costing most per unit of work, and a term signed early locks that arithmetic in.
When should we choose vVF over VCF?
When your measured feature use sits inside the vVF scope. The pattern we see is customers buying VCF for capability used on a fraction of the estate and then paying the full bundle rate across every licensed core, which compounds any error in the core count itself.
What happens if our core count falls during the term?
In most Broadcom terms, nothing. The commitment is to a quantity as well as a rate. Ask the question before signing and get the answer in the paper rather than in a conversation, because it decides whether consolidation during the term is worth funding.
What changed by moving off perpetual?
A sunk cost became a recurring commitment. Perpetual licences with optional support are gone, so right sizing the core count is now an ongoing annual discipline rather than a one time purchasing exercise, and every year you do not do it is a year you pay the inflated number.
