Here is the line I keep repeating in design workshops: VMware Cloud Foundation 9 is not VCF 5.x with a fresh coat of paint. The components look familiar (vSphere, vSAN, NSX), but the center of gravity moved. In VCF 9, private cloud operations and consumption are the product, and the old collection of separately installed, separately licensed, separately lifecycle-managed pieces is now one stack with one installer and one subscription. If you walk in expecting an incremental upgrade, the first surprise is how much of your operational muscle memory no longer applies.
What VCF 9 actually is
VCF 9.0 reached general availability on 17 June 2025, and VCF 9.1 followed on 27 May 2026. Both are built on a single integrated stack: ESX and vSphere for compute, vSAN for storage, NSX for networking, and two components that used to be optional Day-2 add-ons, VCF Operations and VCF Automation, now sitting in the core. That last part is the headline. In VCF 5.x you deployed Aria Operations and Aria Automation separately and lifecycle-managed them yourself. In VCF 9 they are rebranded, deployed by the unified installer, and lifecycle-managed by the platform.
The components you already know are still here. vCenter still manages clusters, ESX still runs the VMs, vSAN still pools local NVMe, NSX still does the overlay and the distributed firewall. What changed is the layer that ties them together and the way you operate and consume the whole thing.
VCF Operations is the new home base
The single biggest day-to-day change is where you point your browser. VCF Operations is now the primary administrative surface: fleet-wide health, patching, certificate rotation, compliance, capacity, and lifecycle all run from one console. The SDDC Manager UI that anchored VCF 5.x is deprecated. SDDC Manager itself still ships (it is installed and upgraded as a component of every VCF 9 instance), and a handful of operations still touch its API, but Broadcom has stated it will be deprecated in a future release. Build your runbooks around VCF Operations, not SDDC Manager, or you will be rewriting them next year.
VCF Automation is the consumption side of the same coin: self-service provisioning, blueprints, multi-tenancy through organizations and projects, served from the same fleet. If your team built Aria Automation blueprints, they carry forward conceptually, but they need to be revalidated against VCF Automation rather than lifted unchanged.
The installer changed too
The VCF Installer appliance replaces Cloud Builder. It is UI-driven and, to the relief of anyone who has fought the old Excel deployment parameters workbook, it no longer needs that spreadsheet. There is a catch worth knowing up front: unlike Cloud Builder, the Installer does not bundle the binaries. It downloads them from the Broadcom depot online, or from a customer-hosted offline depot that you can share across multiple instances. On a slow link, that download is the longest single wait in a bring-up, so start it early. The deeper trade-off is that validation now runs live against your DNS, NTP, and network instead of against a static file you could fudge. The wizard is less forgiving than the spreadsheet was, which is a good thing once you accept it. We walk through the bring-up itself in the management domain bring-up guide.
The fleet: the new top-level idea
The organizing concept that did not exist in 5.x is the fleet. A fleet is a collection of one or more VCF instances that share common VCF Operations and VCF Automation. The first instance you deploy hosts those fleet services in its management domain. When you add a second site or region, you expand the fleet rather than standing up an island. This is what makes VCF 9 feel like a single private cloud rather than a set of independent SDDCs, and it is the structure the whole series leans on. We unpack the hierarchy in the VCF 9 architecture explainer.
Kubernetes is native, and the engine got faster
The vSphere Supervisor exposes VM Service and VKS (vSphere Kubernetes Service), so VMs and containers run under one control plane instead of a bolt-on. VKS multi-cluster management absorbs much of what Tanzu Mission Control used to do. Under the hood, VCF 9 adds genuinely useful core-engine features: NVMe memory tiering to extend RAM with flash, vSAN global deduplication across clusters, and data-path offloads for DPU-equipped hosts. These are not marketing footnotes, they change sizing and cost math, but they are the kind of thing you tune after the platform is standing, not before.
One license, and a sting in the tail
VCF 9 is a single per-core subscription that bundles vSphere, vSAN, NSX, SDDC Manager, Operations, Automation, and Kubernetes. That simplifies procurement enormously compared to the old a-la-carte SKUs. The detail that catches teams out is that general-purpose load balancing is no longer inside the entitlement: the built-in NSX load balancer is deprecated, and production application load balancing now means buying Avi separately. The full picture, including the 16-core-per-CPU minimum and the bundled vSAN TiB entitlement, is in the VCF 9 licensing breakdown.
What that one subscription covers is broad: vSphere, vSAN, NSX, HCX, VCF Operations, VCF Automation, vSphere Kubernetes Service and the VCF Private AI services are all inside the per-core entitlement. The advanced services are where the money hides. Avi Load Balancer, vDefend Firewall and VMware Live Recovery are licensed separately, on top of the base subscription. So budget the base per-core cost first, then add line items for whichever advanced services your design actually needs: load balancing almost always, lateral security and disaster recovery often.
Simple or HA: what you are signing up for
VCF 9 gives you two deployment models, and the difference is not cosmetic. The Simple, single-node model is a minimum of seven appliances: vCenter, SDDC Manager, one NSX Manager, one VCF Operations with its Fleet Manager and Collector, and one VCF Automation. The High Availability model is a minimum of thirteen, because NSX Manager, VCF Operations, VCF Automation, and Operations for Logs each become three-node clusters. That jump is the honest cost of resilience, and it lands almost entirely on the management domain. Production runs HA. Labs and edge sites can take Simple. Knowing the appliance count up front is what stops the management cluster being under-sized, which is the most common first-deployment regret.
What did not change
It is worth being clear about the continuity, because the shift is easy to overstate. Your VMs run on ESX exactly as before. vSAN policies, NSX segments and distributed firewall rules, vMotion, DRS, and HA all behave the way you expect. The vSphere Client is still where you do most VM-level work. What moved is the layer above: fleet-wide operations, lifecycle, and consumption. So the learning curve is real but bounded. You are not relearning vSphere, you are relearning where the platform-level controls live and which console owns them. Teams that frame it that way move faster than teams that treat the whole thing as a green-field skill set.
My take
Do not let the unified-platform messaging convince you the migration is trivial. The platform genuinely got simpler. Your first ninety days got harder, because every click-SDDC-Manager step, every Aria runbook, and every operational habit has to be relearned against VCF Operations and Automation. Greenfield shops win big here and should move with confidence. Brownfield 5.x shops should budget more for retraining and runbook rewrites than for the upgrade mechanics themselves. That is the part the brochure will not tell you, and it is the part that decides whether your first quarter on VCF 9 is smooth or painful.
What’s Next
If you are evaluating VCF 9, start by mapping which of your current operational runbooks reference SDDC Manager or Aria directly, because those are your real migration backlog. What is the first VCF 5.x habit you expect to be hardest to unlearn?
References
- VCF Blog: What’s New in VMware Cloud Foundation 9.0
- VCF Blog: Deployment Pathways for VMware Cloud Foundation 9
- VCF Blog: VCF 9.0 Purpose-Built for App Modernization
About The Author
