• You can bring a vSphere 8 Update 3 environment under VCF 9.1 without upgrading it first. Broadcom calls this back in time converge and import.
• Reversing the order, meaning convert first and upgrade later, avoids gating the whole project behind pre-conversion NSX change windows.
• 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 conversion, and VCF Operations, Fleet Management and the Software Depot come up as part of it.
• Lifecycle Manager then upgrades NSX, vCenter and ESXi in order, one maintenance window at a time.
• Conversions are low risk and can run early and in parallel, which is the real schedule recovery lever.

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, and without waiting on a chain of upgrade windows first. You converge on your current 8.x versions, stand up VCF Operations early, and let Lifecycle Manager drive the upgrades on your own schedule. If you want the generic mechanics, see converging an existing vSphere environment and importing a brownfield environment. This part focuses on the sequencing decision that recovers a tight timeline.

An instinctive plan is the classic order: upgrade everything to 9.x first, then converge to VCF. That works on paper, but it often hits a version wall. If your installed NSX build is not directly compatible with the 9.1 update package, you may need two separate NSX change windows just to get NSX to a 9.1 compatible level before conversion can even begin. On a tight timeline, chaining those windows in front of the real work puts the whole effort at risk.

Reverse the sequence, convert first and upgrade later. Converge each environment while it stays on its current 8.x release, deploy VCF Operations early, and manage every NSX, vCenter and ESXi upgrade through Lifecycle Manager afterward. With Operations deployed and the environments already converted, you can work through backlog items while waiting for patch and upgrade windows, rather than sitting idle behind them.

The net effect: you adopt the VCF management plane immediately, defer the disruptive in place upgrades to scheduled LCM windows, and stop treating those upgrades as blockers to conversion.

This is a documented capability, not a workaround. VCF 9.1 supports back in time converge and import, so you can bring a vSphere 8.0 Update 3 environment under VCF 9.1 management without first upgrading it to 9.x. Two closely related mechanisms apply depending on whether a fleet already exists.

Because 8.0 U3 is a supported source for both converge and import into VCF 9.1, you never have to touch NSX or ESXi to start. Any NSX change windows move to after conversion, where LCM runs them for you.

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, confirm your vSphere, NSX and VCF Operations builds, and inventory certificates and passwords, since VCF takes these over after conversion.

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 without a prior upgrade.

The existing vCenter becomes a managed domain within a new VCF fleet, still on its 8.x versions.

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

• VCF Operations, the management and monitoring plane
• Runtime Services
• Fleet Management, which hosts fleet lifecycle, SDDC lifecycle and the software depot
• Software Depot, where upgrade bundles land for LCM
• Any other required VCF services for your entitlement

With nothing upgraded yet, the first environment is under VCF fleet management: ESX certificate and password automation, unified visibility in Operations, and a depot ready to feed LCM. Work from here is orchestrated, not manual.

Any further environment, such as a secondary site or a disaster recovery site, follows the identical pattern, each as its own phase so a hiccup at one never stalls another.

Because each environment converts on its existing versions, they have no hard dependency on one another. Independent sites can converge in parallel change windows if staffing allows, which is a real schedule recovery lever.

Your environment is now converted, but it still runs on 8.x. In this step you move each piece up to 9.1. You do not run the upgrades by hand. Lifecycle Manager, called LCM, does the work for you. For every component the job is the same three ideas: pick the component, run a precheck, then start the upgrade. LCM will not let you skip the order or start on a failed precheck, so it is hard to get this wrong.

For each component, follow the same loop:

When one component is done, repeat the same loop for the next one down the order. Here is the order with the one thing to know for each:

If your current NSX version is too old to jump straight to 9.1, LCM upgrades it in two hops: first to an in between version, then to 9.1. Each hop is its own window. You do not pick the in between version, LCM chooses it. If your NSX is new enough, it upgrades in a single step.

Most delays come from one of three causes: a missing spare IP address for vCenter, an expired certificate, or a precheck that has not been cleared. Sort these out before you start each window.

Once the first environments are converted, and ideally upgraded, 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 domains report healthy in VCF Operations, with vCenter and NSX visible to Fleet Management.
• 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 next component.
• Each upgrade window followed the LCM order and completed with a green precheck.
• After upgrade, NSX, vCenter and ESXi interoperability is green in Operations.
• Imported sites show as managed domains in the fleet.

Converting first lets you adopt the management plane before the upgrades. Once the first environment is converged, VCF Operations gives you unified health and monitoring, Fleet Management owns SDDC and fleet lifecycle, and the Software Depot feeds Lifecycle Manager. From that point every version change, whether NSX, vCenter, ESXi or Edge, is an orchestrated LCM workflow with prechecks, not a hand run upgrade. Those upgrades stop being blockers to the project and 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.
• Treat conversions as low risk and schedule them early, then save the disruptive upgrades for their own windows.
• Keep each environment conversion independent so one never blocks another.
• Back up vCenter and NSX Manager immediately before every conversion and upgrade window.
• Always follow the LCM order: Operations, then SDDC and Fleet, then NSX, then vCenter, then ESXi, then Edge.
• 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
No. vSphere 8 Update 3 is a supported source. You converge on your current version and upgrade later through LCM.

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 convert multiple environments at the same time
Yes. Independent environments convert on their own versions and have no hard dependency, so parallel windows are a valid schedule recovery move.

Why might NSX need two windows
If your starting NSX build cannot reach the 9.1 line directly, LCM takes it there in two hops, each its own window with its own precheck.