Phase 1: Licence Inventory and Baseline
Before engaging with Broadcom's migration proposal, you need an authoritative inventory of your current VMware estate. Broadcom's migration proposals are built from their own records — which are frequently incomplete, include decommissioned hardware, and in some cases reflect licences that were transferred, bundled with hardware purchases, or acquired through acquisitions and may not accurately represent your current deployment.
What to Inventory
Phase 2: Independent Core Count Validation
The core count in Broadcom's migration proposal is not the starting point for negotiation — it is an opening position that requires independent validation before you treat it as definitive. In our experience across 40+ VMware migration engagements, Broadcom's proposed core count is overstated in over 70% of cases.
Common Core Count Overstatement Patterns
Broadcom typically counts all physical cores across all hosts that appear in their licence records, regardless of whether those hosts are actively deployed, whether they are in production or non-production environments, and whether all components of VCF are actually deployed on each cluster. The most common overstatement patterns we identify are decommissioned hardware that was never formally removed from Broadcom's records (common where hardware refresh cycles didn't include a formal licence decommission step); development and test clusters that are incorrectly included in production VCF scope when lower-cost or different-tier options would apply; disaster recovery standby clusters where hosts are not continuously powered on and workloads are dormant; and OEM-bundled licences from hardware purchases that were included in hardware disposal without formal licence termination.
"On a 500-core VCF proposal at $85 per core per year, a 100-core reduction saves $8,500 annually — $25,500 over three years before any discount negotiation begins. Core count accuracy is always the first conversation."
Validation Process
To validate Broadcom's core count, run an independent VMware inventory export from vCenter that captures all managed hosts, their processor models, and their core counts. Cross-reference this against Broadcom's proposed host list. For any host in Broadcom's list that does not appear in your active vCenter inventory, investigate whether it has been decommissioned. Formally decommission any such hosts in writing to Broadcom before migration negotiations begin — this creates a documented basis for reducing the core count and must be completed before signing VCF terms.
Additionally, analyse each cluster's actual VCF component deployment. Clusters running only vSphere (without vSAN or NSX-T) may qualify for VMware vSphere Foundation (VVF) rather than full VCF — which carries a lower per-core price. Separating your estate into VCF and VVF segments can produce meaningful cost reductions even without changing core counts.
Phase 3: Cost Modelling and Alternatives Assessment
Before negotiating with Broadcom, you need a complete 3-year and 5-year cost model that allows honest comparison between VCF subscription, infrastructure alternatives, and hybrid approaches. The alternatives assessment is not just about cost — it is a negotiation tool. A credible alternatives analysis demonstrably improves Broadcom discount offers because it signals that migration is a real option, not a theoretical threat.
The key alternatives to model are Nutanix (hyperconverged infrastructure with AHV hypervisor), Microsoft Azure Stack HCI (on-premises Azure infrastructure with Hyper-V), cloud migration (moving workloads to AWS, Azure, or Google Cloud native services), and RHEV/oVirt-based open-source infrastructure for specific workload types. For each alternative, model the migration cost including project delivery, re-tooling, retraining, and third-party software compatibility — not just the infrastructure unit cost. VMware alternatives are frequently less expensive on a unit basis but carry meaningful migration costs that must be honestly reflected in any comparison.
We cover the detailed alternatives assessment in our VMware alternatives evaluation guide.
Phase 4: Migration Credit Negotiation
Broadcom's migration credit programme is designed to smooth the transition from perpetual to subscription by offsetting part of the first-year cost differential. Credits are calculated as a percentage of your perpetual licence book value plus remaining support contract value. However, the programme has several mechanics that require active negotiation.
Credit Calculation — Broadcom's Default
Broadcom calculates credits based on their records of your perpetual estate and your support contract remaining value. The credit is expressed as a dollar amount applied to your first-year VCF invoice. Default credit proposals are typically 15–25% of your first-year VCF cost, applied to year one only.
Credit Negotiation — What's Achievable
With active negotiation and a validated licence position, credits of 25–40% of first-year cost are achievable. More importantly, the credit can be structured as a per-core reduction rather than a dollar credit — which provides better multi-year value and a lower ongoing base rate for the full term.
The most important credit negotiation point is the interaction between credit amount and core count. Broadcom's credit calculation uses their proposed core count — if you accept a credit based on an overstated core count, the credit will be nominally larger but the underlying subscription will still be overpaying. Always validate and negotiate core count before negotiating credit amount. A 20% core count reduction with a 25% first-year credit is better than accepting a 35% credit on an inflated core count.
Phase 5: Deal Structure and Term Negotiation
VCF deals are structured around three core variables: term length, total committed core count, and support tier. Broadcom's commercial objectives are maximising term length and committed core count. Understanding these objectives allows you to use them as trading currency.
Term Length Dynamics
Broadcom's published discounts increase with term length: 1-year terms receive minimal discount; 3-year terms typically receive 20–30% below list; 5-year terms can achieve 35–45% below list for large customers. However, 5-year terms carry risk in a rapidly changing environment — Broadcom's own pricing, product strategy, and support model have changed significantly in the two years since acquisition and may continue to evolve. Our recommendation is a 3-year base term with a negotiated renewal option at the same price point or below, rather than committing to 5 years without meaningful exit provisions.
Annual True-Up Provisions
VCF subscriptions require true-up for core count increases — if you add servers, you pay additional cores. Negotiate the true-up frequency (annual preferred over quarterly) and the true-up pricing mechanism: ensure true-ups are priced at your effective per-core rate (discounted rate), not at list price. Without this provision, infrastructure growth can trigger list-price billing even within a discounted term. Also negotiate a downward true-up provision — if you decommission hardware, your subscription should decrease accordingly rather than requiring full-term payment on unused capacity.
Phase 6: Contract Terms That Protect You
Beyond price and core count, several contract terms materially affect the value and risk of a VCF commitment. These are frequently overlooked because commercial negotiations focus on the headline number.
Phase 7: Technical Migration Sequencing
The technical migration from perpetual VMware to VCF-managed infrastructure is a separate project from the commercial migration — but the two timelines must be coordinated. The commercial migration (signing VCF subscription terms) can precede the technical migration by months. However, the technical migration determines how quickly you can realise VCF capabilities and whether you face any gap periods where you are paying for VCF subscription without yet running on VCF infrastructure.
For most enterprise environments, the recommended technical migration sequence begins with greenfield VCF deployment on a pilot cluster — validate operational processes, tooling integration, and runbook procedures before migrating production workloads. Then migrate non-production environments (dev/test), which allows your operations team to develop competency with VCF tooling under low-risk conditions. Migrate production workloads in priority order, beginning with stateless workloads with simple dependencies before progressing to stateful databases and high-availability clusters. DR environment migration typically completes last, after production has been stable on VCF for a minimum of 90 days.
For the complete migration playbook and negotiation support, see our VMware Broadcom Survival Guide or contact our VMware advisory team.