• Converting a vSphere 8 estate into VCF 9.1 reuses the vCenter and hosts you already run, with no rebuild.
• Upgrade the vSphere components, vCenter and ESXi, to 9.1 first, then converge. NSX 4.2 or later converges on its current version and upgrades to 9.1 after convergence.
• Converge builds a new VCF fleet around an existing environment. Import attaches an environment to a fleet that already exists.
• The VCF Installer runs the converge, and VCF Operations, the VCF management services and the software depot come up as part of it.
• After convergence, VCF Operations drives the NSX and Edge upgrades from Build then Lifecycle, one precheck and one maintenance window at a time.
• Back up vCenter and NSX Manager before each vSphere upgrade and before the converge window.

Most of this series stands up VCF 9.1 greenfield. This part covers the opposite case, taking an existing vSphere 8 estate and converging it into VCF 9.1 without a rebuild. You upgrade the vSphere components to 9.1, let the VCF Installer converge them into a new fleet, then finish the NSX upgrade under VCF Operations. If you want the generic mechanics, see converging an existing vSphere environment and importing a brownfield environment. This part walks the end to end convert path for a vSphere 8 source.

Converging an existing environment into VCF 9.1 is not a single click on your current builds. Broadcom documents the converge process as manual upgrades of your existing components to 9.1, followed by the VCF Installer workflow that builds the fleet around them. In practice you move vCenter and the ESXi hosts to 9.1 before the converge, then reuse them as the management domain of the new fleet.

NSX is the exception. An NSX 4.2 or later deployment that is registered with a vCenter without Enhanced Linked Mode converges on its current version, and you upgrade it to 9.1 after the convergence completes. So the order is vSphere to 9.1, then converge, then NSX to 9.1, with the NSX Edge cluster last.

The net effect, you reuse existing hardware and vCenter instead of rebuilding, you adopt the VCF management plane as part of the converge, and you keep each disruptive step in its own maintenance window.

This is a documented capability, not a workaround. VCF 9.1 supports converging or importing an existing vSphere 8 environment into VCF 9.1. Two closely related mechanisms apply depending on whether a fleet already exists.

Because NSX 4.2 or later converges on its current version, you sequence the NSX upgrade after the fleet exists, where VCF Operations runs it for you. The vSphere upgrade to 9.1 stays in front of the converge, so plan those windows first.

Run the VCF Installer validation pass as a dry run days ahead of the window. It checks hardware, networking, switch versions and default setting alignment. Clear the recurring blockers first, remove Enhanced Linked Mode, remediate the distributed switch configuration, and confirm your vSphere and NSX builds against the interoperability matrix. Move each cluster from vSphere Lifecycle Manager baselines to images, since baselines are not supported in 9.x, and inventory certificates and passwords, since VCF takes these over after conversion.

Bring the existing vSphere platform to 9.1 before the converge. This is the version floor for the components the VCF Installer reuses. NSX stays where it is for now.

The installer is the engine that runs the convergence, and it is needed because no VCF instance exists yet. For a full walkthrough of this appliance, see how to deploy the VCF Installer appliance.

This is the same converge mechanism covered in Part 20, run here on a vSphere 8 estate that you have just moved to 9.1.

The existing vCenter becomes the management domain of a new VCF fleet, with NSX still on its 4.2 or later build.

As part of the conversion, the management components come up:

• VCF Operations, the management and monitoring plane
• VCF management services, the container cluster that hosts Fleet lifecycle, SDDC lifecycle and the software depot
• SDDC Manager, for domain level operations
• Software depot, where upgrade bundles land for the fleet lifecycle service
• The license server and any other required VCF services for your entitlement

With vSphere already on 9.1, the converged environment is under VCF fleet management: ESX certificate and password automation, unified visibility in VCF Operations, and a depot ready for the NSX upgrade. Work from here is orchestrated, not manual.

vCenter and ESXi are already on 9.1, so the remaining work is NSX and its Edge cluster. You do not run these by hand. VCF Operations drives them from the Fleet lifecycle service, with a precheck in front of each. It will not let you start on a failed precheck, so it is hard to get this wrong.

For each part, follow the same loop:

In VCF 9.x the NSX host components ship inside ESX, so NSX upgrades in two parts. You upgrade the NSX manager stack first, then upgrade the NSX Edge cluster last, after the rest of the domain is on 9.1. Each part is its own window with its own precheck.

Most delays come from one of three causes: an expired certificate, a precheck that has not been cleared, or an NSX Edge that is undersized for 9.1. Sort these out before you start the window.

Once the first environments are converted, any remaining or smaller remote sites join by import rather than a standalone conversion. The fleet already exists, so there is no reason to stand up new fleet services at each site. The mechanics match Part 21 on importing a brownfield environment.

• Converted domain reports healthy in VCF Operations, with vCenter and NSX visible to Fleet Management.
• vCenter and ESXi are on 9.1, confirmed in VCF Operations.
• Certificate and password management has moved to VCF, which you can spot check on an ESX host.
• Software depot is populated and reachable, and prechecks pass for the NSX upgrade.
• The NSX upgrade followed the manager then Edge order and completed with a green precheck.
• After upgrade, vCenter, ESXi and NSX interoperability is green in VCF Operations.
• Imported sites show as managed domains in the fleet.

Converting reuses your existing vCenter and hosts instead of rebuilding. Once the environment is converged, VCF Operations gives you unified health and monitoring, the VCF management services own Fleet lifecycle and SDDC lifecycle, and the software depot feeds those services. From that point every version change, whether NSX, vCenter, ESXi or Edge, is an orchestrated workflow with prechecks, not a hand run upgrade. Those upgrades become routine day 2 operations.

• Run the installer validation as a dry run well ahead of the window, and remediate ELM and switch issues calmly, not under a clock.
• Upgrade vCenter and ESXi to 9.1 before the converge, and keep each in its own maintenance window.
• Reuse NSX 4.2 or later on its current version, and upgrade it to 9.1 after the fleet exists.
• Move clusters from vSphere Lifecycle Manager baselines to images, since baselines are not supported in 9.x.
• Back up vCenter and NSX Manager immediately before every upgrade and before the converge.
• Validate exact source builds against the Broadcom interoperability matrix, since supported versions shift per 9.1 patch.

Do I have to upgrade vSphere before converting to VCF 9.1
Yes. For the converge path you upgrade vCenter and ESXi to 9.1 first, then the VCF Installer converges them into a new fleet. NSX 4.2 or later is the exception, it converges on its current version and upgrades afterward.

What is the difference between converge and import
Converge builds a new VCF fleet around an existing environment. Import attaches an environment to a fleet that already exists.

Can I keep NSX on its current version
Yes. An NSX 4.2 or later deployment without Enhanced Linked Mode converges as is, then upgrades to 9.1 after the fleet exists.

Why is NSX a two part upgrade
In VCF 9.x the NSX host components ship inside ESX, so you upgrade the NSX manager stack first and the NSX Edge cluster last, each its own window with its own precheck.