TL;DR · Key Takeaways
- VCF 9 gives you four adoption paths: deploy new, expand a fleet, converge an existing vCenter, or import one as a workload domain.
- Three of the four keep your running VMs in place. Only a greenfield build forces a workload migration.
- Converge and import are not the same: converge builds a new management domain from a standalone cluster, import folds a vCenter into a VCF instance you already run.
- The biggest consideration: a cluster already running NSX cannot be converged to a management domain on 9.0.0. Import it instead.
- Use the decision matrix and tree below to pick a path in minutes, not meetings.
Myth: adopting VCF 9 means rebuilding your estate from scratch and migrating every workload into it. Reality: that is the most expensive of four supported paths, and usually the wrong one. The VCF Installer and VCF Operations console now let you bring existing vSphere infrastructure under management with the VMs still running. The hard part is no longer the mechanics. It is choosing the right path for the estate you actually have.
The four adoption paths
- Deploy a new VCF instance. A clean build on new or repurposed hardware. The VCF Installer stands up a management domain with vCenter, NSX, VCF Operations, and VCF Automation. A new instance needs a minimum of 4 hosts for the management cluster.
- Expand an existing VCF fleet. Deploy an additional instance into a fleet you already operate, sharing common VCF Operations and VCF Automation. This is how you add a second site or region.
- Converge an existing vCenter. Re-use a standalone vSphere or vSphere-with-vSAN cluster and convert it in place into a VCF management domain. The Installer deploys into the same cluster as the residing vCenter and adds NSX, SDDC Manager, and the operations stack.
- Import an existing vCenter. From VCF Operations, fold an existing vCenter and all its clusters into a VCF instance you already run, as a VI workload domain. Workloads keep running throughout.
Converge versus import: the distinction people miss
These two get conflated constantly, and mixing them up leads to a design that will not validate. The simplest way to remember it: converge creates a brand new VCF instance out of a standalone cluster, so the converged cluster becomes the management domain. Import requires a VCF instance to already exist, and the imported vCenter joins it as a workload domain. That difference drives a real constraint. An existing vCenter that already has NSX installed is not supported for converging into a management domain on 9.0.0, where the Installer always deploys a fresh NSX. If your candidate cluster already runs NSX, the supported route is to build a new instance and import that cluster as a workload domain, where existing NSX can come along. I have seen teams burn a week trying to force a converge on an NSX-enabled cluster that was never going to pass validation. The hands-on converge procedure is in Part 13.
The decision matrix
| Dimension | Deploy New | Expand Fleet | Converge | Import |
|---|---|---|---|---|
| Best for | Hardware refresh, clean build | Adding a site to a fleet | Modernizing a standalone cluster in place | Folding existing vSphere into a running VCF |
| Starting point | New or repurposed hosts | An existing VCF fleet | Non-VCF vCenter, no NSX | Non-VCF vCenter, NSX optional |
| Resulting object | New management domain | New instance in fleet | New management domain | VI workload domain |
| Move workloads? | Yes, migrate in (HCX/vMotion) | Depends on use | No, preserved in place | No, preserved in place |
| Existing NSX | Fresh NSX deployed | Fresh NSX deployed | Blocks converge on 9.0.0 | Existing NSX can be imported |
| Minimum hosts | 4 (management) | Per new instance | 3 vSAN-ready, or 2 with NFS/FC | 3 vSAN-ready, or 2 with NFS/FC |
A 60-second decision tree
- Yes
- Need capacity at a new site? → Expand the fleet.
- Bring existing vSphere under it? → Import as a workload domain.
- No
- No estate to keep (refresh or clean build)? → Deploy new and migrate with HCX.
- Existing cluster to keep, NSX not yet on it? → Converge it to a management domain.
- Existing cluster that already runs NSX? → Deploy a new instance, then import the cluster.
Considerations worth planning for
- The 90-day clock. A new VCF 9 instance deploys in evaluation mode and is fully functional, but you must apply a license file within 90 days. Put a reminder on it the day you deploy.
- SDDC Manager is on the way out. SDDC Manager 9 is still installed as a component, but it will be deprecated in a future release. Build your runbooks around VCF Operations.
- Import is forgiving on hardware. It accepts single-pNIC hosts with LACP, two-node and stretched vSAN, HCI mesh, and external storage on NFS, VMFS-on-FC, or iSCSI. VCF 9.0.2 even added 1 GbE management network support, unblocking older brownfield sites.
- Import pulls in the whole vCenter. Every cluster under that vCenter comes in as part of the workload domain. If you only want some clusters under VCF, split the vCenter first.
What import will actually accept
Import is the most forgiving path, and knowing its real envelope changes how you sequence a brownfield estate. It accepts a wide range of configurations that converge will reject: single-pNIC hosts with LACP, two-node and stretched vSAN, HCI mesh, and external storage on NFS, VMFS-on-FC, or iSCSI. VCF 9.0.2 added support for 1 GbE management networks, which quietly unblocks older sites that previously could not be imported without a network redesign. The constraint to plan around is scope: import pulls in the entire vCenter, so every cluster under it becomes part of the workload domain. If you only want some clusters under VCF, split the vCenter first, because there is no partial import.
Sequencing a real adoption
For an estate with several clusters, the order matters as much as the path. The pattern I reach for is to identify one clean, NSX-free cluster as the seed, converge it into a management domain, and let that become the first VCF instance. Then import the remaining vCenters as workload domains into that instance, dealing with any ELM, switch, or DRS remediation per cluster as you go. Greenfield builds are reserved for genuine hardware refreshes, and fleet expansion comes later when a second site needs capacity. This sequence keeps workloads running throughout, turns a multi-week migration into a series of multi-hour onboardings, and means the first cluster you touch is the simplest one, so you learn the workflow on low risk before you import the messy brownfield clusters. The detailed mechanics of that first converge are in Part 13.
What I’d Do
The verdict, plainly: do not migrate workloads unless something forces you to. For most organizations sitting on healthy vSphere or vSphere-with-vSAN clusters, the right first move is to converge one clean, NSX-free cluster into a management domain, then import the rest of the estate as workload domains. Reserve the greenfield build for genuine hardware refreshes or a deliberate clean break. Expanding the fleet is a day-two decision once you have a first instance running. Picking import and converge over a rebuild typically turns a multi-week migration into a multi-hour onboarding, with no VM downtime in between. The architecture vocabulary behind these objects is in Part 2, and the prerequisites in Part 4. Which path fits your estate, and what is the one thing holding you back from starting?
References
- VCF Blog: Deployment Pathways for VMware Cloud Foundation 9
- Broadcom TechDocs: Import an Existing vCenter as a Workload Domain
- VCF Blog: How to Converge a vSphere Environment to VCF 9.0
About The Author
