VMware License True-Up Costs Under Broadcom

VMware customers operating under the pre-acquisition perpetual model were familiar with the true-up motion: at audit or at renewal, deployment that had grown beyond entitlement was reconciled by purchasing additional perpetual licences for the over-deployed cores or CPUs, frequently at the discounted commercial pricing the customer's other VMware purchases had been securing. The motion was uncomfortable but predictable.

The subscription model under Broadcom changes the mechanics meaningfully. The true-up motion is more immediate, more expensive, less negotiated, and more frequently the subject of formal compliance action. Customers need to understand the new mechanics to plan their entitlement-utilisation discipline appropriately.

Pre-acquisition true-up motion: a reminder

The pre-acquisition VMware commercial structure was permissive in practice. Customers purchasing perpetual entitlement could deploy additional capacity through the term and reconcile at audit or renewal. The reconciliation typically applied the customer's effective discount level (sometimes with a modest uplift) to the additional perpetual licences and the associated SnS catch-up. The financial impact was bounded by the customer's negotiated discount level; the timing was bounded by the audit or renewal cycle.

The motion encouraged customers to deploy with some confidence that growth would be reconciled at predictable economics. It also meant that VMware audit was, in practice, frequently a reconciliation exercise rather than a punitive one.

Subscription true-up motion: what changed

Under the Broadcom subscription model, the equivalent of true-up looks different along several dimensions.

The commitment is specific, the deployment must fit within it

The subscription commitment is a specific committed core count for a specific term. Deployment above the committed level is over-deployment; there is no built-in tolerance for growth beyond the commitment within the term. Customers planning growth across the term need to commit at the projected peak rather than at the current deployment.

Mid-term reconciliation is a true-up, not a true-up-at-renewal

Discovery of over-deployment during the contract term triggers a mid-term true-up rather than waiting for renewal-time reconciliation. The mid-term true-up purchases additional committed cores for the remainder of the term, typically at the original commercial's per-core pricing without the favourable closing-incentive economics of the original deal.

List-price exposure for unplanned true-up

True-up cores purchased outside the original commercial discount stack expose the customer to closer-to-list pricing than the original deal. The negotiated discount on the original commercial frequently does not apply to true-up volume; the true-up commercial is its own discount discussion, with materially less leverage than the original-cycle negotiation.

Audit triggers true-up at less favourable economics

If the over-deployment is discovered through a formal Broadcom audit rather than through customer-initiated self-reconciliation, the commercial implications are typically less favourable still. The audit-discovered over-deployment may attract list-price pricing, back-dated to the date of over-deployment, with associated penalty interest or service-recovery fees depending on the contract terms.

How the true-up arithmetic works

Consider a customer with a 1,000-core VCF Advanced commitment who, mid-term, has grown the deployment to 1,200 cores. The over-deployment is 200 cores.

Scenario one: customer-initiated self-disclosure of the over-deployment. The customer engages the partner channel, declares the over-deployment, and proceeds to a true-up purchase. The true-up purchase covers the 200 cores for the remainder of the contract term (e.g., 18 months of a three-year contract). The per-core pricing is typically the original-commercial per-core, possibly with a modest uplift but typically without renegotiation of the discount stack. The arithmetic: 200 cores at, say, $350 effective per core annually, prorated to 18 months — approximately $105K commercial impact.

Scenario two: audit-discovered over-deployment. The same 200-core over-deployment, discovered through audit, may be reconciled at list-price-closer pricing (say $550 per core annually rather than $350) and may be back-dated to the date of discovery rather than prorated to the remaining term. The arithmetic: 200 cores at $550 annually, back-dated 12 months (since the discovery shows the over-deployment existed for the period) — approximately $110K back-dated plus $165K prorated forward, or a combined commercial impact in the $275K range.

The difference between self-disclosure and audit-discovery is substantial. The discipline of self-disclosure when over-deployment occurs is economically preferable in almost all scenarios.

What constitutes over-deployment

The definition of over-deployment under the Broadcom commercial requires care because of the per-core arithmetic and the 16-core minimum per CPU.

Over-deployment is licensed core count above committed core count. The licensed core count for a host is the maximum of the actual core count per CPU and 16, multiplied by the CPU count per host, summed across all hosts running the licensed software. The committed core count is the contractual commitment in the subscription agreement.

Customers should track licensed core count actively rather than waiting for discovery. Several specific behaviours trigger over-deployment that are not always recognised as such:

• Hardware refresh to higher-density CPUs without corresponding deployment reduction. A refresh from 16-core to 32-core CPUs at the same host count doubles the licensed core footprint without changing the operational footprint.
• Adding hosts to a cluster without corresponding workload growth. Each added host adds its full per-CPU licensed-core count to the licensed footprint.
• Activating previously decommissioned hosts as additional cluster capacity. The activation re-licenses the hosts.
• Deploying VMware products on hosts not previously included in the entitlement scope.
• Expanding deployment to additional environments (dev, test, DR) not included in the original commitment.

The audit-trigger dynamics

Broadcom audits have intensified materially since acquisition close, with discovery focus on the patterns above. Customers should expect the audit-trigger dynamic to be specifically focused on over-deployment rather than on broader licensing-position questions.

The audit typically begins with a self-declaration request: the customer is asked to provide deployment-position data (host inventory, CPU and core counts, deployed-product list, environment mapping). The submission is compared to the contractual commitment to identify over-deployment. The audit then proceeds to verification (sometimes including on-site or remote validation) and to commercial reconciliation.

For customers approaching renewal, the audit can be initiated during the renewal cycle itself, with the renewal economics dependent on the audit outcome. The combination of audit-during-renewal is among the most uncomfortable customer experiences in the Broadcom commercial environment; see our audit-during-renewal article for the detailed defence approach.

The over-commit alternative

Some customers, anticipating growth across the term, commit at a level above current deployment to provide buffer. The over-commit eliminates the true-up exposure but at the cost of paying for unused capacity through the term.

The over-commit economics work when the commitment-buffer cost is below the expected true-up cost. If the customer projects 200 cores of growth across a three-year term with 40% confidence, the expected true-up cost is approximately 40% of the 200-core true-up scenario. If the over-commit cost (200 cores at the original-deal per-core for three years) is below this expected value, over-commit is rational.

The analysis depends on the growth projection's confidence and the true-up-versus-original-deal pricing differential. The discipline is to perform the analysis explicitly rather than to default either way.

How to plan for growth without over-committing

For customers wanting growth capacity without full over-commit, several mitigation strategies work.

Commit at the realistic-trajectory level

Project the deployment trajectory across the term with explicit assumptions about growth, hardware refresh, decommissioning, and migration. Commit at the year-by-year projected peak. The projection accuracy is the principal risk; under-projection produces true-up exposure, over-projection produces over-spend.

Negotiate growth-commitment language

Some commercial structures support growth-commitment language: the customer commits at the base level with a contractual right to add committed cores at the original-deal economics through the term. The language has to be negotiated into the original commercial; it is rarely available retroactively.

Defer hardware refresh decisions to align with renewal

Customers anticipating hardware refresh that will increase licensed-core count can sometimes defer the refresh to align with the renewal cycle. The renewal-cycle re-commitment incorporates the post-refresh deployment without requiring a mid-term true-up.

Use partial migration to manage growth

Customers anticipating growth that exceeds available commitment can sometimes manage the growth through partial migration of new workload to alternative platforms (e.g., new workloads to a cloud platform, with VMware continuing to support the existing deployment). The migration avoids the VMware true-up while preserving the existing deployment.

If you are facing a true-up

Customers who discover over-deployment, or who are notified of audit-discovered over-deployment, should follow several specific steps.

First, validate the over-deployment figure independently. The Broadcom or audit-firm figure is the starting point of the conversation; the customer's independent reconciliation may identify counting errors, environments incorrectly in scope, or licensable-host status errors that change the figure.

Second, assess the over-deployment causes. Hardware refresh, dev/test scope, decommissioning lag, and licensable-host status are each separately addressable. Some causes may not be over-deployment under a careful contract reading; others are clearly over-deployment.

Third, engage independent advisory before responding to the commercial. The reconciliation commercial frequently includes terms that go beyond the immediate true-up: revised commitment language, audit-clause changes, term extensions. The terms need to be evaluated in their commercial context, not just as a true-up arithmetic exercise.

Fourth, negotiate the true-up commercial as a discrete negotiation with its own discount stack. The default Broadcom or audit-firm posture is to apply list-price or near-list pricing; the negotiated outcome depends on the customer's willingness to engage the negotiating motion.

Fifth, document the resolution carefully. The reconciliation should produce a clearly-described entitlement position that the customer can manage going forward; ambiguity in the reconciliation creates recurrence risk.

Related reading

For deeper detail, see the Broadcom VMware pricing pillar, our VMware audit defence guide, audit-during-renewal dynamics, audit claim calculation, licence compliance checklist, and post-audit settlement dynamics.