VMware Cloud Foundation (VCF) Licensing Guide 2026Pricing, Components, Requirements & Optimisation Strategies

What Changed: The Broadcom Restructure

When Broadcom finalised its $61 billion acquisition of VMware in November 2023, the company immediately began the most aggressive licensing restructure in enterprise software history. Understanding the current state of VCF licensing requires understanding what was dismantled and what replaced it.

Perpetual licences eliminated. VMware no longer sells perpetual licences for any product. All new purchases are subscription-only, with 1-year, 3-year, and 5-year term options. Existing perpetual licence holders retain their licences but are capped at vSphere 8 Update 3 — no upgrade path to VCF 9.0 or vSphere 9.0 exists without converting to a subscription. Broadcom has confirmed that existing perpetual VCF licences are capped at version 5.x and cannot be upgraded to VCF 9.x.

Product catalogue consolidated. Broadcom eliminated approximately 8,000 individual VMware SKUs and replaced them with a handful of bundled offerings. The two primary bundles are VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF). Standalone purchases of individual products (vSphere alone, NSX alone, vSAN alone) are no longer available for new deployments. This is the most consequential change for many organisations: if you previously purchased only vSphere for compute virtualisation and used external storage without vSAN or NSX, you must now purchase an entire bundle that includes components you may never deploy.

Licensing metric shifted from per-socket to per-core. Under the legacy model, VMware licensed vSphere per physical CPU socket. Under the new model, VCF is licensed per physical core with a minimum of 16 cores per CPU. This change dramatically increases licensing costs for high-core-count servers. A dual-socket server with two 32-core CPUs now requires 64 core licences at $350 each ($22,400/year) versus a legacy cost of approximately $8,000–$12,000 as a one-time perpetual purchase plus $2,000–$3,000/year in annual support.

72-core minimum order requirement. New VCF subscriptions require a minimum purchase of 72 cores per order line. This disproportionately impacts small and mid-sized environments. An organisation with a single 3-host cluster of 8-core CPUs (48 physical cores, licensed as 48 at the 16-core minimum) must still purchase 72 cores — paying for 24 cores of unused entitlement. At $350/core, the minimum annual VCF spend is $25,200 regardless of actual environment size.

VCF 9.0: What Is Included

VCF 9.0 is a fully integrated software-defined data centre (SDDC) platform. Unlike a collection of standalone products, VCF is designed to be deployed and managed as a single unified stack through SDDC Manager. Understanding exactly which components are included — and which are paid add-ons — is critical for accurate cost modelling.

Included Components (Base VCF Subscription)

Paid Add-Ons (Not Included in Base VCF)

The add-on pricing reveals VCF’s true cost profile. An organisation deploying VCF with distributed firewall, additional vSAN capacity, and disaster recovery for 100 VMs could face add-on costs that approach or exceed the base VCF subscription cost. This is by design: Broadcom’s bundling strategy creates a base platform entry point, then generates incremental revenue through add-ons for capabilities that many enterprises consider essential. In our advisory engagements, we consistently find that total VCF cost including necessary add-ons is 30–60% higher than the base subscription price alone.

Core Counting: The Licensing Maths

VCF licensing is deceptively simple in concept (count physical cores, pay per core) but contains several rules that inflate the licensable count above the actual physical core count in many environments.

The Rules

Rule 1: Count physical cores, not threads. Hyper-Threading / SMT does not create additional licensable cores. A 32-core CPU with 64 threads requires 32 core licences.

Rule 2: 16-core minimum per CPU. Every physical CPU must be licensed for at least 16 cores, regardless of actual core count. An 8-core CPU requires 16 core licences. A 12-core CPU requires 16 core licences. This rule exists because Broadcom set the minimum at the core count of their target server profile; it penalises organisations running older or lower-core-count hardware.

Rule 3: BIOS-disabled cores still count. If a CPU has 32 physical cores but you have disabled 8 via BIOS to reduce licensing exposure on a different vendor’s product, VMware still counts all 32 physical cores. There is no mechanism to reduce the licensable count through BIOS configuration.

Rule 4: All hosts in VCF must be licensed. Both the management domain hosts and workload domain hosts require VCF licences. The management domain typically consumes 4 hosts running SDDC Manager, vCenter, NSX Manager, VCF Operations, and other infrastructure VMs. These hosts are often overlooked in initial cost estimates — they add 64–256 cores to the licence requirement (depending on hardware) while running zero customer workloads.

Rule 5: 72-core minimum per order line. New purchases require at least 72 core licences. Renewals of existing subscriptions at their current core count are not subject to this minimum, but any expansion requires meeting the 72-core threshold per order.

Core Count Example: 10-Host Data Centre

The 12-core scenario is particularly instructive: 240 physical cores become 320 licensable cores (a 33% inflation), because each of the 20 CPUs triggers the 16-core minimum. For organisations with older Intel Xeon or AMD EPYC processors with 10–14 cores, the minimum-core rule adds a meaningful licensing premium. This is one reason workload consolidation onto fewer, higher-core-count servers is an effective VCF optimisation strategy — the 16-core minimum becomes irrelevant when every CPU exceeds 16 physical cores.

vSAN Storage Entitlement: The 1 TiB/Core Calculation

VCF includes 1 TiB of vSAN capacity per licensed core. This entitlement is poolable across all VCF-licensed clusters, meaning you can aggregate unused storage entitlement from compute-heavy clusters and apply it to storage-dense clusters. The pooling is a licensing entitlement, not a technical redistribution — vSAN still operates within the physical constraints of each cluster’s disk configuration.

Is 1 TiB/Core Enough?

For a 640-core environment, the included entitlement is 640 TiB of vSAN capacity. Whether this is sufficient depends on your storage architecture:

vSAN capacity is measured as raw usable capacity before RAID overhead. With RAID-1 mirroring (the default for small clusters), your effective usable capacity is roughly 50% of raw. With RAID-5/6 erasure coding (available on ESA), efficiency improves to 67–75%. A 640 TiB entitlement translates to approximately 320 TiB usable with RAID-1 or 430–480 TiB usable with RAID-5/6.

For many enterprise environments, 1 TiB/core is generous for compute-heavy workloads (VDI, application servers, web tiers) but insufficient for data-intensive workloads (databases, file services, analytics). Organisations with high storage-to-compute ratios will need to purchase the vSAN Additional Capacity add-on at $210/TiB/year. Before purchasing additional capacity, validate that your vSAN cluster design uses ESA with erasure coding (rather than OSA with mirroring), deduplication and compression are enabled, and storage policies are right-sized per workload. These optimisations can reduce actual vSAN consumption by 30–50%, potentially eliminating or reducing the need for add-on capacity purchases.

VCF vs VVF: Choosing the Right Bundle

The choice between VCF ($350/core/year) and VVF (~$135/core/year) is the first strategic decision in any VMware licensing engagement. The $215/core annual difference is substantial — for a 640-core environment, VCF costs $224,000/year while VVF costs approximately $86,400/year, a difference of $137,600 annually.

Choose VCF when: you need NSX for overlay networking, micro-segmentation (with vDefend add-on), or multi-site/multi-tenant network architecture; you want SDDC Manager for automated lifecycle management across the full stack; you need substantial vSAN capacity and the 1 TiB/core entitlement reduces or eliminates add-on storage purchases; or you are building a private cloud with self-service, policy-driven infrastructure provisioning (VCF Automation).

Choose VVF when: you use external storage (SAN/NAS) and do not need vSAN as your primary storage platform; your networking requirements are met by standard vSphere distributed switches without NSX overlay networks; your environment is smaller (fewer than 7 hosts) and does not justify the management domain overhead; or you want to minimise VMware spend while retaining access to vSphere 9.0 features.

Redress Compliance has published a detailed feature-by-feature analysis in VMware Cloud Foundation vs vSphere Foundation: Licensing, Features, and Pricing Comparison.

Compliance Reporting: The New Mandatory Requirement

VCF 9.0 introduces a mandatory compliance reporting requirement that did not exist in previous versions. Organisations must periodically submit usage reports to Broadcom documenting their deployed core counts and vSAN consumption. Failure to submit compliance reports results in degraded management capabilities and suspension of updates and support.

This is not a soft recommendation — it is enforced through the software. VCF Operations provides centralised licence tracking and reporting capabilities specifically to support this requirement. Organisations planning a VCF 9.0 deployment must establish a compliance reporting process from day one, including clear ownership of who prepares and submits reports, validation that reported core counts match actual deployment, and processes for handling licence true-ups if actual deployment exceeds purchased entitlement.

The compliance reporting requirement reflects Broadcom’s broader shift toward active licence enforcement. Under legacy VMware, licence compliance was largely self-certified with periodic audits. Under Broadcom, compliance is continuous, software-enforced, and non-negotiable. Organisations accustomed to running VMware environments with loose alignment between purchased licences and deployed cores should expect this tolerance to end with VCF 9.0.

