VMware Docs
v1.8.0
Search v1.8.0 Feedback Blog GitHub

Reference

Converge and Import: bringing existing infrastructure under VCF

Two distinct Broadcom mechanisms get lumped together in conversation but are procedurally different, driven by different tools, and solve different problems. Confirm which one actually applies before planning around either:

ConvergeImport
Driven byVCF InstallerVCF Operations (after the management domain already exists)
Starting pointExisting standalone vSphere infra, no VCF at all yetAn existing vCenter (with or without NSX), brought into an already-running VCF fleet
ResultA new VCF or VVF instance/fleet, built from that infrastructureA new workload domain added to that fleet
Applies toVCF or VVF (Broadcom’s own doc title: “Converging Existing Virtual Infrastructure to a VCF or a vSphere Foundation Platform”)VCF only – needs VCF Management Services / SDDC Manager to import into, which doesn’t exist on standalone VVF

If there’s no VCF fleet yet and the goal is to build one from existing kit, that’s Converge. If a fleet already exists and the goal is to add an existing vCenter to it as another workload domain, that’s Import.

Version interop quick-reference

Treat this as a starting point, not the final answer – re-run the Broadcom Product Interoperability Matrix (Upgrade Path tool) for the exact source build before committing, the same discipline confirming a supported upgrade path already demands elsewhere in this repo. Patch-level KBs supersede generic minimums constantly – see the back-in-time restriction row below for exactly why.

Target VCF buildMechanismMin vCenterMin ESXNSXKnown gate
9.0.0Converge9.0+9.0+n/a (fresh)–
9.0.1 / 9.0.2Converge8.0 U3+ only if existing NSX registration at 4.2.1+; otherwise 9.0+8.0 U1+ under the same condition; otherwise 9.0+4.2.1+ if reusing an existing registration–
9.0.x (any)Import8.0 U3a+8.0 U3+4.2.1+ optional–
9.1.0.xImport or Converge8.0 U3a+8.0 U3+4.2.1+ optionalBlocked if vCenter is 8.0 U3j+ and NSX is 4.2.4+ – back-in-time restriction, KB 448135
9.1.1.0+Import or Converge8.0 U3a+8.0 U3+4.2.1+ optionalBack-in-time restriction above resolved – KB 448135’s updated BOM reopens the path
Deploying/joining NSX 9.1 specifically during importImportMust already be on vCenter 9.1–NSX 9.1 does not support vCenter 8.0 U3a+Upgrade vCenter to 9.1 first, before the import wizard’s NSX step

No existing NSX registration doesn’t dodge the 9.1.0.x row above – it can walk straight into it. When NSX isn’t already present, VCF auto-selects and deploys the latest NSX build compatible with the source vCenter, without checking that selection against the target VCF build’s chronological baseline – see The shared trap below for the mechanism and how to avoid it.

Converge: existing vSphere becomes a new VCF or VVF platform

Per Broadcom’s Converging Existing Virtual Infrastructure to a VCF or a vSphere Foundation Platform: “You can use your existing virtual infrastructure as building blocks for your VCF or vSphere Foundation platforms.” Three phases: manual upgrade of existing components to a qualifying 9.x-era build first, infrastructure preparation, then automated deployment via VCF Installer – “By using the VCF Installer workflows, you can converge the components to a new VCF Fleet or a new VCF Instance in an existing VCF fleet.”

Version bar before VCF Installer’s converge workflow will run against an existing vCenter (per Operations modernization):

  • vCenter 9.0+ to converge directly to VCF 9.0.0.
  • vCenter 8.0 U3+ is acceptable for converging to 9.0.1/9.0.2 only if it already has an existing NSX registration at 4.2.1+ – otherwise the vCenter needs upgrading first.
  • ESX carries an equivalent gate: 9.0+ for a 9.0.0 target; 8.0 U1+ acceptable for 9.0.1/9.0.2 scenarios.

VCF Installer does not upgrade vCenter for you as part of convergence – the manual upgrade happens first, then Installer orchestrates NSX / SDDC Manager / workload-domain creation once the vCenter already qualifies. See Broadcom’s Supported and Not Supported Configurations to Converge and Supported Components and Scenarios to Converge for the full scenario matrix before committing to a converge plan.

Import: an existing vCenter becomes a new workload domain (VCF only)

Per Broadcom’s Import an Existing vCenter to Create a Workload Domain – driven from VCF Operations: Operate → Overview → Inventory → Detailed View → VCF Instances → “Add workload domain” dropdown → “Import a vCenter.”

Minimum versions

ComponentMinimum
VCF instance9.0+
vCenter8.0 Update 3a+
ESX8.0 Update 3+
NSX Manager (optional – see below)4.2.1+

NSX 9.1 specific warning, quoted verbatim: “NSX 9.1 does not support vCenter 8.0 Update 3a or later. If your vCenter instance is without an existing NSX registration and you plan to use a shared NSX 9.1 instance or deploy a 9.1 NSX instance during the import procedure, first upgrade your vCenter instance to version 9.1.”

Prerequisites checklist

