Every team I talk to is calling the move from VCF 5.x to VCF 9 an “upgrade.” It isn’t. Calling it that sets the wrong expectations and gets people in trouble. VCF 9 is an architecture change wearing an upgrade’s clothing — and the sooner you treat it that way, the better your plan will be.
I’ve spent the last several months on exactly this transition inside our VMware ecosystem, and the pattern is consistent: the technical steps are documented well enough, but the shape of the platform changed underneath them. Things you took for granted in 5.x — Enhanced Linked Mode, the standalone SDDC Manager workflow, the comfortable distance between components — are either gone or folded into something new. If you go in expecting “5.2 but newer,” you’ll hit a wall at the prerequisite check and spend a week wondering why.
This post is the lay-of-the-land I wish someone had handed me before I started: what actually changed, where the real friction is, and how to sequence the work so you’re not rebuilding under pressure.
The mental model that breaks first
In VCF 5.x you thought in terms of a management domain plus workload domains, with SDDC Manager as the thing you logged into to do lifecycle work, and the Aria suite bolted on as separate Day-2 deployments you installed and lifecycle-managed yourself. That model is the first casualty.
In VCF 9, the platform is fleet-oriented and unified around two hubs: VCF Operations and VCF Automation. SDDC Manager hasn’t vanished, but its interface has been pulled into VCF Operations under fleet management — the workflows you knew are still there, just relocated and renamed. The standalone Fleet Management appliance that existed in 9.0 is gone in 9.1, converged into Operations as a “fleet lifecycle” component. Directly hand-managing vCenter outside that orchestration is effectively deprecated; break out of the managed model and you break supportability.
The practical consequence: roles and runbooks written against the 5.x SDDC Manager UI need rewriting, and the muscle memory of your operators needs retraining. Budget for that explicitly. It’s the cost nobody puts in the project plan.
Worth knowingVCF 9.1 lets VCF Operations manage an existing vSphere 8.0 Update 3+ environment as a workload domain. If you’ve been saying “we can’t move to VCF until the vSphere refresh is done,” this changes the sequencing conversation — you can wrap legacy vCenters under Operations now and migrate the underlying clusters into full VCF domains on your own timeline.
NSX is no longer optional
This is the one that catches compute-focused shops off guard. In VCF 9, the management domain requires NSX. Even a compute-only deployment pulls NSX into the picture. If your team has lived comfortably in VLAN-backed port groups on a vSphere Distributed Switch and never touched an overlay, you now have Geneve, Tier-0/Tier-1 routing, and Edge clusters on your critical path.
I’ve written before about the NSX-V to NSX-T migration playbook, and everything painful about that move applies double here, because now it’s a prerequisite rather than a project you chose. The failure mode is ugly: a misconfiguration during the network cutover can isolate an entire cluster. If your network engineers haven’t done overlay networking, the single highest-leverage thing you can do is get them hands-on in a lab before the production window, not during it.
What to validate before you even start
The VCF 9 import/convergence process runs a comprehensive validation pass, and most brownfield environments fail it the first time. The recurring offenders:
- Enhanced Linked Mode — not supported the way it was; you’ll need to remediate or remove it before convergence is allowed.
- vSphere Distributed Switch version — older VDS versions must be upgraded to a supported level first.
- Standalone hosts in inventory — there can be no standalone ESXi hosts hanging off the vCenter inventory; move them into a cluster or remove them.
- vmkernel IP addressing — all vmkernel adapters need statically assigned IPs, and once the network pool is created during import, those addresses must not change.
- Existing NSX — environments with NSX already installed aren’t initially supported for convergence into a management domain; a fresh NSX instance gets installed as part of the process.
Run that checklist as a pre-flight weeks ahead. Every item on it is something you’d rather fix on a Tuesday afternoon than discover at hour two of a migration window.
Storage: the hardware refresh hiding in the software upgrade
vSAN OSA isn’t deprecated in VCF 9 — I want to be precise about that, because there’s a lot of FUD floating around. But the platform’s center of gravity has shifted hard toward vSAN Express Storage Architecture (ESA), and ESA’s hardware requirements are meaningfully different: it wants all-NVMe. There’s no in-place OSA-to-ESA conversion. The path is to stand up new ESA nodes, Storage vMotion the data across, and decommission the old nodes — which means you need temporary swing capacity in the rack during the transition.
For a lot of shops, “upgrade to VCF 9” therefore quietly contains “buy new storage hardware.” If that CapEx line isn’t in your plan, the plan isn’t real yet. The upside is genuine — global dedup and enhanced compression in 9.1 are claiming up to ~39% lower storage footprint, and NVMe memory tiering changes the DRAM math — but those are modern-hardware features. You don’t get them on the boxes you’re running today.
The licensing reality nobody enjoys
I’ll keep this factual rather than editorial, because your mileage depends entirely on your hardware. The move from perpetual, socket-based licensing to core-based VCF subscription changes the cost structure. For environments running high-core-count CPUs — think 64-core EPYC parts — the same physical footprint can land at materially higher subscription cost than the perpetual licenses it replaces. Reports of 2–3x are common enough that you should model your own core counts honestly before you assume the TCO story works in your favor.
The counter-argument Broadcom makes is that VCF is a full stack — compute, storage, networking, operations, automation — and that if you actually use all of it, the bundled value offsets the increase. That can be true. But it’s only true if you adopt the whole suite, which loops back to the retraining and re-architecture costs above. Decide with a spreadsheet, not a vibe. And note the clock: vSphere 8 general support ends October 11, 2027, so the window to plan deliberately rather than react is finite.
ImportantDon’t let the support-end date stampede you into a rushed greenfield. The vCenter-as-a-workload-domain capability in 9.1 exists precisely so you can decouple “get under VCF management” from “rebuild every cluster.” Use it to buy yourself a phased runway.
How I’d sequence it
If I were scoping this from scratch today, the order that’s been working:
- Inventory and validate. Run the convergence pre-checks against every cluster. Fix ELM, VDS versions, standalone hosts, and vmkernel addressing first. This is unglamorous and it’s where the schedule is won or lost.
- Get the network team overlay-fluent. Lab NSX-T Tier-0/Tier-1 and Edge clusters until a cutover is boring.
- Model storage and licensing honestly. Count cores. Price ESA swing hardware. Put both in the plan as real line items.
- Wrap legacy first. Use VCF Operations to bring 8.0 U3+ environments under management as workload domains, so you get fleet visibility before you commit to rebuilds.
- Migrate in waves. Domain by domain, never big-bang. The blast radius of a unified platform is larger by design — respect it.
The thing I keep coming back to: VCF 9 is a good platform, and the 9.1 maturity work is real. But the reason it “causes you to rethink implementation” — to use the phrase that’s been rattling around my head all spring — is that it collapses the loosely-coupled pieces you’d been operating independently into one tightly-integrated fleet. That’s more power and less slack. Plan for the loss of slack, and the rest follows.
In a follow-up, I’ll go through what VCF 9.1 specifically adds on top of 9.0, and which of the launch headlines actually matter for operators versus which are AI-keynote garnish.