Executive Summary
VMware's move from per-processor to per-core licensing — enacted under Broadcom's ownership — represents the most consequential change to virtualisation economics since VMware first introduced per-socket pricing two decades ago. Every physical core in a host now requires its own licence unit, a 16-core-per-CPU minimum floor applies regardless of the actual silicon, and a punitive 20% late-renewal fee awaits anyone who misses an anniversary date. The result? Renewal quotes that range from uncomfortable to existential for IT budgets, with documented increases of 5× to 40× depending on hardware density and prior contractual terms.
This guide goes beyond the headline figures. We walk through the actual arithmetic of per-core counting — including hyperthreading rules, cloud vCPU translation, and the minimum-floor mechanics — so you can model your own exposure with precision. We then dissect the compounding cost drivers (mandatory bundling, subscription conversion, late-penalty traps), illustrate them with pricing tables and mini case studies, and deliver a 10-step strategic action plan for CIOs, IT procurement leads, and SAM managers navigating their next VMware renewal.
Core Counts Have Exploded
Modern dual-socket servers often carry 64–128 cores per host — each one a billable licence unit under the new model.
Subscriptions Replace Perpetual
One-time licence fees are gone. Annual or multi-year subscriptions now represent the sole procurement path for VMware.
Mandatory Bundling Inflates Bills
vSphere Foundation and Cloud Foundation bundles force customers to pay for components (vSAN, Aria, NSX) they may never deploy.
Penalties Punish Procrastination
A 20% surcharge on late renewals — far steeper than Microsoft's ~3% — creates a financial cliff for any lapsed subscription.
Whether your VMware estate runs 50 cores in a regional office or 50,000 across a global data-centre fleet, the per-core model demands a fundamentally different approach to capacity planning, hardware selection, and vendor negotiation. The sections that follow equip you with the data and tactics to take control.
From Processors to Cores: A Licensing Sea Change
For the better part of two decades, VMware licensing was elegantly simple: one licence per CPU socket. A dual-socket server needed two licences. A four-socket host needed four. The number of cores inside each socket was irrelevant — an 8-core Xeon and a 32-core EPYC both consumed exactly one licence unit. This simplicity made capacity planning, budgeting, and compliance verification straightforward.
Broadcom's acquisition in late 2023 dismantled that model. Starting in early 2024, every new VMware subscription is metered on a per-core basis. The shift aligns VMware with a broader industry trend — Microsoft SQL Server and Oracle Database have used per-core metrics for years — but it introduces a fundamentally different cost dynamic for virtualisation infrastructure that catches many organisations off guard.
Why Broadcom Made the Switch
The commercial logic is transparent. Modern server processors have evolved dramatically: AMD EPYC 9004 chips ship with up to 128 cores per socket, and Intel Xeon 6 "Sierra Forest" reaches 144 cores. Under the old per-socket model, a customer running two 128-core EPYCs in a single host paid for two licence units — the same as a customer running two legacy 8-core chips. Broadcom's revenue opportunity was enormous: by switching to per-core, every additional core becomes a revenue line. The company has publicly targeted growing VMware revenue from $4.7 billion to $8.5 billion within three years of the acquisition, and per-core metering is the primary mechanism to achieve that.
What This Means in Practice
Consider a mid-size enterprise with 10 dual-socket hosts, each running Intel Xeon processors with 20 cores per CPU. Under the old model, that environment required 20 CPU-socket licences. Under the new model, the same environment requires 400 core licences (10 hosts × 2 CPUs × 20 cores). The licence count increased by 20×. Even if the per-unit price is a fraction of the old per-socket price, the total bill is virtually guaranteed to climb — often significantly.
Worse, the shift from perpetual to subscription means these costs recur annually. What was once a one-time capital expenditure plus ~20% annual support is now a fully operational subscription line item that can be repriced at each renewal. For CIOs accustomed to predictable VMware support costs, this is a budgetary sea change.
❌ Old Per-Socket Model
10 hosts × 2 sockets = 20 licences
Core count inside each socket was irrelevant. Perpetual licence + annual support fee (~20% of licence value).
Budget: Predictable, capital expenditure-based.
✅ New Per-Core Model
10 hosts × 2 CPUs × 20 cores = 400 licences
Every physical core is a billable unit. 16-core minimum per CPU applies. Subscription-only — no perpetual option.
Budget: Recurring OpEx, subject to annual repricing.
Takeaway: The first step in cracking the per-core VMware licensing model is accepting that you are no longer licensing servers — you are licensing individual cores. Map out every physical core powering each VMware host in your estate. This single exercise will reveal whether your next renewal is a modest adjustment or a multi-million-dollar shock. For a full picture of Broadcom's licensing overhaul, see our Broadcom/VMware Licensing Overview guide.
What Exactly Counts as a "Core"? Definitions, Hyperthreading, and Cloud vCPUs
Before you can calculate your licence exposure, you must understand precisely what Broadcom considers a "core." The definition is deceptively simple — one physical computing unit on a processor die — but its application across on-premises, virtualised, and cloud environments introduces several nuances that regularly trip up procurement teams.
📦 Physical Servers (On-Premises)
On bare-metal hosts, a core is a physical processor core. If your server runs two Intel Xeon Gold 6430 processors, each with 32 cores, you have 64 physical cores to licence. Hyperthreading (Intel's Simultaneous Multi-Threading, or AMD's equivalent) does not double your count. Two hardware threads on one physical core still represent one licensable core. This is consistent with how Microsoft and Oracle treat hyperthreading in their own per-core models — the thread is a software abstraction, not a physical unit.
💻 Virtualised Environments
In a VMware cluster, the licence count ties back to the physical cores powering the hypervisor layer, not the virtual CPUs assigned to guest VMs. If you allocate 8 vCPUs to a virtual machine running on a host with hyperthreading enabled, those 8 vCPUs correspond to 4 physical cores. The number of VMs running on a host is irrelevant to the core count — what matters is the total physical cores in the host's CPUs. You licence the host, not the guests.
☁️ Public Cloud Deployments (BYOL Scenarios)
For VMware Cloud on AWS, Azure VMware Solution (AVS), or Google Cloud VMware Engine, the core definition maps back to the underlying physical silicon. Cloud providers often label their units as "vCPUs," which typically correspond to one hyperthread — meaning 2 cloud vCPUs = 1 physical core for licensing purposes. An Azure VMware instance with 8 vCPUs runs on 4 physical cores, requiring 4 core licences. Misinterpreting this ratio is one of the most common sources of over-purchasing in hybrid environments.
On-Prem Rule
1 physical core = 1 licence unit. Hyperthreading ignored.
Virtualised Rule
Licence the host's physical cores, not VM vCPU allocations.
Cloud Rule
2 cloud vCPUs = 1 physical core (typical HT ratio). Verify with provider.
Cloud vCPU Misinterpretation Averted
Situation: A procurement manager at a European logistics firm assumed their Azure VMware instances' "8 vCPU" allocation meant 8 core licences were required per instance, across 40 instances — a total of 320 cores.
Action: An internal review, prompted by a Redress Compliance licensing assessment, confirmed that Azure VMware's vCPUs use hyperthreading. Each 8-vCPU instance ran on 4 physical cores.
Takeaway: Always translate cloud "vCPU" labels into physical cores before accepting a vendor quote. The 2:1 ratio applies in most major cloud VMware services.
🎯 What IT Asset Managers Should Do Now — Core Counting
- Run a hardware inventory: Extract CPU model, socket count, and core-per-socket from vCenter or a CMDB. Multiply sockets × cores-per-socket for each host to get the true licence base.
- Verify hyperthreading status: Confirm HT/SMT is enabled — if so, divide any vCPU-based count by 2 to reach physical cores.
- Audit cloud instances: For any BYOL VMware cloud deployment, request the underlying physical core allocation from your cloud provider, not the vCPU label.
- Document everything: Create a single spreadsheet mapping each host to its core count. This becomes your negotiation data and compliance evidence.
The 16-Core Minimum: How the Per-CPU Floor Inflates Costs on Smaller Hardware
Broadcom's per-core model does not simply count physical cores and stop — it imposes a minimum of 16 cores per CPU socket, regardless of the actual silicon installed. This floor means that if your server contains a processor with only 4, 8, or 12 physical cores, VMware licensing treats it as if it has 16. You pay for cores that do not physically exist.
📊 How the Minimum Works
The rule is applied per CPU, not per server. A single-socket server with an 8-core processor is licensed as 16 cores. A dual-socket server with two 8-core CPUs is licensed as 32 cores (16 per socket), even though the server only has 16 physical cores. The minimum does not aggregate across sockets — each socket is independently floored at 16.
For modern hardware running 20, 32, or 64-core processors, the minimum is irrelevant — the actual core count already exceeds 16. But for organisations with older servers, remote-office hardware, or specialised low-power edge deployments, the floor creates a significant cost penalty. You are effectively subsidising Broadcom's revenue model with phantom cores.
📌 The 72-Core Proposal — and Its Reversal
In March 2025, Broadcom communicated an even more aggressive policy: a 72-core minimum per server for all new VMware subscription orders, applied to every server regardless of actual core count. The backlash was swift and severe. Within weeks, Broadcom quietly rescinded the 72-core rule. Distributors confirmed that licensing starts at 16 cores per CPU. In EMEA, the 72-core policy was withdrawn entirely and never took effect. As of the current date, the 16-core-per-CPU minimum remains the operative rule.
However, the episode is instructive: it demonstrates Broadcom's willingness to test aggressive pricing boundaries and only retreat under coordinated customer resistance. CIOs should expect further attempts to raise minimums in future renewal cycles.
| Server Configuration | Physical Cores | Licensable Cores (16-min/CPU) | Phantom Core Tax |
|---|---|---|---|
| 1 socket × 4 cores | 4 | 16 | +300% |
| 1 socket × 8 cores | 8 | 16 | +100% |
| 2 sockets × 8 cores | 16 | 32 | +100% |
| 2 sockets × 16 cores | 32 | 32 | 0% |
| 2 sockets × 32 cores | 64 | 64 | 0% |
| 2 sockets × 64 cores | 128 | 128 | 0% |
The table above illustrates the "phantom core tax" — the percentage by which your licensable core count exceeds your physical core count due to the 16-core minimum. Servers with fewer than 16 cores per CPU are penalised the most. This has direct implications for hardware strategy: running VMware on low-core-count CPUs delivers the worst licence ROI under the new model.
🎯 What Infrastructure Architects Should Do Now — Minimum Impact
- Flag sub-16-core hosts: Identify every server in your VMware estate running CPUs with fewer than 16 cores. These are your highest-priority candidates for retirement, consolidation, or repurposing to non-VMware workloads.
- Model consolidation ROI: Calculate whether migrating VMs from multiple low-core hosts onto fewer modern, higher-core hosts reduces your total licensable core count — and by how much.
- Reassess edge and ROBO deployments: Small remote-office or edge sites with one or two low-core servers are disproportionately impacted. Evaluate whether alternative hypervisors for edge deployments offer better economics.
How Costs Multiply: Anatomy of the 5×–40× Sticker Shock
The per-core metric alone does not explain the extreme cost increases many customers face. The full picture involves four compounding factors that interact to produce renewal quotes far beyond what most IT budgets anticipated.
📌 Factor 1: Core-Count Explosion
The raw licence-count increase is the most visible driver. An enterprise that previously licensed 100 CPU sockets now licenses thousands of cores. The per-unit price is lower, but the unit volume is vastly higher. For environments running modern 32- or 64-core processors, the arithmetic is brutal. A 50-host cluster with dual 64-core EPYCs moves from 100 socket licences to 6,400 core licences. Even at a fraction of the per-socket price, the total spend climbs dramatically.
📌 Factor 2: Mandatory Bundling
Broadcom consolidated VMware's catalogue from 160+ products into a handful of bundles — primarily VMware Cloud Foundation (VCF) and vSphere Foundation (VVF). VVF includes vSphere, vSAN, and Aria Operations. VCF adds NSX, Tanzu, and the full Aria Suite. Many organisations that previously purchased only vSphere Enterprise Plus now find themselves forced into a broader bundle — and paying for vSAN, NSX, or Aria capabilities they never intended to deploy. For a detailed comparison, see our guide on VMware Cloud Foundation vs vSphere Foundation.
📌 Factor 3: Perpetual-to-Subscription Conversion
Under the old model, a VMware perpetual licence was a one-time capital expenditure. Annual support (SnS) typically ran at 18–22% of the licence value. Under Broadcom, perpetual licences are no longer sold, and existing SnS contracts are not being renewed. The subscription that replaces them often costs as much as the original perpetual licence itself — annually. Over a 5-year period, this can represent a 3–5× increase in total cost of ownership compared to the perpetual model. For the strategic context behind this change, read Why Broadcom Killed Perpetual VMware Licences.
📌 Factor 4: List-Price Inflation
Broadcom has also raised list prices across the board. Legacy discounts — including academic, government, and volume-based concessions — have been eliminated or significantly reduced. Customers who previously enjoyed 40–60% off list are now being quoted at 10–20% off (or list price outright), compounding the impact of the metric change.
| Scenario | Old Annual Cost | New Annual Cost | Increase |
|---|---|---|---|
| Mid-size enterprise, 64 total cores, basic vSphere only | $20,000 | $100,000 | 5× |
| Public-sector org, 200 cores, legacy perpetual + SnS | $100,000 | $500,000 | 5× |
| University, 500 cores, no academic discount retained | $40,000 | $500,000 | 12.5× |
| Large enterprise, 2,000+ cores, full VCF migration | $400,000 | $2,000,000 | 5× |
Educational Institution Faces 12.5× Increase
Situation: A UK university running VMware vSphere on ~500 cores across research and teaching clusters paid £40,000/year under an academic perpetual licence with SnS. Upon renewal, Broadcom quoted them for VMware Cloud Foundation at full commercial rates — £500,000/year — with no academic discount.
Action: The institution engaged peer universities, collectively escalated to Broadcom's EMEA leadership, and simultaneously issued an RFP for alternative hypervisors (Proxmox, Hyper-V) for non-critical clusters.
Takeaway: Collective customer pressure, combined with a credible alternative plan, is the most effective lever against Broadcom's pricing. No single institution has enough weight alone.
"The per-core shift is not simply a metric change — it is a revenue extraction mechanism amplified by mandatory bundling, perpetual elimination, and discount compression. CIOs must model the compounding effect of all four factors simultaneously, not in isolation."
The 20% Late-Renewal Penalty: A Costly Trap and How to Avoid It
Among Broadcom's VMware licensing changes, the 20% late-renewal fee stands out as one of the most punitive and least discussed. If your VMware subscription expires before you complete the renewal, Broadcom imposes a one-time 20% surcharge on the first year's subscription cost. For context, Microsoft's comparable late-renewal penalty is approximately 3%. Broadcom's is nearly seven times steeper.
📌 How the Penalty Works
The penalty applies when a subscription renewal is processed after the contract's anniversary date. It does not matter whether the delay is two days or two months — the 20% premium is assessed on the full first-year renewal amount. On a $500,000/year subscription, that means a $100,000 penalty. On a $2 million contract, it is $400,000. The financial waste is entirely avoidable.
📌 Why It Exists
The late fee serves a dual purpose for Broadcom. Operationally, it enforces disciplined renewal cadences that support predictable revenue recognition. Strategically, it weakens the customer's negotiating position. A lapsed subscription means the customer is running VMware software without an active entitlement — creating a compliance exposure that Broadcom can leverage. In effect, the penalty transforms the renewal deadline from a soft negotiation milestone into a hard financial cliff.
Procurement Delay Triggers $180,000 Penalty
Situation: A US manufacturing firm with a $900,000/year VMware subscription was awaiting final CFO sign-off when the renewal deadline passed by 11 days. The internal approval process had stalled over questions about the new per-core pricing.
Action: Broadcom added a $180,000 line item to the renewal invoice — 20% of the first-year subscription. The firm's procurement team attempted to negotiate the penalty down, but Broadcom's position was firm: the terms were contractual.
Takeaway: Treat VMware renewal deadlines as immovable fiscal events. Internal approval delays are not Broadcom's problem — start the process early enough to absorb them.
🎯 What Procurement Teams Should Do Now — Late-Renewal Prevention
- Set T-180 and T-90 alerts: Create calendar reminders at 180 and 90 days before every VMware contract anniversary.
- Pre-authorise renewal budgets: Work with finance to pre-approve VMware renewal spend ranges so that CFO sign-off does not become a bottleneck.
- Negotiate "grace period" language: In your next contract, attempt to include a 30-day grace window for processing delays.
- Document the 20% risk to leadership: Ensure executives understand that a missed deadline is a six-figure financial penalty.
Multi-Year Lock-Ins: Evaluating 3–5 Year Commitments Under Broadcom
Broadcom's sales teams are actively steering customers toward 3-year and 5-year subscription agreements. The incentive structure is straightforward: longer commitments yield better per-core rates and protect against annual list-price increases. But the trade-offs — reduced flexibility, shelfware risk, and strategic lock-in — require careful evaluation. For detailed negotiation frameworks, see our CIO Playbook for Negotiating VMware Contracts.
📌 The Case for Multi-Year Deals
Price predictability is the primary benefit. In an environment where Broadcom has demonstrated a willingness to raise prices aggressively year-over-year, locking a rate for 3–5 years provides budget certainty. Some customers report initial trade-in offers that include 40–50% off list price — but these discounts are typically conditional on multi-year commitments.
📌 The Case Against
Flexibility is the casualty. A 5-year VMware commitment made in 2025 extends to 2030 — a horizon over which cloud migration strategies, containerisation adoption, and alternative hypervisor viability may fundamentally change your virtualisation needs. If your VMware footprint shrinks in Year 3 due to a cloud migration initiative, you are still paying for the committed core count.
5-Year Commitment
Best per-core discount but maximum lock-in. Suitable only for organisations with high confidence that VMware will remain their core virtualisation platform through 2030+. Requires robust exit and scale-down clauses.
3-Year Commitment
The "sweet spot" for most enterprises. Secures meaningful discount while limiting strategic exposure. Aligns with typical IT planning horizons and allows re-evaluation at a reasonable cadence.
1-Year Subscription
Maximum flexibility but highest per-core cost and full exposure to annual repricing. Best suited as a bridge while evaluating alternatives or during active migration planning.
Global Manufacturer Chooses the 3-Year Middle Ground
Situation: A multinational manufacturer with 4,200 licensable cores faced a 1-year renewal quote of $3.2 million — a 4× increase over prior spend. Broadcom's 5-year offer was $2.1M/year but required a Cloud Foundation commitment including NSX, which the firm did not use.
Action: The firm's CIO negotiated a 3-year vSphere Foundation deal at $2.4M/year, excluding NSX. The contract included a clause allowing a 15% core-count reduction at the Year 2 anniversary without penalty, aligned with a planned cloud migration of non-critical workloads.
Takeaway: The 3-year term secured a 25% discount while preserving strategic optionality. The scale-down clause was the critical negotiation win — always request one.
Navigating the Most Dangerous Licensing Pitfalls
The per-core model introduces a category of compliance and cost traps that did not exist under per-socket licensing. Below we detail the most common pitfalls, their financial impact, and specific mitigation tactics.
📌 Pitfall 1: Treating vCPUs as Cores
This is the single most expensive mistake in per-core compliance. Teams that count VM-level vCPU allocations as core licences will over-purchase dramatically in hyperthreaded environments (the 2:1 ratio). Conversely, teams that count only vCPUs in cloud environments without applying the physical-core translation may under-count and face compliance exposure. The fix: always anchor your count to physical cores at the host level, never at the VM level.
📌 Pitfall 2: Ignoring the 16-Core Minimum on Legacy Hardware
Organisations with aging server estates — particularly remote offices, DR sites, or lab environments running 4-core or 8-core CPUs — are paying the "phantom core tax." The mitigation is ruthless: retire, consolidate, or repurpose sub-16-core hosts. Every one you remove from the VMware estate saves you 16 core licences worth of subscription cost.
📌 Pitfall 3: Missing the Renewal Deadline
The 20% late-renewal penalty catches organisations every quarter, particularly those with complex multi-country VMware estates where renewal dates vary by region. A single missed date on a $1M contract costs $200,000. Implement automated tracking and begin discussions 6 months out.
📌 Pitfall 4: Over-Committing on Multi-Year Deals
Broadcom's discounts for 3–5 year terms are attractive, but committing to a core count that exceeds your actual need creates years of shelfware. Forecast conservatively, build in scale-down clauses, and avoid pre-committing growth cores unless the per-core rate for incremental capacity is contractually guaranteed.
📌 Pitfall 5: Assuming Bundle Contents Are Stable
Broadcom has already changed bundle compositions since the acquisition — adding and removing components from VVF and VCF. What you negotiate today may not be what the bundle contains at renewal. Mitigation: demand an explicit exhibit in your contract listing every product and feature included. See our guide to Broadcom's simplified VMware portfolio for current bundle compositions.
| Pitfall | Typical Financial Impact | Mitigation Strategy |
|---|---|---|
| Treating vCPUs as cores | 50–100% over-purchase or compliance gap | Anchor counts to physical host cores; verify HT ratio |
| Sub-16-core hardware penalty | 100–300% per-host core inflation | Retire/consolidate sub-16-core servers |
| Late renewal | 20% first-year surcharge | T-180 alerts; pre-authorise renewal budgets |
| Multi-year over-commitment | 15–30% wasted spend across term | Conservative forecasting; scale-down clauses |
| Bundle composition changes | Loss of expected features at renewal | Contractual product-list exhibit; annual review |
10-Step Strategic Action Plan for VMware Per-Core Cost Control
With the mechanics understood and the pitfalls mapped, the following action plan consolidates everything into an executable strategy. Each step includes specific deliverables and responsible stakeholders.
Baseline Your Environment — Exhaustively
Conduct a full inventory of every VMware host: CPU model, socket count, cores per socket, hyperthreading status, and VMware product deployed (vSphere, vSAN, NSX, Aria). Export from vCenter and cross-reference with your CMDB. This is your single source of truth for all downstream calculations and negotiations. Assign an owner and a completion deadline.
Calculate Your True Licensable Core Count
Apply the 16-core-per-CPU minimum to each host. Sum across the entire estate. Separate the count by site, business unit, or cluster — this granularity helps identify optimisation opportunities and supports chargeback models. Compare the total to your current licence entitlement to quantify your gap or surplus.
Right-Size Hardware for Licence Efficiency
Identify hosts where the licence cost exceeds the workload value. Consolidate VMs from multiple low-core hosts onto fewer high-core modern servers. Retire sub-16-core hardware aggressively. Model the total-cost-of-ownership (hardware refresh + licence savings) to build the business case.
Evaluate Edge and ROBO Alternatives
For small remote-office or edge sites running 1–3 VMware hosts, assess whether VMware is still cost-effective. Alternatives like Proxmox, Hyper-V, or KVM may deliver equivalent functionality at a fraction of the licensing cost for sub-enterprise deployments.
Lock Renewal Dates into Organisational Workflow
Implement automated alerts at T-180 and T-90 days. Designate a renewal owner. Pre-authorise budget ranges with finance so that CFO approval is not a last-minute bottleneck. The 20% late-renewal penalty is entirely preventable.
Engage Broadcom Early — Not Reactively
Begin renewal conversations at least 6 months before contract expiry. Request indicative pricing and new SKU mappings early. Broadcom's processes can be rigid and slow — early engagement gives you time to escalate, seek counter-quotes, or find creative deal structures.
Negotiate Bundles vs. Components Deliberately
Compare the cost of VCF, VVF, and individual subscriptions against your actual usage. If you need only vSphere and vSAN, VVF may be more economical than separate subscriptions. If you need vSphere only, push for a component-level deal. For organisations evaluating the full bundle landscape, our VMware unbundling analysis provides a comprehensive framework.
Secure Multi-Year Price Protections (with Exit Clauses)
If committing to a 3-year term, insist on capped annual increases, scale-down rights (ability to reduce core count at each anniversary), and explicit product-inclusion exhibits. A multi-year deal without these protections is just a longer trap.
Maintain a Credible Plan B
You do not need to commit to leaving VMware — but you do need Broadcom to believe it is possible. Pilot an alternative hypervisor in a non-critical environment. Issue an RFP for virtualisation alternatives. See our guide on diversifying virtualisation to reduce vendor risk.
Engage Independent Advisory Support
Broadcom's negotiation teams are skilled and well-resourced. Levelling the playing field often requires independent expertise — licence benchmarks, contract-clause analysis, and deal-structure creativity. Firms like Redress Compliance specialise in Broadcom advisory services. Our top 20 tips for negotiating with Broadcom provide a quick-reference resource.
Audit Preparedness: Staying Compliant Under Broadcom's Watch
Broadcom has signalled — both directly and through its channel partners — that compliance enforcement will be vigorous. Under per-core licensing, the attack surface for compliance gaps is much larger than under per-socket: a single untracked host, a forgotten DR site, or a miscounted cloud deployment can trigger a non-compliance finding.
📌 Document Your Core Counts Continuously
Maintain an evergreen register of your licensable core count, updated at least quarterly. Automate extraction from vCenter wherever possible. This register serves dual purposes: it supports your negotiation data and constitutes your compliance evidence if Broadcom initiates an audit. For a comprehensive view of audit risk, see our guide to audit risks under Broadcom's VMware licensing.
📌 Avoid Common Audit Triggers
Deploying additional ESXi hosts without corresponding licence additions is the most common trigger. Repurposing a licence from a decommissioned host to a new one without formally updating entitlements is another. And running VMware software after your subscription has lapsed — even briefly — creates an exposure window. Our Broadcom audit defence guide provides a step-by-step response framework.
📌 Prepare for the Audit Conversation
If Broadcom initiates an audit, your first response should be calm and data-driven. Having your core-count register, licence entitlement records, and contract documentation organised and accessible demonstrates compliance maturity and reduces the audit scope. Organisations that cannot produce this data quickly tend to face broader and more costly audit processes.
🎯 What SAM Managers Should Do Now — Audit Readiness
- Automate core-count reporting: Configure vCenter or a third-party SAM tool to export host-level core counts on a scheduled basis.
- Reconcile quarterly: Compare deployed cores against licensed entitlements every quarter. Resolve discrepancies before Broadcom finds them.
- Centralise documentation: Keep all VMware contracts, entitlement certificates, and correspondence with Broadcom in a single, accessible repository.
- Conduct a pre-audit self-assessment: Run an internal mock audit annually, checking for unlicensed hosts, lapsed subscriptions, and misallocated entitlements.
Looking Ahead: What CIOs Should Expect from Broadcom's VMware Strategy
Broadcom's VMware licensing strategy is not static. The company has already demonstrated a willingness to test aggressive policies (the 72-core minimum), retreat when resistance is sufficient, and introduce new bundle configurations. CIOs should expect continued evolution in several areas.
📌 Price Increases Will Continue
Broadcom's revenue targets for VMware have not been achieved in full. Analysts expect annual list-price increases of 5–15% on top of the already-elevated per-core rates. Multi-year agreements with fixed pricing become more valuable each year this trend continues.
📌 Bundle Compositions May Shift
Components may move between VVF and VCF — or be extracted as paid add-ons. The vSphere Enterprise Plus SKU was introduced and repositioned within the first year of the acquisition. CIOs should assume that what they purchase today may be repackaged at renewal.
📌 Audit Frequency Will Likely Increase
As the installed base fully transitions to subscriptions, Broadcom will have both the incentive and the data to identify compliance gaps. Organisations that proactively manage their licence positions will fare far better than those caught off guard.
📌 The Alternative Ecosystem Is Maturing
Proxmox, Nutanix AHV, and Microsoft Hyper-V are all benefiting from VMware customer dissatisfaction. While none is a drop-in replacement for VCF, the gap is narrowing — particularly for Tier 2 and Tier 3 workloads. Maintaining awareness of these alternatives strengthens both your negotiating position and your strategic resilience.
"The organisations that will navigate Broadcom's VMware era most successfully are those that treat licensing as a strategic discipline — not an annual administrative chore. Invest in the data, the expertise, and the organisational processes to manage your VMware position proactively, and the per-core model becomes a manageable cost of doing business rather than an existential budget threat."