Upgrading VCF Management Components to 9.1.1 All in One

With VCF 9.1.1 released on September 3, 2026, I wanted to bring the management-service upgrades together in one place. I already wrote a separate walkthrough for each component, but following thirteen individual posts is not how I want to plan a maintenance window. This post is the all-in-one runbook I would use for a VCF 9.1.0.x fleet.

VCF 9.1.1 is a maintenance release with an updated Bill of Materials (BOM). The official release notes say that a 9.1.0.x environment starts by patching Fleet Lifecycle. After that, the remaining components follow a small set of dependencies. The release notes also link to the VCF Upgrade Planning Tool, which is useful when the source environment is older than 9.1.0.x.

This article covers the VCF Management page in VCF Operations. It does not replace the supported upgrade path for a VCF 5.2.x or 9.0.x environment, the core SDDC upgrade order, or the migration workflow from older releases. For a fleet-managed 9.1.0.x maintenance patch, use VCF Management; Broadcom does not recommend the manual .PAK method for that case.

The Important Difference From the Older Guides

The VCF Operations page can show an Upgrade (ALL) action after the target version is selected. It is tempting to select every row and let the page run everything at once. Broadcom documents a 9.1 lifecycle issue where concurrent component runs can interfere with the plan records. A component can finish successfully but remain stuck as Ready for upgrade, with the same build on both sides of the upgrade path. That state can block later upgrades and has no customer-side database fix.

For that reason, this is an all-in-one article and execution plan, not a recommendation to launch every component concurrently. Select one component, run its prechecks, upgrade it, wait for the task to show Completed, confirm the version, and then continue. This also makes a failed task much easier to isolate.

What Gets Patched

The exact rows depend on which services are installed in each VCF instance. The build numbers below are the versions shown in my lab and are included to make the upgrade path easy to recognize. Confirm the target offered by your VCF Operations UI against the current 9.1.1 BOM.

The BOM also lists Software Depot 9.1.1.0.25713941, Cloud Proxy 9.1.1.0.25679891, and License Server 9.1.1.0.25679819. Include them in the final inventory check. Cloud Proxy and License Server lifecycle is bundled with VCF Operations in the standard lifecycle workflow. Optional services may add more rows; the table above covers the component walkthroughs already published on this blog.

Before You Begin

This runbook assumes that the VCF instance is already on 9.1.0.x and that VCF Operations can see its management components. If the environment is on 5.2.x or 9.0.x, use the supported upgrade path first. The VCF 9.1 upgrade guidance covers the larger sequence: VCF Operations, SDDC Manager, VCF Management Services, and then the core domain components.

Before opening the upgrade page:

• Check the source and target builds against the VCF Interoperability Matrix, the release notes, and the BOM. Do not force an upgrade when the target is not a supported path.
• Configure and validate the backup target required by each component under Build -> Lifecycle -> VCF Management -> Backup & Restore. For file-based VCF Management services, an external SFTP server is the recommended target, and you should verify a fresh backup before patching. Use an image-based backup for VCF Operations and Operations for Networks. Keep the encryption passphrase available for a restore. Broadcom lists Telemetry and Real-Time Metrics as N/A for backup, and the runtime file-based backup covers service accounts only. Log Management backups exclude log data, which must be archived separately. Follow the component backup-method table; do not assume every row has an on-demand component backup.
• Download all required binaries before starting. For the primary VCF instance, Broadcom’s required-binaries list includes Fleet Lifecycle, SDDC Lifecycle, VCF Services Runtime, Salt RaaS, Salt Master, Identity Broker, Software Depot, Telemetry, and License Server. Use the VCF Download Tool and binary-management documentation for disconnected environments.
• Check VCF Operations, the VCF services runtime, and every hosted component for healthy nodes, disk, CPU, memory, DNS, certificates, and credentials. A full management-services node or volume can prevent staging; review the node-capacity guidance and volume-capacity guidance if alerts are present.
• If you use custom VCF Automation profiles, review the cleanup procedure in KB 451147 before upgrading. Custom profiles from earlier 9.x releases can make the Automation upgrade fail.
• Record the integrations and user-facing checks you will run afterward. Identity Broker affects SSO, Log Management affects ingestion, Operations for Networks affects network visibility, and Automation affects portals and deployments.
• Plan a maintenance window. Do not start another lifecycle operation while the current component task is running.

The Dependency Order

The release notes give the mandatory boundaries. I would handle Operations and Software Depot early to get their isolated operations out of the way, then continue through the remaining services:

1. Fleet Lifecycle must be patched first.
2. VCF Operations must be handled by itself. Do not run another lifecycle operation while the Operations patch is in progress, and wait for it to complete before continuing.
3. Software Depot must be handled by itself when it is being patched. Other component patches are blocked while its binaries are unavailable.
4. Patch VCF Services Runtime before Identity Broker or Salt RaaS on the same VCF instance.
5. Patch VCF Automation before the Migration Service Engine, if that optional component is installed.
6. Patch the remaining installed components one at a time, waiting for Completed and validating each version before moving on. This sequential execution follows the current KB 453246 recommendation; it does not add a mandatory dependency between otherwise independent components.

The list is a safe execution order for this runbook. The release notes remain the authority if your inventory contains a component or dependency that is not listed here.

Upgrading Fleet Lifecycle First

Log in to VCF Operations with an Administrator account and go to Build -> Lifecycle -> VCF Management -> Upgrade.

Fleet Lifecycle has its own card and target selection. Use … -> Select version on that card, select 9.1.1.0.25713934, and click Set Target Version. Click Check Binary Availability, resolve any missing binary, and then click Upgrade. Follow Upgrade details until the task is complete and the card shows Current version: 9.1.1.0.25713934.

The Fleet Lifecycle walkthrough has the full screen sequence. Complete this operation before patching any other component.

Selecting the Management-Component Target

Once Fleet Lifecycle is complete, return to VCF Management -> Upgrade. If the management-component target still shows 9.1.0.*, click Select Version (called Change target version in the current documentation), choose 9.1.1.*, and click Set Version. Use Customize if you need to review or select a specific component target. If 9.1.1 is missing, click Sync, wait for the metadata task to finish, and check again. Changing the target only changes the available upgrade paths; it does not start an upgrade.

This target applies across the VCF instances in the fleet, so review the instance name on every row before selecting it. Expand Check Required Binaries and resolve every missing binary before selecting a component.

Running Each Component Upgrade

For each remaining component, follow the individual-component upgrade procedure and the dependency boundaries above:

1. Clear any previous selection and select exactly one component row.
2. Confirm the source and target builds are the ones you expect. The buttons should show Run Prechecks (1) and Upgrade (1).
3. Click Run Prechecks (1) and open Precheck details. Review every check, including package staging, platform connectivity, database checks, and the backup requirement.
4. Fix any failed check and run the precheck again. Start the upgrade only when the row reports Ready for upgrade.
5. Click Upgrade (1) on that row and open Upgrade details. For the runtime-hosted services, the task details show staging, component checks, preparation, upgrade, and inventory synchronization. The exact subtask names vary by component.
6. Wait for the overall task to report Completed, including the final inventory sync where it is shown. If a subtask fails, open its details, correct the reported issue, and retry it before proceeding.
7. Go to Build -> Lifecycle -> VCF Management -> Components, open the component, and confirm Status: Running and the expected 9.1.1 build.
8. Check the component’s service health and the VCF Management -> Tasks page before starting the next row.

Repeat these steps for every installed component. The individual walkthroughs in the table show the corresponding screen sequence and lab captures for each service.

Post-Upgrade Validation

Once all selected components report 9.1.1:

• Check Build -> Lifecycle -> VCF Management -> Components for a consistent inventory and no component still showing an old target.
• Review Build -> Lifecycle -> Tasks for failed, partial, or stale tasks. If a component is already on the target but remains stuck as Ready for upgrade, do not edit the lifecycle database; open Broadcom Support and reference KB 453246.
• Test SSO through Identity Broker, VCF Operations logins and dashboards, Log Management ingestion, Operations for Networks collection, Automation portals and a representative deployment, Salt health, Telemetry behavior, and the services-runtime health dashboard.
• If VCF Operations was upgraded, check the precheck result for affected Management Packs. KB 454432 lists packs that need a 9.1.1-compatible update, and KB 454434 covers custom packs built with an older MP Builder.
• Confirm that a new management-services backup completes and that the backup artifacts are retained according to your policy.
• If the VCF Operations Build -> Lifecycle page is blank or spins after an appliance update, test an incognito window or clear the browser cache. Broadcom tracks that behavior in KB 441205.

And with that, we have one repeatable plan for the VCF Management 9.1.1 maintenance window. The UI still gives us a single place to see every component, every precheck, and every task, while the execution stays within the current Broadcom guidance for 9.1.1.