Official checklist items, quoted verbatim where noted:

  • “Verify that SSH is enabled on the existing vCenter instance.”
  • “Verify that all ESX hosts use FQDNs instead of short names in your vSphere inventory.”
  • “Verify that SDDC Manager has access to all NSX Manager nodes on port 443.”
  • “Verify that your NSX certificate contains the FQDNs of all NSX nodes and the NSX cluster VIP in the SAN field.”
  • If there’s no existing NSX registration, have the matching NSX install bundle available for the vCenter’s version.
  • If joining an existing shared NSX instance, its version must be “the same or later than the version of the management domain” (if no other workload domains share it yet) or “the same or later than the version of all domains that share the instance.”

Field-observed additional blockers (from a practitioner’s worked vCenter 8.x import, not all spelled out in the official checklist above):

  • DRS must be Fully Automated – “Partially automated or manual DRS is not supported for import.”
  • vSphere Distributed Switch (VDS) 8.0+ with at least 2 uplinks – standard switches alone aren’t supported; migrate off VSS first if still in use (see VSS to VDS migration for the general procedure, written for the VVF-extending-to-VCF case but the same mechanics).
  • Enhanced Linked Mode must be deactivated before import – not negotiable.
  • Static IPs on every VMkernel interface, except NSX Host TEPs (DHCP is fine there).

The import wizard, and its one hard constraint

  1. General Information – name the workload domain.
  2. Specify vCenter – select the existing vCenter (and NSX Manager, if already registered), supply credentials.
  3. Confirm certificate thumbprints (vCenter, NSX Manager, other components).
  4. If there’s no existing NSX registration: choose deploy-new or join-existing-shared-instance, specify appliance/cluster FQDNs.
  5. Prechecks – resolve anything flagged; export a CSV report for large environments if needed.
  6. Review & Finish.

“All vSphere clusters in the existing vCenter are imported as part of this process. You cannot select a subset of the clusters.” Plan the workload domain boundary around the whole vCenter, not a subset of its clusters.

Field-observed gotchas:

  • NSX binaries not found during validation – per the same practitioner account, the fix is checking Fleet Management → VCF 5.2 (not the 9.0/9.1 section) for the matching NSX patch binaries and downloading them before re-running validation – an easy place to look in the wrong section.
  • ESXi root passwords don’t always populate in the VCF credential store post-import – per Broadcom KB 388859.

The shared trap: auto-selected NSX version can be chronologically incompatible

This affects both Converge and Import whenever NSX isn’t already present or registered – when the workflow has to deploy NSX itself, per VCF 9.1 - Understanding VCF Converge & Import Scenarios for vCenter Server Without NSX, VCF automatically deploys “the latest NSX version that is compatible with the source vCenter Server version” – compatible with the vCenter, but not cross-checked against the target VCF release’s chronological BOM baseline. Confirmed as the actual root cause behind this repo’s own field notes case, not just a version-number coincidence: the article’s example is the identical combination – vCenter 8.0 Update 3c defaults to NSX 4.2.4.1 – compatible with that vCenter build, but unable to upgrade further to reach VCF 9.1.0’s NSX baseline. Same mechanism as the back-in-time restriction already documented for the vCenter side (KB 448135) – this is the NSX side of the same trap, triggered automatically during Converge/Import rather than during a later manual upgrade choice.

Confirmed fleet-wide blast radius, not scoped to the affected domain: see Field notes: NSX and vCenter and Full VCF upgrade sequence, Phase 2 for a case where an imported workload domain’s auto-selected NSX 4.2.4.1 blocked a management-domain-only Plan Component Upgrade, even though that upgrade never touched the imported domain – SDDC Manager validates the target version against the whole fleet’s component inventory before saving any domain’s plan.

Three ways to avoid or recover from it:

  1. Pre-deploy NSX manually first, then register the vCenter as a Compute Manager within NSX before converging/importing – the workflow detects and uses the existing deployment instead of auto-selecting one.
  2. Override the auto-selected version per Broadcom KB 429205, “Overriding version of NSX Manager while converging or importing an existing vCenter instance with new NSX Manager deployment” – specify the desired NSX version via Domain Manager / Operations Manager property files instead of accepting the latest vCenter-compatible one.
  3. Undo and redeploy per Broadcom KB 430524, “Upgrading a Brownfield-imported domain fails during the upgrade pre-check phase due to an unsupported upgrade path for NSX” – applies to workload domains only, not the management domain.

Older NSX releases (4.1.x) may need a two-hop upgrade to reach VCF 9.1.0 even after correcting the version-selection issue. This same chronological pattern isn’t unique to the 9.1 line either – Broadcom KB 430825 documents an equivalent NSX 4.2.3.3 back-in-time block on a VCF 5.2.2 → 9.0.1/9.0.2 upgrade, so treat “check the exact source build against the exact target build” as a standing rule for any Converge/Import/upgrade combination, not a 9.1-specific quirk.

Sources

ITQ – What's Next. VCF upgrade-planning material. © 2026 ITQ. hollebollevsan.nl