Updated October 2026. I wrote this back in January for the 9.0.1 to 9.0.2 upgrade. VCF 9.1 changed the order enough that following the old list will stop you partway through, so I rewrote it. This version covers getting to 9.1.x from either 9.0.x or 5.2.x. The original 9.0.2 steps are still at the bottom if you need them.
The short version: VCF Operations goes first, every time. SDDC Manager is second. Then you deploy the new VCF Management Services, configure the fleet Software Depot, and only after that do you touch NSX, vCenter and ESX. The order is enforced, so if you try to skip ahead it simply won’t let you.
Before you start
There is no rollback after Step 3. Once VCF Management Services are deployed there is no supported way to back out, and on a 9.0.x source the Fleet Management Appliance has already been decommissioned by then. Your backups are the only plan B, so treat them that way.
- Backups. SFTP file based backups configured in SDDC Manager, full VM backups, and snapshots of the critical appliances, cold where you can. Snapshot every VCF Operations node too. If the Operations upgrade fails halfway, those snapshots are how you recover.
- IP and DNS. You need a /27 for VCF Services Runtime and five FQDNs: Services Runtime, fleet component, instance component, Identity Broker and License Server. Create forward and reverse records ahead of time and keep every name lowercase. A single capital letter will fail the deployment. These names are permanent, so pick ones you can live with. If you run VCF Automation, plan a /29 for its nodes as well.
- Cloud proxy. The VCF Instance that hosts VCF Operations must have a cloud proxy. This is a hard requirement and the upgrade will not complete without it.
- Prechecks. Run the SDDC Manager prechecks and clear what they find. Check your Avi (NSX ALB) version against the target as well, because an incompatible Avi can fail the SDDC Manager step.
- Inventory sync. Same tip as before: trigger an inventory sync before you start and again any time something looks off.
- Binaries. Have everything downloaded and staged before the change window opens.
Check your source version first
Look up your exact build in the Broadcom Interoperability Matrix under VCF Upgrade Path before you plan anything. Two cases I’d call out:
- 5.2.2: upgrading to 9.0.1 or 9.0.2 can fail on an NSX back in time error (KB 430825). It’s fixed in 9.1 and Broadcom recommends going straight there. If you’re on 5.2.2 today, skip 9.0.x.
- 5.2.4.0: per KB 447234, the 9.1.0.x releases out at the time did not include SDDC Manager 5.2.4.0 in their upgrade path. Don’t try to force it. Wait for the 9.1.x release that adds the path.
Coming from 5.2.x
The workflow below is the same, but a 5.2 environment has a few things to sort out before Step 1.
- Depot. SDDC Manager 5.x still authenticates to dl.broadcom.com with a download token. If yours is still pointed at depot.vmware.com, fix that first. This post walks through the depot change script.
- VCF Operations. VCF 9 requires it. If you run Aria Operations 8.18, it gets upgraded in place to VCF Operations 9.1. Broadcom’s 5.2 to 9.1 walkthrough does this through Aria Suite Lifecycle, so follow the upgrade doc for your build. If you have no Aria Operations at all, deploy VCF Operations 9.1 first.
- Cloud proxy. Deploy one in the first VCF Instance and move the SDDC adapter over to its collector group.
- License server. Install it through the VCF Operations workflows.
- Dark sites. The Offline Bundle Transfer Utility (lcm-bundle-transfer-util) is not supported on SDDC Manager 9.x. Use the VCF Download Tool (vcf-download-tool) for the 9.1 binaries.
- Don’t jump ahead. If SDDC Manager reaches 9.1 and you try to upgrade NSX before the sequence gets there, SDDC Manager reports the NSX upgrade bundle as missing even though it’s sitting in Binary Management (KB 447995). Finish the steps in order and it shows up when it’s supposed to.
Workflow
Step 1: VCF Operations 9.1
Everything starts here, and nothing else moves until Operations is on 9.1. For a major version upgrade from 9.0.x or Aria Operations 8.18, the supported method is the PAK file uploaded through the admin interface at https://<ops-fqdn>/admin.
What to expect during this step:
- Cloud proxies upgrade on their own, up to 10 at a time. They stop collecting while they upgrade and pick back up when each one finishes.
- On a 9.0.x source, Operations copies the Fleet Management Appliance’s inventory (certificates, CSRs, service accounts, service registry and so on) and then shuts the appliance down. It doesn’t come back. That’s why the old “patch VCF Fleet” step is gone.
- Until they are upgraded to 9.1 themselves, you can’t manage certificates or passwords for VCF Automation, Identity Broker, Logs or Networks from Operations. That’s expected and not something to troubleshoot.
Step 2: SDDC Manager 9.1
From 9.0.x you start this from VCF Operations rather than SDDC Manager: Build > Lifecycle > VCF Instances > the instance hosting SDDC Manager > SDDC Manager Updates > Available Updates > Update Now.
Once it’s on 9.1, the download token stops working. In Depot Settings, switch to an activation code from the VCF Business Services console. From here on, do your lifecycle work in VCF Operations. The SDDC Manager UI is deprecated in 9.1 and is going away in a future release.
Step 3: Deploy VCF Management Services
This is the step where the architecture actually changes. VCF Management Services is the new containerized management plane, running on a Kubernetes runtime on the management cluster. It takes over the jobs that used to belong to the Fleet Management Appliance, Aria Suite Lifecycle, VMware Identity Manager and the Logs management components.
On the first VCF Instance you get VCF Services Runtime, Fleet Lifecycle, SDDC Lifecycle, the Software Depot, Salt RaaS, Salt Master, Identity Broker, License Server and Telemetry. Any instance you upgrade after that only gets Services Runtime, Salt Master and SDDC Lifecycle, because the fleet services already exist. If Identity Broker is already running as a 9.0.x appliance, this step skips it and you upgrade it in Step 5.
Go to Build > Lifecycle > VCF Instances > first instance > SDDC Manager Updates > Available Upgrades > Next Steps > Install Components. The wizard asks for the VCF Operations FQDN, admin credentials, the /27, the five FQDNs and a Services Runtime admin password.
Two rules. Keep every FQDN lowercase. And once the VMs are deployed, leave them in the folder and resource pool where they landed. Moving them breaks patching and scale out later.
Step 4: Configure the fleet Software Depot
Do this before upgrading anything else. The Software Depot you just deployed replaces the depot setting that used to live in SDDC Manager, and until it’s configured nothing can be downloaded or staged for the rest of the upgrade.
Authentication is the activation code again: generate a Software Depot ID, register it in the VCF Business Services console, and enter the code it gives you. If binary downloads fail with a 403 Forbidden, check that the code was generated against the correct Site ID (KB 441349).
For dark sites using a disconnected local depot instead of an online or offline depot, you have to upload the management component binaries into the Fleet Depot Service yourself. William Lam has a good walkthrough linked below.
Step 5: Optional management components
With the depot configured, these can go in any order:
- VCF Automation. It has its own procedure, with an import phase followed by an in place upgrade. Read the Automation 9.1 upgrade doc before starting.
- VCF Operations for Networks. You can only upgrade it through the VCF Operations fleet lifecycle workflows. Its own UI won’t do it.
- Logs. Upgrade it independently. This restores certificate and password management for it.
- Identity Broker (appliance mode only). If yours is embedded in the management vCenter SSO, there’s nothing to do here.
On licensing: if you came from VCF Operations 9.0.x in connected mode, licenses move to the new License Server automatically. In disconnected mode there’s a separate license transfer step after the Operations upgrade, so don’t miss it.
Step 6: NSX
Now the management domain. Upgrade NSX through the VCF Instance upgrade in VCF Operations.
Step 7: vCenter Server
I still use Reduced Downtime Upgrade (RDU) here. It deploys a new vCenter appliance next to the existing one and copies the configuration and data across while the source keeps running. At the end, the source shuts down, the new appliance takes over its IP and identity, and services restart. Downtime is usually under five minutes if the network, compute and storage are healthy. Run the prechecks, confirm your snapshots and watch the workflow while it runs.
Step 8: ESX hosts
Hosts come last. VCF 9 only does image based lifecycle for ESX, since baselines are gone. Build or assign the vSphere cluster image in vSphere Lifecycle Manager and import it for the upgrade. If you use a vendor custom image with OEM firmware and driver add-ons, those come along on the import, so the upgraded hosts end up with the new ESX build plus your vendor bits without extra work.
Workload domains
These are optional and can wait. Once the management domain of a VCF Instance is on 9.1, you can upgrade its workload domains whenever it suits you. Workload VMs stay up through the whole management domain upgrade.
What’s different afterwards
- VCF Operations is where lifecycle lives now. SDDC Manager still runs, but its UI is on the way out.
- The Fleet Management Appliance is gone. Fleet Lifecycle and SDDC Lifecycle inside VCF Services Runtime do its job.
- The Software Depot is a managed service, not a setting in SDDC Manager.
- Depot authentication uses an activation code instead of a download token.
- Identity Broker replaces VMware Identity Manager for SSO.
References
- KB 440630: Upgrade sequence and related issues for VCF and VVF 9.1
- KB 443647: Download token replaced by activation code in 9.1
- KB 441349: 9.1 binary downloads fail with 403 Forbidden
- KB 430825: 5.2.2 to 9.0.1/9.0.2 NSX back in time error
- KB 447234: SDDC Manager 5.2.4.0 to 9.1.x incompatible
- KB 447995: NSX upgrade bundle missing during 5.2 to 9.1
- VMware blog: VCF 5.2.x to 9.1 upgrade guide
- William Lam: Side loading binaries into the Fleet Depot Service
- William Lam: VCF Download Tool cheatsheet for 9.1
Original workflow: 9.0.1 to 9.0.2 (January 2026)
This only applies to upgrades within 9.0.x. Don’t use it for 9.1.
- VCF Fleet. Patch it to 9.0.2. Download through Binary Management in VCF Operations, or from your offline repo if disconnected.
- VCF Operations. Use Plan Upgrade to target 9.0.2 for the Operations components, then VCF Automation. Networks and Logs can follow once Operations and Automation are done.
- SDDC Manager. Upgrade from Lifecycle Management in SDDC Manager or from VCF Operations under Lifecycle > VCF Instances.
- Identity Broker. Only for an external appliance. Skip it if embedded.
- NSX. Through the VCF Instance upgrade.
- vCenter. Reduced Downtime Upgrade.
- ESX. Image based, using the cluster image imported for the upgrade.