Every core added inside a Broadcom ELA trues up at list unless the growth band was pre negotiated
The discount you win at signature applies to the cores in the product schedule. Every core added after it is priced under the true up clause, and the default methodology there is list. A three year agreement with growth in it therefore has two prices, and buyers negotiate one.
Prepared by Redress Compliance · August 16, 2026 · Broadcom VMware advisory. 20 to 30 ELA negotiations run, 2024 to 2025.
Executive summary
True up runs at list price by default. Pre negotiate the growth discount or lock additions to the original band, because a discount agreed at signature does not automatically travel to cores added in year two.
Renewal uplifts landed at 2 to 5 times the prior perpetual support stream, driven by the move from perpetual licences to subscription bundles rather than by any single rate change.
Core counts were overstated 10 to 25 percent against consolidated host capacity, so the discount was frequently applied to a quantity that should not have been in the schedule at all.
Cloud Foundation bundles were sold in where 30 to 50 percent of components went unused, which is the scope question the product schedule decides and the discount conversation never reaches.
The four components, and which of them are negotiable
A Broadcom ELA carries four moving parts. Buyers concentrate on the first and sign the fourth without amendment, which is exactly the wrong order of attention.
| Component | Definition | Negotiable |
|---|---|---|
| Product schedule | VCF, vSphere Foundation, vSphere Standard, add ons | Yes, both the mix and the core counts |
| Term | Three years is the default, five years possible | Yes, with price impact in both directions |
| Support tier | Production 24x7 or non production business hours | Yes, and it should be set by environment |
| True up clause | Annual or term end true up on growth above baseline | Yes, both methodology and discount |
The true up clause is where a good deal quietly stops being one. Growth above the baseline in the product schedule is priced under this clause, and the default methodology prices it at list. An estate that negotiated a strong band at signature and then grew 15 percent over three years has bought the growth at a materially worse rate than the original purchase, inside an agreement that reads as though it had one price. Pre negotiate the growth discount, or lock additions to the original band, and get the methodology written rather than described.
What to fix before the schedule is fixed
- Right size the cores before they enter the product schedule, because counts were overstated 10 to 25 percent against consolidated host capacity in the negotiations we ran, and the schedule is what the whole agreement is built on.
- Challenge the bundle on measured component use. VCF was sold in where 30 to 50 percent of the components went unused, and the ELA prices bundle scope whether or not you consume it.
- Set the support tier by environment, production 24x7 where the workload warrants it and non production business hours elsewhere, rather than accepting a single tier across the estate.
- Negotiate the true up methodology and its discount at signature, since it is the only price in the agreement you will pay without a negotiation attached to it.
- Model multi year prepay both ways. It can hold price and it locks in scope, so the certainty is worth having only once the core count and bundle mix are right.
- Keep an alternative live through the term, because Nutanix, OpenShift Virtualization, Proxmox, and Hyper V each open leverage that a signed ELA otherwise closes off until renewal.
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 →An ELA has two prices, and buyers negotiate one
An enterprise agreement is bought for certainty, and Broadcom ELAs do deliver it on the baseline. What buyers frequently do not price is that the agreement contains a second commercial mechanism operating on different terms. The product schedule sets a quantity and a negotiated rate. The true up clause sets what happens to everything above that quantity, and its default methodology is list. Any estate that grows during the term is therefore buying at two prices, and in most of the negotiations we ran only the first had been argued.
The asymmetry is easy to miss because the two mechanisms are separated by time rather than by document. At signature, growth is hypothetical and the discount is concrete, so attention goes where the number is. Eighteen months later the growth is real, the discount conversation is over, and the clause governing the addition was agreed in a paragraph nobody costed. Modest growth is enough for this to matter: on a three year term, an estate expanding at a normal rate can find that a meaningful share of its total spend was transacted at a rate it never negotiated.
Underneath that sits the more basic problem, which is that the baseline itself was usually too large. Core counts were overstated 10 to 25 percent against consolidated host capacity, and Cloud Foundation bundles were sold in where 30 to 50 percent of components went unused. Those two errors set the quantity and the scope that the whole agreement is priced from, and a strong discount applied to an inflated schedule still produces a bad agreement. Sequence matters here as much as it does on the term commitment: right size the cores and challenge the bundle before the schedule is fixed, because the schedule is not a description of your estate, it is the definition of what you have agreed to pay for.
Two moves follow. Negotiate the true up methodology and its discount at signature, so growth is priced at the band you argued rather than at the band you did not. And keep a genuine alternative live through the term, because Nutanix, OpenShift Virtualization, Proxmox, and Hyper V each open leverage that a signed multi year agreement otherwise closes off until renewal. The per core arithmetic sits in the 2026 cost breakdown, the conversion economics in perpetual against subscription, and the wider library in the Broadcom practice.
- Every risky clause in the new paper flagged with the exact quote and replacement language
- Core counts verified before Broadcom rounds them up into the product schedule
- Renewal uplift exposure modeled over the full term, with the cap to ask for
What the ELA negotiations showed, 2024 to 2025
Across roughly 20 to 30 Broadcom VMware ELA negotiations, the move from perpetual licences to subscription bundles drove most of the cost increase:
Share of Cloud Foundation components going unconsumed in estates where VCF was sold in as the default.
Renewal increase against the prior perpetual support stream, driven by the model change rather than by any single rate.
Core counts overstated 10 to 25 percent against consolidated host capacity completed the pattern. Core counts and bundle scope are the two largest cost drivers in a Broadcom ELA, and both are decided in the product schedule rather than in the discount conversation.
The structural differences from the legacy VMware ELA are worth stating plainly: subscription replaced perpetual, the bundle catalogue compressed to VCF, vSphere Foundation, vSphere Standard, and a few add ons, and per CPU pricing is gone in favour of per core with a 16 core minimum per processor. Support is now included in the subscription, with production tier carrying 24 by 7 and non production priced separately.
Watch the briefing · 4:44The VMware VCF Renewal: How to Prepare Before Broadcom Names the PriceThe schedule and scope work that decides an ELA before the discount is discussed.
Your first five moves
- Right size the core count against consolidated host capacity before a single number enters the product schedule.
- Audit component use against the VCF bundle and price vSphere Foundation as the alternative wherever the unused share is material.
- Negotiate the true up methodology and its discount at signature, locking additions to the original band rather than to list.
- Split the support tier by environment, production 24x7 where warranted and non production business hours elsewhere.
- Model three year against five year prepay on the corrected schedule, and keep an alternative live through the term. The Broadcom practice runs the ELA with you.
Frequently asked questions
How is a Broadcom ELA different from the legacy VMware ELA?
Three structural changes. Subscription replaced perpetual licences with annual support on top. The bundle catalogue compressed from dozens of SKUs to VCF, vSphere Foundation, vSphere Standard, and a few add ons. And per CPU pricing is gone in favour of per core with a 16 core minimum per processor.
What does the true up clause actually do?
It prices growth above the baseline in your product schedule, either annually or at term end. The default methodology prices that growth at list, which means cores added in year two can cost materially more than the identical cores bought at signature unless the band was pre negotiated.
How do we stop growth being priced at list?
Negotiate the true up methodology and its discount at signature. Either lock additions to the original discount band or agree an explicit growth discount in the clause. It is the only price in the agreement you will otherwise pay without a negotiation attached to it.
What are the four components of a Broadcom ELA?
The product schedule naming bundles and core counts, the term which defaults to three years with five possible, the support tier which sets production or non production coverage, and the true up clause defining how growth is priced. All four are negotiable, including the last.
How much uplift should we expect at renewal?
Uplifts of 2 to 5 times the prior perpetual support stream were normal in the negotiations we ran. That is driven by the move from perpetual licences to subscription bundles rather than by any single rate change, which is why comparing against the old support figure sets the wrong expectation.
Is VCF the right default bundle?
Frequently not. VCF was sold in as the 2026 default where 30 to 50 percent of the components went unused, and an ELA prices bundle scope whether or not you consume it. vSphere Foundation covers vSphere, Tanzu Standard, and vCenter on the same per core arithmetic.
Should we take multi year prepay?
Only once the core count and bundle mix are right. Prepay can hold price and it locks in scope, so it converts a correct schedule into certainty and an inflated schedule into a multi year commitment to overpay. Model both and sequence the right sizing first.
What leverage exists once an ELA is signed?
Less than before it, which is the point of the term. Keep a genuine alternative live through the agreement, because Nutanix, OpenShift Virtualization, Proxmox, and Hyper V each open leverage at renewal, and an alternative that only starts being explored at renewal is not costed in time to matter.
The VMware Estate After the Repackaging
Part 2 of the Negotiating Broadcom series. Two bundles, per core with a sixteen core floor, three year terms paid up front, and a support horizon in October 2027 that decides your timing more than your renewal date does. What the estate actually looks like now, and which numbers are real.
