TL;DR · Key Takeaways
- Your current version decides the path. VCF 9.0.x upgrades straight to 9.1. VCF 5.2.x moves by applying the VCF Operations 9.1 PAK file first, then the core stack.
- There is no jump from VCF 4.x straight to 9.1. You reach VCF 5.2 first, then run the 9.1 upgrade on top of it.
- VCF Operations is mandatory in 9.x. If you are on Aria Operations 8.x you must be on 8.18 before the 9.1 PAK will apply, which can mean an extra hop or two.
- From vSphere Foundation or plain vSphere 8.x you pick one of three shapes, depending on whether NSX and VCF Automation are in play.
- Aria Operations for Networks has to be at 6.14 before it can move, and Log Management has no in-place upgrade, so you redeploy it and transfer the data.
- Confirm your exact hops in Broadcom KB 440630 and the Upgrade Planning Tool before you download a single bundle.
I get the same question every time a new VCF release lands: can I just go straight to it? For 9.1 the honest answer is that it depends completely on where you are starting from. The paths are more forgiving than they were in the 4.x days, but they still have hard rules you cannot talk your way around, and picking the wrong one wastes a maintenance window you probably fought to get.
This part maps every supported starting point to the road it takes: a clean 9.0.x hop, the longer route from VCF 5.2.x, the two-stage climb from 4.x, and the branching you hit if you are on vSphere Foundation or plain vSphere 8.x. I will call out the version floors that trip people up, and the one KB I open before I commit to anything. If you have not read Part 1 on what is new in 9.1, start there, because the VCF Management Services change is the reason these paths look the way they do.
Start with where you are, not where you want to be
Every supported path to 9.1 is defined by your current footprint, not by the version you want to land on. Broadcom groups these into a handful of starting points, and each one has a fixed set of hops. Get the starting point right and the rest is mostly following the sequence. Get it wrong and the 9.1 binaries will not even show up as an option in your lifecycle tooling, which is how most people discover they picked the wrong road.
Here is the short version of who goes where. Read the row that matches your environment today.
The clean path: VCF 9.0.x to 9.1
If you are already on 9.0.x, this is the path Broadcom built for. It is a direct upgrade, and most of the architectural change happens without you moving files around by hand. You still upgrade VCF Operations first, but from there the run manages the transition into the new fleet model for you.
What actually moves under the hood
On a 9.0.x fleet, lifecycle work runs through the fleet management appliance. During the 9.1 upgrade, that role moves into the new VCF Management Services cluster. Once all data from fleet management has transferred, the old appliance is decommissioned and shut down. You do not reuse its IP addresses. While the new cluster spins up, the old 9.0.x components are still online orchestrating the run, so overlapping addresses would collide mid-upgrade. Plan for a fresh block of addresses for VCF Management Services before you begin.
vCenter is the one place you get a choice on 9.0.x. Because you are moving between minor versions rather than across a major boundary, you can pick an in-place upgrade or a reduced downtime upgrade in the update workflow. Coming from 5.2, that choice is made for you and you must use the reduced downtime upgrade. ESX follows vCenter, and if any cluster still runs vSphere Lifecycle Manager baselines it has to move to a vLCM image as part of the upgrade, because baselines are gone in 9.x.
Coming from vSphere Foundation or plain vSphere 8.x
Not everyone starts from a full VCF stack. Plenty of environments are vCenter and ESX 8.x with Aria Operations 8.x, sometimes with NSX 4.x, sometimes with Aria Automation on top. For these, the path to 9.1 branches into three shapes, and which one applies to you depends on how much of the stack you actually run.
The first shape is the lean one. You upgrade VCF Operations and stop there. This is the vSphere Foundation entitlement, and it does not deploy the full VCF Management Services fleet. A useful detail people miss: the VCF License Server in this shape is a no-op for you. Its update is pushed automatically from VCF Operations as part of the PAK file, so you never patch it by hand. The second shape adds the SDDC and fleet lifecycle services plus Log Management, which exist mainly to lifecycle the log component. The third shape is the full VCF build with NSX, SDDC Manager and, if you run it, VCF Automation.
One caution that catches vSphere Foundation admins: even though the SDDC and fleet lifecycle service shows up in your deployment, it does not mean you now patch vCenter and ESX from VCF Operations. Under the vSphere Foundation entitlement you keep updating vCenter through its VAMI interface and ESX through vSphere Lifecycle Manager images inside vCenter, exactly as before. General fleet lifecycle for those components is a VCF entitlement feature, not a VVF one.
The long roads: VCF 5.2.x and 4.x
If you are on VCF 5.2.x, you can reach 9.1, but the move starts with VCF Operations. Where an existing Aria Operations 8.x is deployed, you upgrade it using the VCF Operations 9.1 PAK file. Before that PAK will apply, Aria Operations has to be on 8.18. If you are on an earlier 8.x build, that is one or more upgrades on its own before you even open the 9.1 bundle. Once VCF Operations is up, VCF Management Services is deployed, which stands up the new fleet management container, and then SDDC Manager and the core stack follow.
VCF 4.x cannot go straight to 9.1 at all. You first upgrade the environment to VCF 5.2, and only then run the 9.1 upgrade on top of it. Treat that as two projects with two change windows, not one long night. Older 5.x builds behave the same way: reach 5.2, then proceed. Within the 5.x line you can move sequentially or skip-level to 5.2.x, which shortens the first leg, but you still land on 5.2 before 9.1 is on the table.
Version floors are where these paths quietly fail. The 9.1 bundle checks the current build of each component and refuses to proceed if any of them sit below the minimum. Here are the ones I confirm before I schedule anything.
A worked example: 9.0.2 to 9.1
Take a common case: a single VCF instance on 9.0.2 with a management domain and one workload domain, NSX, and VCF Operations already in place. On paper this is the clean path, one hop. In practice the order and the waiting are what matter.
I upgrade VCF Operations first, using the 9.1 PAK through Software Update. Then I deploy VCF Management Services and let the fleet data migrate off the old appliance, which is the part that quietly eats time because it is moving state, not just booting a VM. New IP block for the cluster, not the old one. SDDC Manager next, with a precheck before the update runs. Then the domain plan: NSX management stack, vCenter with a reduced downtime upgrade on 9.0.x if I want to keep guests running, ESX hosts one cluster at a time, and finally the NSX Edge cluster to finalize the workload domain. Rough shape for a small instance is most of a day, and the longest single wait is usually the ESX rollout because each host drains, remediates and reboots in turn. If you have a big cluster, that stage alone can run into the evening.
What I would check before committing to a path
My habit is to run the Upgrade Planning Tool and cross-read Broadcom KB 440630 before I trust any path I think I know. The tool asks what you run today and returns the supported hops, including the component pre-reqs, and it covers all the shapes above despite the name suggesting it only plans. Between the tool and the KB, I catch the version floors that would otherwise surface halfway through a window.
If you want my opinion on sequencing your own project, I would split anything with Aria Automation into its own workstream. Automation carries custom code and integrations that take real time to validate, and bolting it onto the core upgrade window is how a clean run turns into a stalled one. Get the core stack to 9.1, confirm it is healthy, then bring Automation across on its own schedule.
Common questions
Can I go from VCF 4.x straight to 9.1?
No. You upgrade to VCF 5.2 first, then run the 9.1 upgrade on top of that. Plan it as two separate projects with two change windows. Trying to shortcut it is not a supported path and the tooling will not offer 9.1 until you are on 5.2.
Do I have to be on the very latest 9.0 patch before going to 9.1?
Check the release notes for your build, but the more common blocker is the VCF Operations version, which needs to be 8.18 when you come from an Aria Operations 8.x line. Confirm each component against the floors before you schedule. The 9.1 bundle will refuse to run if something sits below its minimum.
I run vSphere Foundation, not full VCF. Do I still deploy VCF Management Services?
You get a lighter shape. The SDDC and fleet lifecycle service may appear, but it is there to lifecycle the log component, not to take over vCenter and ESX patching. You keep updating vCenter through VAMI and ESX through vSphere Lifecycle Manager images, as you did before.
What happens to Aria Operations for Logs?
There is no in-place upgrade to Log Management. You deploy the new Log Management component inside VCF Management Services, then transfer your log data to it once it is up. Plan for the extra storage and the transfer time rather than expecting the old instance to convert.
Can I reuse the IP addresses from my old fleet management appliance?
No. While VCF Management Services stands up, the old 9.0.x components are still online running the upgrade, so reusing those addresses would cause a collision mid-run. Set aside a fresh block for the new cluster before you begin.
Once you know your path, the next job is prerequisites and the Planning and Preparation Workbook, which is where the complete guide heads in Part 3. For how 9.1 differs from 9.0 at a component level, the standalone 9.0 vs 9.1 writeup is worth a read, and the broader VCF 9 series and VCF 9 Operations series cover the platform you are upgrading into. If disaster recovery is part of your design, the stretched cluster versus site recovery piece pairs well with upgrade planning.
References
- Broadcom KB 440630: Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1
- VMware Cloud Foundation Blog: How to Upgrade to VMware Cloud Foundation 9.1
- William Lam: Demystifying Supported Upgrade Paths to VCF 9.1
- Broadcom TechDocs: Upgrading to VMware Cloud Foundation 9.1
About The Author
DrJha