If you’re running vSphere 8 Update 3i today and you’re a VMware Cloud Foundation (VCF) customer — not a VMware vSphere Foundation (VVF) customer — you have a decision in front of you that’s bigger than a typical point-release upgrade. Moving to VCF 9.1 isn’t just about newer ESXi and vCenter builds. It’s about deciding how your management stack is going to be architected for the next several years: which domain model you land on, how you handle NSX, and how much of your existing storage investment carries forward.
That distinction between VCF and VVF matters from the first planning conversation. VVF customers stop at vSphere, vSAN, and Aria Operations — there’s no SDDC Manager, no NSX Manager, and no fleet-level domain model to design around. VCF customers are signing up for the full stack: SDDC Manager-managed domains, a mandatory NSX Manager, and Aria/VCF Automation as part of the fleet. Everything below assumes you’re going the full VCF route, because the domain and networking decisions simply don’t apply the same way to a VVF-only deployment.
This post walks through how to plan that upgrade: the tools worth using before you touch a host, how to think about domain topology, what your storage options actually are (spoiler: you are not required to run vSAN), and how NSX factors in even if you have no intention of running an overlay network.
Start With the Right Planning Resources
Before you build a runbook, it’s worth spending twenty minutes with a few resources that will save you from re-deriving information that’s already been worked out.
- VCF Upgrade Planner — This is the single best starting point. It’s an interactive tool from VMware/Broadcom that asks about your current environment (vCenter, ESXi, NSX, Aria Operations/Automation, and even Dell VxRail versions where applicable) and your target VCF version, then generates a tailored upgrade path. It covers four distinct scenarios: upgrading to vSphere 9.1 without adopting VCF, upgrading vSphere/Aria first and converging to VCF later, standing up a brand-new VCF 9.1 fleet from an existing vSphere estate, and expanding an existing VCF fleet. Output can be worked through interactively or exported to PDF, which is handy for change-control paperwork.
- William Lam’s write-up on the planning tool — A good walkthrough of what the planner actually produces once you fill it out: phased workflows for maintenance-window planning, networking and resource requirements, and callouts on common pitfalls.
- Broadcom’s official upgrade documentation — The authoritative source for supported versions and sequencing. This is the one to keep open in a tab while you build your runbook, since it’s what Broadcom Support will hold you to.
- gibsonvirt.com’s walkthrough of the conversion process — A practical, screenshot-driven account of taking a vSphere 8 cluster through vCenter upgrade, VCF Installer deployment, and convergence into a management domain.
- virtualvmx.com’s two-site, no-spare-hosts scenario — Worth reading specifically for its treatment of a consolidated domain model and how NSX behaves when it’s deployed without an overlay.
- vrcloud24x7.com’s field notes on the 8.x-to-VCF transition — Useful for the “this is a platform change, not a patch” framing, and its pre-flight checklist around DNS, NTP, and certificates.
None of these replace Broadcom’s documentation as the source of truth, but between them you’ll have a much clearer picture of what to expect before you start touching production infrastructure.
Step One: Decide on Your Domain Topology
This is the decision that shapes everything else, and it’s worth getting right before you upgrade a single host. VCF organizes infrastructure into domains, and there are three models to understand.
Management domain. This is a dedicated cluster that runs the control plane for the entire VCF instance and, by extension, the fleet: SDDC Manager, vCenter, a dedicated NSX Manager, and the VCF Operations and VCF Automation components. It can also host Edge nodes and, if you have spare capacity, business workloads — but its primary job is running VCF itself. Broadcom’s design guidance points toward a minimum of four hosts in an N+1 configuration for resiliency, though your actual sizing will depend on the scale of the fleet components you’re running.
VI workload domain. A separate vCenter (which can share an NSX Manager instance with other workload domains) paired with one or more vSphere clusters, dedicated to running your actual application workloads. Broadcom’s minimum here is three hosts in a 2+1 HA configuration, and workload domains are flexible enough to reuse your existing storage — you’re not locked into a specific array or storage architecture just because you’re moving to VCF.
Consolidated domain. This is where the vSphere 8 upgrade planning gets interesting, and where I want to sharpen the framing a bit. A consolidated domain runs management components and workload VMs on the same physical hosts, separated logically by resource pools rather than by dedicated hardware. It’s not that a consolidated domain can’t run workloads beyond “just operations” — it absolutely can, and that’s the point of the model. The issue is risk concentration: mixing your SDDC Manager, NSX Manager, and Aria stack on the same cluster as production application workloads means a single hardware failure, a noisy-neighbor resource contention event, or a botched maintenance window can take down both your infrastructure control plane and your business workloads at once. Broadcom’s own guidance is explicit that consolidated architecture is appropriate for lab, demo, and non-production environments — not for anything carrying real production SLAs.
For a lot of vSphere 8 U3i customers, the consolidated domain is going to look attractive purely because of the math: you already have a 3-4 host cluster, and converging it into a consolidated domain is the path of least resistance. That’s a legitimate way to get your feet wet with VCF, or to run a genuinely small, low-criticality environment. But if you’re planning to run meaningful production capacity on top of this — not just the fleet’s own management footprint — budget for a dedicated management domain plus at least one separate VI workload domain. Trying to retrofit that separation later, after you’ve built everything on a consolidated model, is a much bigger project than doing the host math up front.
Practical takeaway: if your current vSphere 8 environment is a lab, a POC, or a small environment where an outage is an inconvenience rather than an incident, consolidated is fine and will get you converged with the fewest hosts. If you’re supporting anything with a real SLA, plan for a dedicated management domain from day one, even if it means acquiring additional hosts before you start the conversion.
One more sizing note for the management domain specifically: its footprint isn’t static once you’re converged. SDDC Manager and VCF Automation ship as fixed-size appliances that don’t grow with the fleet, but VCF Operations is explicitly sized against monitoring scale — the number of hosts, VMs, and objects it’s watching across the fleet — and Broadcom’s own sizing guidance tells you to pick a tier with future growth in mind, not just your day-one footprint. In practice that means every additional workload domain you bring online adds some incremental load to the management domain’s compute and storage, even though the domain’s own host count doesn’t need to change in lockstep. Build a little headroom into your four-host management domain rather than sizing it exactly to what day-one requires.
Step Two: Upgrade Options — And Why vSAN Isn’t a Requirement
A common assumption is that moving to VCF means moving to vSAN, largely because most VCF reference architectures and marketing lean heavily on vSAN ESA as the default storage layer for new (greenfield) deployments. That’s guidance, not a hard requirement, and it’s worth separating the two.
Broadcom’s own documentation for the vSphere-8-to-9.1 upgrade path lists vSAN as explicitly optional at the vCenter/ESXi upgrade stage — the supported components are vCenter 8 U3 and later, ESXi 8 U3 and later, and vSAN 8 U3 and later if you’re running it, with no indication that vSAN adoption is a prerequisite for the upgrade itself. If your current vSphere 8 environment is running on Fibre Channel, iSCSI, NFS, or vVols against an external array, that storage relationship isn’t something the upgrade forces you to abandon. Workload domains in particular are built to accommodate existing storage rather than mandate a rip-and-replace to HCI.
Where this gets nuanced is at the design layer once you’re fully converged: Broadcom’s day-two guidance for new management domain builds does lean toward vSAN (specifically vSAN ESA) for the management cluster, largely because it simplifies lifecycle management and removes external SAN dependencies from your most sensitive infrastructure tier. If you’re standing up a brand-new management domain as part of this upgrade rather than converging an existing cluster, it’s worth planning for vSAN ESA-capable hardware even if you don’t strictly need it elsewhere. But for workload domains, and for brownfield conversions of clusters you’re already running successfully on array-based storage, there’s no requirement to change your storage architecture just to get to VCF 9.1.
Broadly, you’re looking at two upgrade motions, and your storage architecture doesn’t have to dictate which one you pick:
- Single-motion convergence — Upgrade vCenter and ESXi first, then run the VCF Installer to deploy NSX Manager and SDDC Manager and converge directly into a VCF 9.1 domain. This is the faster path if your environment is already clean and you don’t need a checkpoint between the vSphere upgrade and the VCF convergence.
- Phased upgrade — Upgrade vCenter, ESXi, and Aria Operations to current versions first, running as an upgraded vSphere Foundation environment without SDDC Manager or NSX Manager deployed yet, and converge to full VCF in a second, later phase. Broadcom is explicit that this is a legitimate first phase, but with a caveat worth flagging to any stakeholders: you can’t use VCF 9.1 capabilities — domains, fleet management, NSX-driven networking — until the components that provide them are actually deployed. If your organization needs a change-control checkpoint between “vSphere is current” and “we’re on VCF,” this phased approach gives you that pause without leaving you unsupported in between.
Neither path requires you to have adopted vSAN beforehand, and neither path forces you onto it during the upgrade. Where you land on storage should be driven by your workload domain’s actual requirements and your existing array’s remaining useful life — not by an assumption that VCF equals vSAN.
Step Three: NSX Requirements and the VLAN/Flat Network Path
This is the piece that trips up the most vSphere 8 U3i customers moving to VCF for the first time, largely because “NSX” and “overlay networking” have become synonymous in a lot of people’s mental models. They’re not the same thing, and understanding the difference will save you a networking redesign you may not actually need.
NSX Manager is a mandatory component of a VCF management domain. It’s deployed during convergence regardless of whether you intend to use overlay networking, because it’s part of how VCF manages its own fleet-level networking and segment control — this is a structural difference from VVF, which has no NSX Manager requirement at all. If you’re coming from vSphere 8 with no NSX in your environment today, that’s a new piece of infrastructure to plan capacity and design time for, even if your actual data-plane networking doesn’t change.
What you’re not required to do is deploy NSX overlay networking with GENEVE encapsulation, TEP VMkernel interfaces, and stretched Tier-0/Tier-1 gateways. VCF’s fleet-level networking design supports two models for management components:
- The VLAN-backed (flat network) model — Management components sit on dedicated VLANs with straightforward routing and firewall-based segmentation. There’s no overlay, no GENEVE encapsulation, and you keep your standard 1500-byte MTU rather than needing the larger MTU that overlay networking typically calls for. NSX Manager still exists and still manages these segments, but it’s operating in a much simpler mode than a full overlay deployment.
- The NSX overlay segment model — Management components run on NSX overlay segments, which unlocks IP mobility for fleet-level VMs and, if you’re running a multi-instance fleet, segment stretching across sites via NSX Federation, with Tier-0/Tier-1 gateways handling routing and optional load balancing.
For a single-site VCF deployment with no requirement to move management VMs’ IP addresses around or stretch networking across locations, the VLAN-backed model is a completely supported, production-ready choice — not a lab shortcut. Broadcom has also confirmed that existing brownfield environments already running management components on NSX VLAN-backed segments can stay there after upgrading to 9.1 without being forced to migrate to overlay; overlay is recommended as a best practice for new (greenfield) deployments, not mandated for everyone.
The practical implication for planning: if your vSphere 8 U3i environment is a flat, VLAN-based network today with no overlay ambitions, you can carry that design forward into VCF 9.1. Budget the engineering time for standing up and managing an NSX Manager instance — new certificates, new upgrade cadence, a new component in your monitoring and backup strategy — but you don’t need to budget for a networking re-architecture unless you specifically need the IP mobility or multi-site stretching that overlay networking provides. Save that conversation for when you actually have a multi-instance fleet or a workload that needs it.
Common Pitfalls Worth Planning Around
A few issues show up repeatedly across the field reports and official documentation, and they’re worth building into your plan rather than discovering mid-maintenance-window.
The VCF Installer has replaced Cloud Builder, and it wants a clean environment. If you’ve used Cloud Builder for a VCF deployment before, don’t assume the workflow carries over. The VCF Installer is stricter about DNS resolution (forward and reverse, for every component you’re deploying), NTP synchronization, and certificate validity than its predecessor was. Environments that have been running for years on vSphere 8 tend to accumulate exactly this kind of drift — a stale reverse DNS zone, an NTP source that quietly stopped syncing, a certificate that’s technically valid but issued from a CA chain nobody’s touched since the original build. Run a dedicated pre-check pass on these three items specifically before you schedule anything.
Aria Operations version compatibility is a real gate, not a suggestion. The upgrade sequencing generally wants VCF Operations upgraded ahead of vCenter, not after, and the supported version matrix between Aria/VCF Operations and the vSphere versions you’re targeting is narrower than people expect. Check the compatibility matrix for your specific Aria Operations build before you touch anything else — an incompatible Aria version can block or complicate the rest of the sequence.
Image-based lifecycle management changes your patching model. Once you’re converged into VCF, vSphere Lifecycle Manager image compliance becomes an enforcement mechanism rather than a convenience feature. Hosts that were running heterogeneous driver or firmware versions under baseline-based patching in vSphere 8 will need to be reconciled to a single cluster image before or during the upgrade. If your current cluster has accumulated per-host inconsistencies — different firmware revisions after piecemeal hardware refreshes, for instance — plan time to remediate that as part of the project, not as a surprise you find during ESXi upgrade validation.
Management appliance protection needs its own design, especially in multi-site environments. SDDC Manager, vCenter, and NSX Manager generally need to be treated as independent, site-local components rather than something a single DR tool can fail over wholesale — SRM, for example, can’t protect the vCenter instance it’s running inside of. If you’re planning a two-site VCF deployment, decide early which appliances get replication-based protection (via VMware Live Recovery or similar), which get backup/restore treatment with a fresh deploy at the recovery site, and which are simply independent per site. This is a design conversation, not a checkbox, and it’s much easier to have before convergence than after.
Licensing and entitlement mapping takes longer than the technical upgrade — and don’t forget to license the management domain itself. Confirming your Broadcom account has the correct VCF 9.1 entitlements, generating the right license keys, and getting the download token configured in the VCF Installer’s depot settings is frequently the slowest part of the whole project — not because it’s technically hard, but because it usually routes through account and licensing teams outside of infrastructure. Kick this off in parallel with your technical planning, not after it.
It’s also worth being explicit about a detail that’s easy to gloss over when you’re spec’ing hardware: VCF’s licensing model is per-core across every ESX host in the environment, and per Broadcom’s own licensing documentation there’s no domain-specific exemption or discount — management domain hosts consume license capacity exactly the same way workload domain hosts do. That four-host management domain running nothing but SDDC Manager, NSX Manager, and your Aria/VCF Operations and Automation stack still needs to be fully licensed, and those cores need to be accounted for in your budget the same as any workload-facing capacity. It’s a reasonable position to think Broadcom should treat management domain infrastructure differently, since it’s running the platform itself rather than customer-facing workloads — but that’s not currently how the licensing model works, so plan and budget for it as real, billable core count rather than assuming it’s bundled in.
Putting a Sequence Together
Pulling this into a rough planning sequence for a single-site VCF customer coming from vSphere 8 U3i:
- Run the VCF Upgrade Planner against your actual current-state versions and get a tailored path and phase breakdown. Export it to PDF for your change-control documentation.
- Decide your domain topology before touching anything — consolidated for lab/small/non-production, dedicated management domain plus workload domain(s) for anything carrying a real SLA. Confirm host counts against the model you’ve picked.
- Confirm your storage plan. If you’re converging existing hosts on array-based storage, you don’t need to add vSAN to get to 9.1. If you’re building a new management domain from scratch, evaluate vSAN ESA for that cluster specifically.
- Decide your networking model for NSX. Flat/VLAN-backed if you’re single-site with no IP mobility requirement; overlay if you need segment stretching, Federation, or fleet-level IP mobility.
- Validate infrastructure fundamentals — DNS forward and reverse lookups, NTP sync, and certificate chains across every component. These are unglamorous but are consistently the source of failed convergence attempts.
- Upgrade vCenter and ESXi first, whether you’re going straight to full convergence or taking the phased route through an upgraded vSphere Foundation environment.
- Deploy the VCF Installer, then NSX Manager and SDDC Manager, and converge into your chosen domain model.
- Validate the fleet — inventory, image compliance, and integration testing against AD, monitoring, and backup tooling before you call the upgrade complete.
Where This Leaves You
The version bump from vSphere 8 U3i to VCF 9.1 is really three separate decisions wearing one trench coat: a domain architecture decision, a storage decision, and a networking decision. None of them are forced by the upgrade itself — you can keep your array-based storage, you can stay on flat VLAN networking, and you can start on a consolidated domain if that’s genuinely appropriate for what you’re running. What the upgrade does force is picking a direction deliberately rather than defaulting into whatever the installer wizard suggests, because the domain model in particular is expensive to change after the fact.
Run your environment through the VCF Upgrade Planner first, use it to generate a phase-by-phase plan, and treat the domain topology decision as the one item on this list that deserves a real design conversation — everything else in this post follows from getting that one right.