Dr. Pranay Jha

VMware Cloud Foundation (VCF) 9.1 is not a “click update and hope” release. If you are running VCF 9.0.x and planning the move to 9.1, the upgrade has to be treated as a controlled, full-stack sequence across VCF Operations, SDDC Manager, NSX, vCenter, and ESX hosts — plus any adjacent components such as Avi Load Balancer, VMware Live Recovery / Site Recovery Manager (SRM), and vSphere Replication. This guide walks through the order, the prerequisites, and the gotchas so your upgrade window stays boring — which is exactly how a platform upgrade should be.

What’s Different in VCF 9.1

The single biggest architectural change to be aware of is the introduction of the unified VCF Management Services cluster. In 9.1 this new service layer replaces the standalone VCF 9.0 Fleet Management Appliance and the VMware Identity Broker (vIDB), and becomes the central “universal remote” for lifecycle, licensing, and operational capabilities. VCF Operations becomes the control point for lifecycle operations in the 9.x model, so much of the upgrade is now driven from the VCF Operations interface rather than directly from SDDC Manager.

Because of this, you cannot skip deploying Management Services, and you cannot reuse your existing 9.0.x IP addresses for it. While the new cluster is deployed, your old 9.0.x components are still online orchestrating the upgrade, so reusing IPs would cause network collisions mid-upgrade.

The Upgrade Sequence at a Glance

Upgrading to 9.1 requires a strict component upgrade sequence. Upgrading your workload (VI) domains is not mandatory as part of this and can be done later as a Day-N task. The high-level flow is:

1. Validate prerequisites and compatibility against the target BOM.
2. Upgrade VCF Operations from 9.0.x to 9.1.
3. Configure the online depot in VCF Operations.
4. Download the required VCF 9.1 binaries.
5. Deploy the new VCF Management Services cluster.
6. Validate / upgrade VMware Live Recovery (SRM) and vSphere Replication where applicable.
7. Upgrade Avi Load Balancer (if present) before SDDC Manager.
8. Upgrade SDDC Manager to 9.1.
9. Plan the management domain upgrade.
10. Run upgrade prechecks.
11. Upgrade NSX.
12. Upgrade vCenter.
13. Import / assign the ESX image.
14. Upgrade ESX hosts.
15. Verify versions, logs, and health, then remove temporary safety controls.

The order matters because the platform has dependencies between lifecycle management, operations, SDDC Manager, NSX, vCenter, and ESX. VCF Operations must take ownership of the fleet inventory before it can orchestrate the rest of the stack. Get the sequence wrong and the platform will happily teach you why the sequence exists.

Pre-Upgrade Checklist

This is the boring part, which means it is also the part that saves your weekend.

1. Confirm the Bill of Materials

Start with the target VCF 9.1 BOM and confirm every component version against the official interoperability matrix. Pay particular attention to components that sit slightly outside the normal SDDC Manager lifecycle path — load balancers, recovery appliances, and replication components are the easy ones to forget.

2. Back up SDDC Manager and core components

Confirm a recent, successful SDDC Manager backup stored on an external SFTP server, and make sure recent backups exist for the other managed components.

3. Take supported snapshots

Snapshots before the upgrade are especially important for vCenter, because the vCenter upgrade flow uses a temporary network configuration during the process. Remove snapshots after the upgrade is validated — leftover infrastructure snapshots cause storage waste and performance problems.

4. Prepare temporary network details for vCenter

The vCenter upgrade needs a temporary network configuration. Have the following documented and validated before the change window: a free temporary IP from the same subnet, subnet mask / prefix, default gateway, and any required DNS details.

5. Allocate a new CIDR block for VCF Management Services

This is the prerequisite people miss. The new Management Services cluster requires a minimum of 12 free IP addresses on your management VLAN. Because the upgrade wizard requires an IP pool in CIDR format (not a range), you must provide at least a /28 subnet (14 usable IPs); a /27 (30 usable) is recommended if you have room for future scale-out. Create the forward and reverse DNS records (FQDNs) for the new services beforehand — do not wait for the wizard to prompt you before calling your network team.

