You will take an existing vSphere environment that already runs vSAN storage and NSX networking, and bring it under VCF management as a VI workload domain. Import keeps the vCenter, the hosts, the vSAN datastore and the NSX configuration in place, so nothing is redeployed and no workload moves. After import completes, the domain appears in the VCF Operations fleet inventory and gains VCF lifecycle and fleet management.

Import differs from converge in one important way. Converge turns a standalone vSphere environment into your first VCF management domain when you have no VCF yet. Import assumes a VCF instance already exists and adds the brownfield environment alongside it. If you are starting with no VCF at all, follow the converge walkthrough in Part 15 first, then return here to bring in your remaining estates. Import registers the environment the same way a native VI workload domain is created, so day 2 operations behave consistently across both.

Prerequisites

Work through every row before you start. A single missing reverse DNS record or an unsynced clock will stop the precheck, so clear these first.

What import changes and what it leaves alone

Import is a control plane operation. It records your vCenter, clusters, hosts, vSAN datastore and NSX configuration in SDDC Manager and the VCF Operations fleet inventory, and it registers the domain for VCF lifecycle. Your running virtual machines keep running. No host is reinstalled, no datastore is reformatted, and no NSX segment is recreated. Because of that, import carries no guest workload downtime by itself. Import does activate NSX on the distributed virtual port groups in each imported cluster, which turns on the distributed firewall with default rules that allow all Layer 2 and Layer 3 traffic, so review those rules once the domain is in.

After import, a few management behaviors change. Lifecycle for the imported domain now flows through VCF, so future ESX and NSX updates come from the VCF depot rather than standalone tooling. Password and certificate rotation for the domain move under VCF management. Plan a short maintenance window for the import run so no one edits the source vCenter while the workflow writes its inventory, even though guest workloads stay online.

Step 1, verify the source versions and health

Confirm the source estate clears the version floors and reports no storage or NSX faults.

1. Log in to the source vSphere Client as administrator@vsphere.local.
2. Open Menu, then Administration, and read the vCenter build under Deployment.
3. Confirm that build maps to vCenter 8.0 Update 3a or later.
4. Select each cluster, open the Hosts tab, and confirm every host runs ESXi 8.0 Update 3 or later.
5. Open the vSAN cluster, select Monitor, then vSAN, then Skyline Health, and clear every red item.
6. Open the NSX Manager UI, select System, then Appliances, and confirm NSX reports 4.2 or later.

Step 2, prepare the source vCenter

Enable SSH, record names, and confirm no stale VCF registration blocks the import.

1. Open vCenter appliance management page at https://your-vcenter-fqdn:5480.
2. Log in as root, select Access, and set SSH Login to Enabled.
3. Record the fully qualified domain name of the vCenter and of every ESX host.
4. Confirm forward and reverse DNS resolve for each of those names.
5. Confirm no SDDC Manager extension is registered on the vCenter by checking with your VCF administrator or the Managed Object Browser.

Step 3, open the import wizard in VCF Operations

Import runs from VCF Operations. Start the wizard against the VCF instance that will own the new domain. Set VCF Operations up first if you have not, using Part 7 on VCF Operations setup.

1. Log in to VCF Operations for your fleet.
2. On the top navigation bar, click Operate, then select Inventory in the left pane.
3. Click Detailed View, expand VCF Instances, and select your VCF instance.
4. From the Add workload domain drop down, select Import a vCenter.
5. On the General information page, enter a name for the new workload domain and click Next.

Step 4, specify the vCenter and NSX Manager

Point the wizard at the source vCenter and its NSX Manager, then accept the certificate thumbprints.

1. On the Specify a vCenter page, select the source vCenter from the inventory, or choose Specify an external vCenter and enter its FQDN in lowercase.
2. Enter the vCenter Server root password and the SSO user name and password.
3. Activate the NSX Manager toggle and enter the NSX Manager VIP FQDN with the admin, root and audit passwords.
4. If the source NSX has edge clusters, select Enable Edge cluster sync and import NSX Edge node VMs to bring the edge nodes into the fleet.
5. Click Next, confirm the vCenter and NSX Manager certificate thumbprints, then click Next again.

Step 5, run the prechecks

The wizard validates connectivity, versions, DNS, NTP and the absence of a stale SDDC Manager extension.

1. On the Prechecks page, run the prechecks.
2. Read each result and resolve every flagged item, for example a missing reverse DNS record or an NTP offset.
3. For a large estate, export the validation report to a CSV file and work through the findings.
4. Click Next once every precheck passes.

Step 6, confirm or deploy NSX

Import either binds your existing NSX Manager to the new domain or deploys a fresh cluster when the vCenter has none.

