VMware licensing and VCF pricing: How to model three-year TCO

A VMware renewal quote or a per-core number looks precise, and it's tempting to treat it as the cost of running VMware Cloud Foundation (VCF) for the next three years. But that figure leaves out most of what decides the operating decision: the hardware under the licenses, the people who run the platform, the recovery design that protects it, the migration work to get there, and the cost of eventually leaving.

A per-core figure alone can't explain VMware Cloud Foundation pricing. A defensible comparison of three-year total cost of ownership (TCO) begins with the licensing capacity you actually need, then adds infrastructure, operations, resilience, migration, growth, and exit costs.

This article gives you a method for building that comparison and leaves market prices out, because commercial terms, entitlements, minimums, and product scope need to come from your current quotes and contracts.

For background on Broadcom's licensing and platform changes, see Disruption to opportunity: Making sense of VMware VCF 9, and for renewal timing, see our VMware renewal strategy.

How do you model VCF three-year TCO? Start with the licensing capacity your hosts require. Then add infrastructure and facilities, operations, protection and resilience, migration and overlap, growth, and exit costs across three years. Subtract only credits or avoided costs you can document. Compare every quote on the same capacity, service scope, resilience, growth, and responsibility assumptions.

What determines VMware Cloud Foundation pricing?

Five inputs shape VMware Cloud Foundation pricing, and each comes from a different source. Technical capacity is the number of cores and vSAN TiB your hosts require under Broadcom's counting rules. Licensed product scope is what that capacity entitles you to use, and add-ons are separate products you license on top of it. Support or service scope covers the support level and any services attached to the order, while commercial order terms cover the term length, minimums, and other conditions in your quote and contract. Keep each one on its own line in your model.

Start with required licensing capacity. According to Broadcom's core-counting guidance for VMware Cloud Foundation and vSphere Foundation, VCF licensing is based on the total physical CPU cores across every ESXi host you plan to license, with a minimum of 16 cores counted for each physical CPU. A host with 2 8-core CPUs, for example, counts as 32 cores.

The 16-core minimum is a technical rule for calculating capacity. Any commercial minimum or order constraint on your purchase is a separate term, so validate it against your current quote and contract.

Broadcom's official VMware license calculator lets you enter sample host configurations and run simulations to see the subscription capacity required for VCF, VMware vSphere Foundation (VVF), and vSAN. The result from this VMware licensing calculator is a capacity figure, and your TCO model takes that figure as its first input.

Licensed capacity and any separate products or add-ons together determine your scope in VMware Cloud Foundation licensing. Broadcom's guidance says each licensed VCF core includes 1 TiB of vSAN capacity, measured against the raw physical storage your hosts contribute to vSAN clusters, and you buy additional vSAN capacity separately if you need more. For VCF 9.1, Broadcom's licensing overview lists VCF cores as the primary license and names vSAN (TiB) and VMware Private AI Foundation with NVIDIA as the add-on licenses managed in the VCF Business Services console. VMware licensing packaging and entitlements can change, so confirm both against Broadcom's documentation before you lock the model.

Support levels, services, and order terms sit on top of capacity and scope. Unit prices and discounts depend on your purchasing unit, term, eligibility, and date, so the numbers in your model should come from your own written quote.

Establish the current-state baseline before comparing options

Define your baseline before you evaluate any proposal. Without one, a lower quote can hide a narrower scope or a shift in responsibility.

Inventory the estate first. That means hosts, sockets, physical cores, clusters, storage capacity and consumption, networking, backup, disaster recovery, facilities, support agreements, tooling, and contract dates.

Then measure workload demand. Capture allocated and used compute, memory, and storage, plus performance needs, protection tiers, availability targets, data growth, workload growth, and seasonal peaks.

Document the operating effort as well, including platform administration, lifecycle work, monitoring, security, backup, capacity planning, incident response, vendor management, training, and after-hours coverage.

Capture each input in a table like this one, so the source, owner, and validation status travel with every number.

Build the complete three-year cost stack

A complete three-year cost stack captures every dollar it takes to license, run, protect, move, and eventually exit the platform.

Licensing and subscriptions

Write the stack as a formula so every reviewer works from the same definition:

Three-year TCO = licensing and subscriptions + infrastructure + operations + protection and resilience + migration and overlap + growth and exit costs - documented credits or avoided costs

Licenses, subscriptions, support, add-ons, renewal timing, and contractual adjustments belong in this line. Treat discounts and credits as inputs you can document with a written quote or contract, and leave out any savings you're only expecting.

Infrastructure and facilities

This line covers servers, storage, networking, hardware support, colocation or data center space, electricity, cooling, connectivity, and the capacity you hold for refresh or expansion.

Separate sunk costs from future cash requirements, and apply the same rule to every option. Hardware you already own, new purchases, provider infrastructure, and capacity held for resilience all need consistent treatment, or the comparison tilts before you've started.

Operations, protection, and change

Operations covers labor, managed services, monitoring, security operations, lifecycle management, training, vendor management, and escalation coverage. Protection covers backup, disaster recovery, testing, and audits. If you're weighing a service such as Disaster Recovery as a Service (DRaaS), put its recovery design, testing, and service scope in this same line so it compares cleanly with a design you'd run yourself.

Change covers migration planning, professional services, data movement, remediation, testing, parallel environments, change windows, and any temporary license or infrastructure overlap while the old and new environments run side by side.

Here's how the full stack breaks down by category.

Compare direct on-premises, hosted or managed, and phased hybrid models

Compare three practical paths: direct on-premises VCF, a hosted or managed private cloud, and a phased hybrid model that moves selected workloads or responsibilities over time.

Normalize scope before you compare totals. Capacity, the workload set, resilience, the support window, the refresh period, migration work, connectivity, security responsibilities, and growth assumptions need to be equivalent across every option.

With Flexential Hosted Private Cloud, some infrastructure and operations costs can shift from your own budget lines into the provider's service scope. In a phased hybrid design, connectivity and data movement between environments become cost lines of their own, which is where an interconnection service such as Flexential Cloud Fabric enters the model.

Which model costs less depends on utilization, refresh timing, internal labor, service scope, resilience requirements, migration effort, and contractual terms, so the next step is testing those assumptions.

Test the assumptions that can change the result

Sensitivity testing shows which assumptions move your three-year total and by how much.

Capacity and growth

Run at least a low, expected, and high case for required cores, storage consumption, workload growth, resilience capacity, public cloud or network egress, and labor or managed-service scope.

In your model, show which variables affect every year, which occur once, and which can trigger a step change, such as a hardware expansion, a new contract tier, or a new site.

If growth is hard to predict, model how you'd add capacity in increments. Capacity on Demand from Flexential, for example, lets you maintain a baseline environment and activate additional compute and storage when you need it.

Migration, overlap, and exit

Test migration duration, coexistence, remediation, cutover, rollback, temporary capacity, and dual-running periods. A small schedule change can move costs between years or extend the overlap period.

Scope these inputs from a real migration plan that spells out the sequence, cutover approach, and overlap period you're pricing, whether your team runs it or you use Flexential cloud migration services and strategy.

Include exit assumptions too: data movement, decommissioning, contract end dates, hardware disposition, license or entitlement changes, and the cost of switching operating models. Have your legal team review any portability and termination language before it enters the model.

Ask procurement questions before comparing quotes

Quotes become comparable when every vendor answers the same questions in writing. Send each one the same set and require dated, written responses.

Scope and commercial terms

Ask what each quote includes: products, capacity units, support, add-ons, implementation services, minimums, term length, renewal mechanics, credits, and exclusions. Require a dated, written answer.

Operating responsibility and service boundaries

Ask who owns hardware, lifecycle management, monitoring, patching, backup, recovery, security operations, capacity planning, incident response, connectivity, and vendor escalation.

Then map each responsibility to a model and a cost owner. A responsibility that moves to a provider takes its cost into a different service scope and risk allocation, so it stays in the comparison.

Entitlement, portability, and change control

Ask how license entitlements, portability, bring-your-own-license (BYOL) or bridge options, transition programs, product changes, support changes, and midterm capacity increases are handled. Have your product and legal teams validate every answer against your contract.

Keep current contractual facts separate from marketing language. Confirm eligibility and future availability from your contract and current program documentation, and don't infer either one from a competitor's web page, a prior deal, or an outdated program description.

Document the decision and update cadence

Record the source, owner, effective date, and confidence level for every material input, and note which assumptions still need product, technical, legal, procurement, or finance validation.

Set review triggers for quote changes, hardware changes, workload growth, migration timing, product packaging, renewal dates, and service-scope changes.

Here's a question set you can bring into the buying process:

1. Which products, capacity units, add-ons, and support levels does this quote include, and what's excluded?
2. How many cores and vSAN TiB does the quote assume, and how were they counted?
3. What minimums, term length, and renewal mechanics apply, and where are they written?
4. Which credits or discounts are included, and what documentation supports them?
5. Which implementation or migration services are in scope, and which are billed separately?
6. Who owns hardware, lifecycle management, patching, monitoring, backup, recovery, and security operations?
7. Who owns capacity planning, incident response, connectivity, and vendor escalation?
8. How are midterm capacity increases priced and approved?
9. How are entitlements, portability, BYOL, bridge, or transition options handled, and what does the contract say about each?
10. What happens at the end of the term, including data movement, decommissioning, and termination?
11. Which product, packaging, or support changes during the term would change this quote?
12. What's the effective date of each answer, and who confirmed it?

How Flexential can support the VCF cost decision

An assessment is where the model meets your actual environment. Flexential analyzes data from your environment and builds a custom report on it, which lets you validate the estate, workload placement, dependencies, target operating model, migration sequence, service boundaries, and cost inputs against your own data.

As a Broadcom VMware Cloud Service Provider (VCSP) Pinnacle partner, Flexential offers Hosted Private Cloud with VCF 9, where Flexential manages the underlying infrastructure and platform operations. Managed Infrastructure gives you certified experts to help design, build, manage, and maintain your environment. Across on-premises, hosted, and hybrid designs, Flexential also supports migration through Cloud Migration, connectivity through Cloud Fabric, disaster recovery through DRaaS, and incremental capacity through Capacity on Demand.

If you expect to migrate but want to avoid a long-term commitment before you're ready, the VMware Continuum Program lets you keep operating your existing VMware environment under a flexible interim commercial model while you build a roadmap toward Flexential cloud solutions.

Flexential's role is to help you make assumptions explicit, compare responsibility models side by side, and bring out the implementation and operating costs a licensing quote doesn't show.

Turn the model into an assessment decision

To recap the method: start with required licensing capacity, build the complete three-year cost stack, normalize responsibilities and service scope, test the assumptions that move the total, and document every source. Built this way, VMware Cloud Foundation pricing becomes one well-documented input in a decision you can defend to finance, procurement, and leadership.

If you'd like help applying it, the Fast-Track Cloud Assessment comes at no cost and no obligation. It includes an infrastructure assessment based on your business goals and current environment, a modernization roadmap with sizing, VMware strategy, and VCF 9 recommendations where appropriate, and a cloud TCO and workload placement analysis across on-premises, private cloud, and hybrid cloud. Bring your current quotes, inventory data, growth assumptions, resilience requirements, and open operating questions to the assessment conversation.

Frequently asked questions

How is VMware Cloud Foundation licensing capacity determined?

VCF licensing capacity is based on the total physical CPU cores across every ESXi host you plan to license. Broadcom's core-counting guidance applies a technical minimum of 16 cores per physical CPU, so an 8-core CPU counts as 16. Broadcom's official license calculator can simulate required capacity for sample configurations. Any commercial order minimum is a separate term, so confirm it against your current quote and contract.

What costs belong in a three-year VCF TCO model?

A three-year VCF TCO model includes licensing and subscriptions, infrastructure and facilities, operations, protection and resilience, migration and overlap, growth, and exit costs. Subtract credits or avoided costs only when a quote, contract, or other written source documents them. Expected savings without documentation stay out of the model until they're confirmed.

How should on-premises and hosted VCF costs be compared?

Normalize the scope before you compare totals. Capacity, the workload set, resilience design, migration work, support window, connectivity, labor, service scope, and growth assumptions need to be equivalent across the on-premises and hosted options. If one quote assumes a smaller workload set, a lighter resilience design, or less labor than the other, adjust it until both describe the same environment, and only then compare the totals.

How is VCF purchased in a hosted or managed model?

It depends on the provider and the offer. In a hosted or managed model, licensing, infrastructure, and operations may be bundled into one service or priced separately.

Can VMware licenses move between operating models?

It depends on current program rules and your contract. Entitlements, portability, BYOL, bridge or transition options, and termination rights vary by program and agreement, and they can change over time. Before you model a move between on-premises, hosted, and hybrid options, get written confirmation from Broadcom or your provider and have your legal team review the terms.

How often should the VCF TCO model be updated?

Update the model whenever the quote, licensed capacity, workload growth, hardware plan, migration schedule, service scope, contract terms, or responsibility allocation changes. Any one of those changes can alter the three-year total, so treat each as a trigger for a fresh review. Before you make a decision, revalidate every claim that has changed against its current source.