Step 1: Upgrade VCF Operations to 9.1

The first major step is upgrading VCF Operations, done by uploading the VCF Operations 9.1 upgrade PAK file to the administrator interface:

1. Download the VCF Operations 9.1 upgrade PAK file from the Broadcom Support Portal.
2. Log in to the primary VCF Operations node administrator interface.
3. Open Software Update and click Install a Software Update.
4. Upload the PAK file and accept the EULA / release information.
5. Start the installation and monitor it from the Software Update page.

Expect the administrator interface to restart and log you out — that is normal. When the Fleet Management migration dialog appears, provide the root password for the previous fleet management appliance and allow the migration to complete. Once the cluster upgrade finishes, the associated cloud proxy is upgraded and the old fleet management appliance is decommissioned. Wait until all nodes and the cluster show an online status before moving on.

Step 2: Configure the Online Depot

After VCF Operations is upgraded, configure the online depot so it can download the required upgrade bundles. In VCF Operations, go to Build > Depot Settings, click Configure for the online depot, enter the activation code from the business services console, and verify the connection is active. If the depot is not active, binary download and lifecycle management become your next problem.

Step 3: Download the Required Binaries

With the depot active, go to Build > Lifecycle, select the relevant VCF instance, open Binary Management, select the required upgrade bundles, and click Download. Do this before the maintenance window — waiting on large binary downloads while the change clock ticks is a poor use of everyone’s time.

Step 4: Deploy VCF Management Services

This is where the /28 or /27 CIDR block and DNS records from your checklist come into play. SDDC Manager will not allow you to proceed until this new service layer is up and owns the inventory.

1. Log in to VCF Operations and navigate to Build > Lifecycle.
2. Find the banner / task prompting you to Deploy Management Services and click Deploy to launch the wizard.
3. Enter your network details: the new CIDR block (e.g. 10.0.0.32/27), gateway, and VLAN.
4. Map the provided FQDNs (e.g. vcf-service-runtime, vcf-fleet-lifecycle, license server) to IPs within the new CIDR block.
5. Run the Management Services Precheck. Do not deploy if it shows DNS or network reachability errors.
6. Click Deploy and monitor the task until it reports Successful.

The system spins up the new nodes on the fresh IP block and, once healthy, transfers lifecycle control to them. Only after this task succeeds can you safely move on.

Step 5: Handle SRM, vSphere Replication, and Avi

If VMware Live Recovery / SRM or vSphere Replication is present, validate the supported upgrade path and confirm appliance health, protection groups, recovery plans, pairings, and replications are healthy before the core platform upgrade.

If Avi Load Balancer is deployed, upgrade it before the SDDC Manager sequence: confirm the current Avi Controller version, validate the target against VCF 9.1 compatibility, run Avi prechecks, confirm controller cluster / service engine / virtual service health, and take backups per the supported Avi procedure. Load-balancer health issues are exactly the kind of thing that turn a clean upgrade into an incident bridge.

Step 6: Upgrade SDDC Manager to 9.1

Once VCF Operations is upgraded, the depot is configured, binaries are downloaded, Management Services are running, and SRM/Avi are validated, upgrade SDDC Manager from VCF Operations:

1. Log in to VCF Operations and go to Build > Lifecycle.
2. Select the correct VCF instance and open the SDDC Manager Updates tab.
3. Download the SDDC Manager 9.1 update.
4. When the download completes, click Update Now.

Do not proceed if prechecks are red. “It is probably fine” is not a rollback plan.

Step 7: Plan the Management Domain Upgrade

In VCF Operations, go to Build > Lifecycle, select the management domain, open the Upgrades tab, and click Plan Domain Upgrade. Select the VCF target version (and custom target versions if required), choose the upgrade scenario for vCenter and NSX Manager, then review and submit. At this stage you also decide between an optimized or sequential approach, depending on environment size, maintenance window, and risk tolerance.