1. If the vCenter already carries NSX, the wizard binds that NSX Manager to the new workload domain, so no new appliances deploy.
2. If the vCenter has no NSX registration, enter the NSX Manager details so the wizard deploys a new cluster.
3. Choose High Availability for a three node cluster, set the appliance size, and enter the node and cluster FQDNs.
4. Run the validations, resolve any issue, and click Next.

If your source uses edge nodes, review how edges map into a fleet in Part 9 on NSX Edge clusters so the imported topology stays consistent.

Step 7, review, finish, and monitor

Finish the wizard to start the import, then follow the task to completion.

1. Review the summary and click Finish to start the import.
2. Track progress under Fleet Management, then Tasks, for the VCF instance you selected.
3. Wait for the task to report the domain imported, then let the first inventory collection finish.
4. Confirm the new workload domain appears in the Inventory tree.

Step 8, assign licenses and finish

Import registers the domain in an unlicensed state, so assign capacity before you hand it over.

1. In VCF Operations, open Administration, then Licensing.
2. Add or select a VCF 9.1 subscription with capacity for the imported cores.
3. Assign the license to the newly imported workload domain.
4. Open Operate, then Inventory, and confirm the domain shows a green status.

flowchart TD
  A[Existing vSphere with vSAN and NSX] --> B{VCF fleet already running}
  B -->|Yes| C[Import as VI workload domain]
  B -->|No| D[Converge into management domain first]
  C --> E[Assign license and validate in VCF Operations]
  D --> E

Sizing and network notes

Import that reuses an existing NSX Manager adds no new appliances. When the source vCenter has no NSX, the wizard deploys a fresh NSX Manager cluster, so size for that. The workflow uses the SDDC Manager and VCF Operations that already run in your fleet. Confirm VCF Operations and SDDC Manager reach the source vCenter on port 443 and the source NSX Manager on port 443. Keep the source vCenter and hosts on the same NTP source as the fleet so the prechecks do not fail on clock skew. Budget 30 to 90 minutes for a single cluster import, and longer for domains with many hosts, since inventory collection scales with host and object count.

Verify the import

Confirm the import finished cleanly before you hand the domain to day 2 teams. Each check below has a clear place to look and a clear expected result.

Common errors and fixes

Existing SDDC Manager extension detected

Precheck stops with a message that an SDDC Manager extension is already registered on the vCenter. Remove the stale com.vmware.vcf.sddc.manager extension from the vCenter Managed Object Browser, confirm the vCenter belongs to no other VCF instance, then rerun the precheck.

Could not generate a token from SDDC Manager

A precheck reports it cannot obtain a token. Confirm VCF Operations and SDDC Manager are reachable and that the clocks across the fleet and the source are in sync. Retry the prechecks once connectivity and time are correct.

Cluster common datastore check failed

Import halts on a vSAN partition or absent components. Open vSAN Skyline Health, resolve any partition and bring absent components back online, confirm a single common datastore per cluster, then run the import again.

SSH thumbprint validation failed

Import cannot validate the vCenter SSH thumbprint. Enable SSH on the source vCenter, then confirm the certificate thumbprints when the wizard prompts you on the thumbprint page.

Common questions

Import versus converge. Converge builds your first VCF management domain from a standalone vSphere environment. Import adds a brownfield environment to a fleet that already exists, as a VI workload domain.

Whether workloads move during import. No workload moves. Hosts, vSAN storage and running VMs stay where they are. Import registers the environment with VCF and does not move or rebuild the data plane.

Support for bare metal NSX edges. VCF 9.1 adds import support for environments that use bare metal NSX edge nodes, so those topologies no longer block onboarding.

Rollback if import fails. Your source environment stays intact throughout. If a stage fails, fix the flagged item and rerun. Import is idempotent enough to resume after a corrected precheck.

vSphere versions accepted. Source clusters must run vCenter 8.0 Update 3a or later, ESX 8.0 Update 3 or later, and NSX 4.2 or later, including the back in time builds that VCF 9.1 supports for import.

Time a single cluster import takes. Plan 30 to 90 minutes for one cluster, and more for larger domains, because inventory collection scales with host count.

Whether the source NSX Manager stays in place. Yes. Import keeps your existing NSX Manager cluster and binds it to the new workload domain rather than deploying a fresh one.

References

• VMware Cloud Foundation 9.1 documentation on Broadcom TechDocs
• Import an Existing vCenter to Create a Workload Domain, VCF 9.1 TechDocs
• How to converge a vSphere environment to VMware Cloud Foundation, VCF blog
• Existing SDDC Manager extension detected, Broadcom KB 404182
• Workload domain import cluster common datastore check, Broadcom KB 423358

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts