VCF or VVF: Which VMware Bundle Actually Fits Your Estate
Since Broadcom collapsed VMware into two bundles, the question every renewal now turns on is simple to ask and easy to get wrong: do you need VMware Cloud Foundation, or is VMware vSphere Foundation enough. Most estates are quoted the larger one by default. Here is how to work out which actually fits what you run, before you pay for a stack you will never switch on.
When Broadcom simplified the VMware range, it did something useful and something expensive at the same time. The useful part is that there are now essentially two editions to choose between, not a confusing sprawl of point products. The expensive part is that the default quote, and the default assumption, is the larger of the two. A lot of organisations are now paying for the full private cloud platform when what they actually run is virtualisation and shared storage. This guide is about telling those two situations apart on evidence, not on the line item you were sent.
The two bundles, in plain terms
There are two subscriptions that matter for most enterprises. VMware vSphere Foundation, usually written VVF, is the virtualisation bundle: vSphere as the hypervisor, an entitlement to vSAN for hyperconverged storage, and the core management you need to run a cluster well. VMware Cloud Foundation, written VCF, is the full private cloud platform: everything in the virtualisation layer plus the integrated networking, automation, container and operations stack, packaged and lifecycle managed as one.
The shorthand that holds up in practice is this. VVF runs virtual machines properly. VCF runs a private cloud. If you think of your estate as servers that host workloads, you are probably a VVF estate. If you think of it as an internal platform that other teams consume through self service, with software defined networking and automated provisioning underneath, you are closer to VCF. The mistake is buying the platform when you only ever wanted the servers.
The decision is not "which is better". VCF is the more capable bundle, that much is not in dispute. The decision is whether you genuinely use, or will use within this term, the capabilities that VCF adds over VVF. If you do, VCF is fair value. If you do not, you are funding shelfware, and the gap between the two is where a large part of an avoidable renewal increase sits.
How the licensing maths works underneath both
Whichever bundle you land on, the commercial mechanics are the same and they matter more than the edition name. Licensing is by subscription, not perpetual, since Broadcom withdrew perpetual licences and made subscription the default. It is priced per physical core, and you license every populated core in every processor in the host. There is a floor of 16 cores per processor, so a CPU with fewer than 16 cores is still charged as 16, and a CPU with more is charged at its real count.
This is why two estates running identical workloads can be quoted very differently. A host built on high core count processors carries more licence than an older host doing the same job, because the unit of account is the core, not the workload. It is also why right sizing the bundle is only half the exercise. You can choose VVF correctly and still overpay if nobody has checked the core counts against what is actually powered on and in use. Get both right, the edition and the core baseline, and the number usually comes down.
What VCF adds over VVF
To choose well you need to know precisely what you are paying extra for. Beyond the vSphere and vSAN that both bundles share, VCF adds an integrated stack. The headline components are software defined networking and security, automation and self service provisioning, a container platform for running Kubernetes alongside virtual machines, and a deeper operations and lifecycle management layer that updates the whole platform as a single coordinated unit rather than component by component.
Each of those is genuinely valuable to the organisation that uses it. Software defined networking earns its place where you need micro segmentation, multi tenancy or network automation at scale. The automation layer earns its place where developers or internal teams provision their own environments and you want that governed rather than manual. The container platform earns its place where Kubernetes is a real part of your roadmap rather than a slide. The test for every one of them is the same: is this switched on, configured and depended upon, or is it a capability that came in the box and sits idle.
| Capability | VVF | VCF |
|---|---|---|
| vSphere hypervisor | Included | Included |
| vSAN storage entitlement | Included | Included, larger per core entitlement |
| Core management and operations | Included | Included, extended |
| Software defined networking and security | Not included | Included |
| Automation and self service provisioning | Not included | Included |
| Integrated Kubernetes and container platform | Not included | Included |
| Single coordinated lifecycle across the stack | Per component | Whole platform |
| Best fit | Virtualisation and shared storage estates | Genuine private cloud platforms |
Treat the table as a prompt, not a verdict. The component list tells you what is available. Only your own usage data tells you what is needed, and that is the part most renewals skip.
When VVF is the better fit
VVF is the right call more often than the default quote implies. It fits when your estate is, at heart, vSphere clusters running virtual machines, with vSAN or external storage underneath, and management handled through the standard tools. If your networking is done with physical switches and firewalls rather than VMware's software defined layer, if provisioning is handled by your platform team rather than self service portals, and if Kubernetes is either absent or run somewhere else entirely, then the additional VCF components are capabilities you would be buying and not using.
This describes a very large number of mid sized and even large enterprises. They run VMware extremely well, they depend on it, and they use perhaps a third of what the full platform offers. For them VVF is not a downgrade, it is an accurate match, and choosing it deliberately is one of the cleaner savings available at renewal. We see the same pattern repeatedly in entitlement reviews: the stack was sold as a platform and is being used as a hypervisor.
When VCF is genuinely justified
VCF earns its cost when you actually operate as a private cloud. That means software defined networking is in real use, not just licensed, for micro segmentation or multi tenancy. It means automation and self service are how environments get provisioned, with the governance and speed that brings. It means containers and virtual machines are managed together as a deliberate strategy. And it often means scale, because the lifecycle and operational advantages of managing the whole stack as one unit compound as the estate grows.
For these organisations VCF is not shelfware, it is the operating model, and trading down to VVF would mean dismantling things they rely on. The honest position is that plenty of large estates fall squarely in this camp, which is exactly why the answer to "should we leave VMware" is not always yes. If you are using the platform fully, you are getting platform value, and the conversation shifts from edition choice to negotiating that subscription well.
Go through the four VCF additions one by one, networking, automation, containers and unified lifecycle, and for each ask a blunt question: if this were switched off tomorrow, would anything break, and would anyone notice within a week. If the answer is no for most of them, you are a VVF estate paying VCF prices. If the answer is yes, VCF is doing its job.
How to map your actual feature consumption
The way to decide is not to read the datasheet and imagine which features you might like. It is to measure what you run today and what is genuinely on your roadmap, then map that to the smaller bundle that covers it. In practice that means a short, evidence led exercise:
- Inventory what is actually deployed and in use, not just licensed. Is the software defined networking layer carrying production traffic and policy, or installed and idle. Is the automation layer provisioning real workloads, or sitting unused behind manual processes.
- Establish the core baseline per host: processor core counts, how many are populated and powered, and how that interacts with the 16 core per processor floor. This is where the licence quantity, and a chunk of the cost, is actually set.
- Separate current use from roadmap. A capability you will genuinely deploy this term is a reason to license it. A capability you might explore one day is not, you can add it when it becomes real.
- Map the result to the smallest bundle that covers your real and committed use, then price both so the gap is explicit rather than assumed.
Done properly this is the difference between accepting the upsell and buying what you need. It is the same discipline whether you ultimately stay on VMware or use the exercise to inform a wider decision, and it is deliberately boring, because the savings come from rigour rather than cleverness.
The version 9 obligation that applies either way
One operational point sits underneath both editions and is easy to miss in a bundle conversation. Broadcom's version 9 terms introduce a compliance reporting requirement: you are expected to submit regular verified reports, and failing to do so on time can degrade management plane functionality and suspend support entitlements. It is not a paperwork footnote, it is an operational obligation that needs an owner, regardless of whether you land on VVF or VCF. Factor it into the running cost of either choice rather than discovering it after signing.
Not sure whether you need VCF or VVF?
Send us your current VMware quote or renewal and a rough picture of your estate. We will map your actual feature use and core baseline to the bundle that genuinely fits, and show you the gap in plain numbers. Independent, with no platform to sell and no preferred edition. We have sat on the other side of the table.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Where this sits in the bigger decision
Choosing the right bundle is the practical core of staying on VMware and doing it well. It is also one input into the larger question of whether to stay at all, which we lay out in our honest decision framework on leaving VMware. If your priority right now is simply the number, the renewal cost guide explains why the figure jumped, and the renewal cost calculator gives you a quick, no signup estimate to test the bundle decision against. For proof that getting this right pays off, our VMware licensing case study shows how an evidence led approach held one enterprise's renewal uplift well under 80 percent against a projection of up to 410 percent.
Frequently asked questions
What is the difference between VCF and VVF?
VMware vSphere Foundation (VVF) is the virtualisation bundle: vSphere as the hypervisor, a vSAN entitlement for storage, and core management. VMware Cloud Foundation (VCF) is the full private cloud platform: everything in VVF plus integrated software defined networking, automation and self service, a container platform, and unified lifecycle across the whole stack. VVF runs virtual machines well. VCF runs a private cloud.
Which bundle do most organisations actually need?
More often than the default quote suggests, the answer is VVF. A large number of estates run vSphere and vSAN with traditional networking and manual or platform team provisioning, and use little of what VCF adds. If your software defined networking, automation and container layers are not in genuine production use, you are likely a VVF estate being quoted VCF.
When is VCF worth the extra cost?
When you genuinely operate as a private cloud: software defined networking in real use for segmentation or multi tenancy, automation and self service as the way environments are provisioned, containers and virtual machines managed together by design, and usually scale where managing the whole stack as one unit pays back. For those estates VCF is the operating model, not shelfware.
How does the per core and 16 core minimum affect the choice?
Both bundles are priced per physical core, with every populated core licensed and a floor of 16 cores per processor. The edition sets what you can do, the core baseline sets how much you pay. Choosing VVF correctly still leaves money on the table if nobody has checked core counts against what is actually powered on and in use, so right sizing the bundle and validating the cores are two halves of the same exercise.
Can I start on VVF and move to VCF later?
In most cases yes, and that order is usually the safer one commercially. Licensing the smaller bundle that matches your real use today, then adding capability when a roadmap item becomes a genuine deployment, avoids paying for years of idle features. Buy for what you run and what you are committed to this term, not for what you might one day explore.