Subscription Terms and Renewal Traps

VCF subscriptions are available in 1-year, 3-year, and 5-year terms. Multi-year terms reduce the effective annual cost and provide price predictability, but they also lock the organisation into VMware for the duration. Understanding the renewal mechanics is essential for avoiding cost escalation.

Late renewal penalty: 20%. Broadcom imposes a 20% penalty on the first-year subscription price for customers who fail to renew their subscriptions by the anniversary date. This creates urgency around renewal timing and limits the organisation’s ability to use late renewal as a negotiation tactic.

Multi-year pressure. Broadcom is actively steering customers toward 3-year and 5-year commitments, often offering meaningful discounts (15–25% off list) for longer terms. While this reduces annual cost, it also eliminates flexibility to reduce VMware footprint or migrate to alternatives during the term. For organisations actively evaluating VMware alternatives, a 1-year renewal at a higher per-core price may be strategically preferable to a locked 3-year term at a lower price, as it preserves optionality.

Expansion versus renewal pricing. Renewals at the existing core count typically retain the previously negotiated discount level. However, expanding core count mid-term often resets to current list pricing for the incremental cores, and new expansion orders must meet the 72-core minimum. This creates a planning incentive to slightly over-provision at initial purchase rather than add cores incrementally at potentially higher per-core rates.

No downgrade provisions by default. Standard VCF contracts do not include provisions to reduce core count during the subscription term. If you consolidate workloads and reduce your VMware footprint, you continue paying for the original core count until the term expires. Negotiating downgrade rights at contract signing is strongly recommended — see our VMware Renewal Negotiation Playbook for specific tactics.

Cost Modelling: Three Enterprise Scenarios

The following scenarios illustrate VCF’s total cost profile across different environment sizes, including the management domain overhead that many initial estimates overlook.

Scenario 1: Small Environment (3 Workload Hosts)

The “management domain tax” is immediately visible: 128 of 224 licensed cores (57%) are consumed by infrastructure VMs, not customer workloads. This is the primary reason VCF is uneconomic for small environments. A 3-host workload cluster is effectively paying double for its compute capacity.

Scenario 2: Mid-Size Environment (20 Workload Hosts)

With add-ons, the effective per-core cost rises from $350 to approximately $502/core/year — a 43% premium over the headline price. This is a pattern we observe across virtually every enterprise VCF engagement: the base price is the starting point, not the ending point.

Scenario 3: Large Environment (100 Workload Hosts)

At large scale, the add-ons — particularly vDefend Firewall — can exceed the base VCF subscription cost. This is where negotiation leverage is most valuable. Our Italian luxury brand case study demonstrates how structured alternative architecture modelling and counter-negotiation reduced a comparable Broadcom renewal by 38% (€900K saved).

VCF Licensing Optimisation Strategies

Regardless of whether an organisation intends to remain on VMware long-term or migrate to alternatives, optimising VCF licence costs is an immediate priority. The following strategies are drawn from our advisory engagements with enterprises managing VCF renewals.

1. Consolidate workloads to reduce licensed core count. Every core eliminated from the VMware footprint saves $350+/year. Consolidation involves right-sizing VMs (most enterprise VMs are 30–40% over-provisioned), identifying underutilised hosts that can be decommissioned, and migrating non-critical workloads (dev/test, non-production, file services) to alternative platforms (Linux KVM, Proxmox, Azure). In our experience, a disciplined consolidation exercise typically reduces licensable core count by 15–25% without impacting production capacity.

2. Evaluate VVF for workloads that do not require VCF capabilities. Not every workload requires NSX, SDDC Manager, or VCF Automation. Environments running standard virtualisation with external storage and basic networking can operate on VVF at ~$135/core/year — a 61% saving versus VCF. Splitting the environment between VCF (for workloads requiring the full stack) and VVF (for commodity compute) can substantially reduce total licensing cost.

3. Challenge vSAN add-on requirements. Before purchasing additional vSAN TiBs, verify that ESA with erasure coding is deployed (not OSA with mirroring), global deduplication and compression are enabled, storage policies are not over-provisioned (many environments apply FTT=2 when FTT=1 is sufficient), and the 1 TiB/core entitlement is fully utilised across all clusters via pooling. These optimisations can reduce vSAN consumption by 30–50%, eliminating add-on costs entirely in many cases.

4. Negotiate contractual protections at renewal. Critical contract terms to negotiate include annual price escalation caps (target 3–5% versus Broadcom’s uncapped standard terms), downgrade provisions allowing core count reduction at annual anniversary, co-termination rights for additions, and a commitment to specific add-on pricing for future expansion. These protections cost nothing to negotiate but provide meaningful financial protection over a multi-year term. Our negotiation playbook details specific tactics for each of these provisions.

5. Build credible alternative architectures. The single most effective negotiation lever with Broadcom is a credible, board-approved plan to migrate a portion of the VMware estate to an alternative platform. This is not a bluff — it is a documented architecture with specific migration timelines, cost models, and executive approval. Broadcom’s deal desk responds to credible competitive pressure with discounts of 15–35% off list price, escalating with the perceived likelihood of workload departure.

Hardware Requirements and Compatibility

VCF 9.0 has specific hardware requirements that affect both licensing cost and deployment feasibility. Understanding these requirements before purchasing VCF licences prevents costly surprises during deployment.

Management domain sizing. A production VCF deployment requires a dedicated management domain running SDDC Manager, vCenter, NSX Manager, VCF Operations VMs, and VCF Automation VMs. The management domain requires a minimum of 4 ESXi hosts when using vSAN (3 for the vSAN cluster plus 1 for redundancy), or a minimum of 2 hosts when using external storage. Each host in the management domain must be licensed with VCF — these are not “free” management hosts. For organisations accustomed to running vCenter on a single management server, the 4-host management domain represents a significant infrastructure and licensing overhead. The management domain hosts must meet the same hardware compatibility requirements as workload hosts and should be identical hardware configurations for vSAN clusters.

vSAN ESA versus OSA hardware. VCF 9.0 supports both the vSAN Express Storage Architecture (ESA) and the Original Storage Architecture (OSA). ESA delivers significantly better performance and storage efficiency (erasure coding, global deduplication) but requires NVMe-only storage devices certified on the VMware Hardware Compatibility List (HCL). Servers with SAS or SATA drives cannot use ESA and must remain on OSA. For organisations planning a hardware refresh, ESA-compatible servers with NVMe storage should be specified from the outset. For organisations retaining existing hardware, OSA remains fully supported — Broadcom has explicitly stated that OSA is not deprecated in VCF 9.0.

Server certification carryforward. Servers certified for vSphere and vSAN 8.x are generally carried forward and supported in VCF 9.0. A full hardware refresh is not required to upgrade from VCF 5.x to 9.0 in most cases. However, firmware and BIOS versions must be validated against the VCF 9.0 HCL before upgrade — running unsupported firmware is the most common cause of upgrade failures. Plan firmware updates as part of the VCF upgrade maintenance window. The hardware compatibility check should be performed weeks before the upgrade, not during it, to allow time for firmware procurement and testing.

Network infrastructure requirements. VCF 9.0 requires dedicated VLANs for management, vMotion, vSAN, and NSX host overlay networks. Jumbo frames (MTU 9000) are recommended on all VLANs, with a minimum MTU of 1600 required on the NSX host overlay VLAN end-to-end through the physical switching infrastructure. Organisations that have not deployed jumbo frames in their data centre network may need to reconfigure physical switches and validate end-to-end MTU before VCF deployment — a networking prerequisite that is sometimes discovered late in the deployment process.

Upgrade Paths to VCF 9.0

The path to VCF 9.0 depends on your current VMware licensing position:

From VCF 5.x (existing subscription): Direct upgrade path exists. The upgrade involves sequential updates to VCF Operations components, then SDDC Manager, then NSX, then vCenter, then ESXi hosts. Broadcom recommends backing up each component before upgrade as there is no holistic rollback mechanism. The management domain upgrade is non-disruptive to workload VMs but requires maintenance windows for each component. Existing hardware certified for vSphere/vSAN 8.x is generally carried forward to VCF 9.0 — a full hardware refresh is not required.

From vSphere 8.x (perpetual licences): VCF 9.0 supports importing existing vSphere 8.x clusters into a new VCF management domain. The VCF Installer can convert an existing vSphere environment into a VCF management domain, and additional vSphere environments can be imported via VCF Operations. NSX is automatically deployed as part of the import process (non-disruptive to running VMs). This path requires purchasing VCF subscriptions for all imported hosts.

From vSphere 7.x or earlier: No direct upgrade path to VCF 9.0 exists. Organisations must first upgrade to vSphere 8.x, then convert/import to VCF 9.0, or deploy VCF 9.0 as a greenfield installation and migrate workloads from the legacy environment. The greenfield approach is generally recommended for legacy environments as it avoids accumulating configuration debt during migration.

Frequently Asked Questions