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 in 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.

Concretely, the controls that used to be scattered across SDDC Manager, Aria Operations and Aria Lifecycle now surface in one console. Fleet and instance health, patching and lifecycle, certificate rotation, password and account management, configuration compliance and drift, capacity and cost, and log analytics all run from VCF Operations. That consolidation is the single best reason to start your runbook rewrite by searching for every step that says open SDDC Manager and asking where the same task lives now.

How the VCF Installer changed

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.

---

Fleet, the new top-level construct

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.

Native Kubernetes and a faster core engine

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.

Memory tiering is the one worth understanding early, because it changes sizing math rather than just performance. With NVMe tiering a host can present more usable memory than its installed DIMMs, which lifts consolidation ratios on memory bound clusters. It is not free capacity, the flash tier is slower than DRAM and it has to be on the compatibility list, so treat it as a planning lever you validate, not a number you assume.

Licensing under one subscription

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 and HA deployment models

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.

I learned that appliance count the expensive way. On an early VCF 9 build I sized the management cluster around the Simple model, seven appliances, and two weeks in the customer decided they wanted HA after all. Going from seven appliances to thirteen meant the four host management cluster no longer had the headroom, so we added two hosts and re-ran a chunk of the bring-up. A day gone to a decision that should have taken five minutes at design time. Pick Simple or HA before you order hardware, not after.

What did not change

Be 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.

Who should move now, and who should wait

Greenfield shops have the easiest call. You get the simpler platform with none of the migration debt, so there is little reason to deploy 5.x today. Build on VCF 9 and skip a forced upgrade a year from now.

Brownfield 5.x estates should separate two things that get conflated, the upgrade mechanics and the operational relearning. Mechanics are well trodden. Relearning is the real project, because every runbook that references SDDC Manager or Aria has to be rewritten against VCF Operations and Automation. Budget for that, and if your team is thin, let 9.1 settle before you commit a large estate.

Anyone still on perpetual licensing needs to model the subscription math before anything else. The per core subscription carries a 16 core per CPU minimum, so a host with two 8 core CPUs licenses as if it had 32 cores. On small or oddly specced hosts that changes your cost per socket enough to influence which servers you keep. Work that number out on your real hardware before you fall in love with the platform.

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.

The habit that took me longest to break with VCF 9 was reaching for SDDC Manager out of muscle memory. On my first real 9.0 environment I spent twenty minutes hunting for a workflow that had quietly moved into VCF Operations, convinced something was broken, before it clicked that the home base had genuinely changed. Every engineer I have onboarded since has hit the same wall in their first week. Budget for the relearning, not just the upgrade, because the platform got simpler while the muscle memory got in the way, and the teams that plan for that first confused week move far faster than the ones that assume nothing moved.

Where to start your evaluation

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?

Three things are worth doing in your first week of evaluation. Inventory every runbook that names SDDC Manager or Aria, because that list is your real migration backlog. Decide Simple or HA before you size hardware, so the management cluster is right the first time. And model the per core cost on your actual host specs, including the 16 core minimum, before you present a number to anyone. Do those three and the rest of this series lands on solid ground.

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