Step 8: Run Upgrade Prechecks

Run prechecks before touching NSX, vCenter, or ESX. Validate cluster health, host connectivity, vSAN health (where applicable), NSX manager / edge health, vCenter service health, certificate validity, DNS / NTP consistency, backup status, available capacity, and lifecycle bundle readiness. Resolve failures before continuing, and review warnings too — some “warnings” are really future outages wearing polite clothing.

Step 9: Upgrade NSX

From VCF Operations, go to Build > Lifecycle, expand the VCF instance, select the domain, open Upgrades, and click Upgrade Now for NSX. Monitor with View Status, and verify directly in the NSX Manager UI as well. Be strict with health checks before and after — management plane, control plane, transport nodes, edges, and routing should all be validated.

Step 10: Upgrade vCenter

The vCenter upgrade requires the temporary network configuration you prepared earlier (temporary IP, subnet, gateway) and a vCenter snapshot. From VCF Operations Build > Lifecycle, select the VCF instance and click Configure for vCenter:

1. Review the upgrade mechanism and select the backup option.
2. Configure the temporary network settings and review them.
3. Schedule the upgrade (immediate execution if it matches your window).
4. Choose automatic switchover if that is the approved approach.
5. Monitor progress with View Status.

After completion, verify the vCenter version from both the VCF lifecycle view and the vCenter UI — do not rely on a single screen.

Step 11: Import the ESX Image and Upgrade Hosts

First import the ESX image: in VCF Operations Build > Lifecycle, select the VCF instance, click Image Management, choose the import method, provide the image information, and click Import. Make sure the image is available before scheduling host upgrades.

Then configure the ESX upgrade: for VMware ESX 9.1 click Configure, select the clusters or individual hosts, assign the imported image, choose upgrade options, review, click Finish, then Upgrade Now. In production, prefer a controlled, batched rollout rather than upgrading every cluster at once. During host upgrades, watch cluster health, DRS activity, maintenance-mode transitions, workload evacuation, and any vSAN resync activity.

Post-Upgrade Validation

The platform may be upgraded, but the job is not done until you have proven it is healthy. Validate VCF Operations cluster status, SDDC Manager health, the VCF lifecycle view showing expected versions, NSX manager / transport node / edge status, vCenter service health, ESX host versions, cluster compliance, vSAN health, post-upgrade backup jobs, cloud proxy health, and recovery component health if SRM / replication is deployed. Only after validation should you remove temporary snapshots and take fresh backups of the newly upgraded components.

Lessons Worth Repeating

• Don’t start without clean prechecks. If the platform tells you something is wrong, believe it and fix it first.
• Don’t ignore supporting components. Avi, SRM, vSphere Replication, cloud proxies, and depot connectivity all influence the experience.
• Download binaries early so they are not part of the risky section of the change window.
• Have the new CIDR block, DNS records, and temporary vCenter network details ready before you click Schedule.
• Validate from multiple places. Don’t trust one green checkmark — confirm from VCF Operations, SDDC Manager, vCenter, NSX Manager, and the host level.

Final Thoughts

Upgrading from VCF 9.0 to 9.1 is a manageable process, but it is still a full-stack platform upgrade. Respect the order: upgrade VCF Operations first, configure the depot, download binaries, deploy VCF Management Services, handle dependency components, upgrade SDDC Manager, plan the domain upgrade, run prechecks, then move through NSX, vCenter, and ESX in a controlled sequence. Skip the boring preparation work and the platform will remind you why it exists.

References

• Broadcom TechDocs — Upgrading to VMware Cloud Foundation 9.1
• Broadcom TechDocs — Upgrade Sequence to 9.1 (Release Notes)
• Broadcom TechDocs — Deploy VCF Management Services as Part of VCF Upgrade to 9.1

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts