The VCF 9.1 Upgrade, Step by Step: What Actually Happens

In Part 1 "Before You Upgrade to VCF 9.1: What You Need to Have Ready" we covered everything you need to have in place before touching the upgrade. This post picks up at the change window; here's what actually happens at each step.

Step 1: VCF Operations, the upgrade starts here

Every VCF 9.1 upgrade begins with upgrading VCF Operations. This is not negotiable; nothing else in the sequence can proceed until VCF Operations is at 9.1.

The upgrade mechanism

The upgrade is performed via a PAK file uploaded to the VCF Operations administration interface (accessible on port 443 via the /admin path). This applies to both VCF Operations 9.0.x and Aria Operations 8.18.x source versions. For maintenance-level upgrades Broadcom discourages the PAK method in favor of other mechanisms, but for major version upgrades from 8.x or 9.0.x the PAK upgrade is the only supported path.

What happens during the upgrade

When you upgrade VCF Operations from 9.0.x, the process does more than update the software. VCF Operations connects to the Fleet Management Appliance and collects its full inventory: component inventory, service registry, user-imported certificates, certificate signing requests, content management endpoints, marketplace configuration and service accounts. After the data transfer completes, the Fleet Management Appliance is automatically decommissioned and shut down. This data is later transferred to the new Fleet Lifecycle and SDDC Lifecycle components during Step 3.

Cloud proxy behavior

Cloud proxies in the environment are upgraded automatically during the VCF Operations upgrade. Up to 10 cloud proxy instances upgrade concurrently. If there are more than 10, they proceed sequentially. Cloud proxies do not collect data while upgrading; data collection resumes after each proxy completes. Internal certificates are renewed during the upgrade; custom certificates are not affected. Each cloud proxy receives a new root-CA certificate with a five-year validity period.

Temporary capability gap

After upgrading VCF Operations to 9.1, you temporarily lose the ability to manage certificates and passwords for VCF Automation, VCF Identity Broker, VCF Operations for Logs and VCF Operations for Networks. These components are still managed by VCF Operations fleet management until they are individually upgraded to 9.1. This is expected behavior, not an error.

Step 2: SDDC Manager

After VCF Operations is at 9.1, SDDC Manager is next. When upgrading from 9.0.x, this is triggered directly from the VCF Operations UI rather than from SDDC Manager itself.

How to trigger it

In VCF Operations, navigate to Build → Lifecycle → expand VCF Instances → select the VCF Instance hosting SDDC Manager → SDDC Manager Updates tab → Available Updates → Update Now. The upgrade runs as an orchestrated workflow with progress tracking visible in the VCF Operations interface.

After the upgrade: reconfigure the depot

Once SDDC Manager is at 9.1, you must reconfigure your software depot authentication method. In SDDC Manager, navigate to Administration → Depot Settings and switch from a download token to an activation code obtained from the VCF Business Services console. The old download token method is no longer supported in 9.1.

Step 3: deploying VCF Management Services, the architecture shift

This is the step where the architecture actually changes. VCF Management Services is the new containerized management plane introduced in VCF 9.1. Deploying it replaces the functions previously provided by the Fleet Management Appliance, Aria Suite Lifecycle, VMware Identity Manager and Aria Operations for Logs management components, moving them into a Kubernetes-based runtime running on the management cluster.

What gets deployed on the first VCF Instance

The following components are deployed as part of this step on the first VCF Instance (the one hosting VCF Operations):

How to trigger the deployment

In VCF Operations, navigate to Build → Lifecycle → VCF Instances → select the first VCF Instance → SDDC Manager Updates tab → Available Upgrades tab → Next Steps section → Install Components. A wizard will prompt you for the VCF Operations FQDN, administrator credentials, the /27 CIDR block, the five FQDNs and the VCF Services Runtime admin password.

One critical detail: no capital letters

All FQDNs entered during the VCF Management Services deployment wizard must be lowercase. Capital letters anywhere in an FQDN will cause the deployment to fail. This applies to the VCF Services Runtime FQDN, the Fleet Component FQDN, the Instance Component FQDN, the Identity Broker FQDN and the License Server FQDN. Verify your DNS entries are lowercase before starting.

Do not move the VMs after deployment

After VCF Management Services VMs are deployed, do not move them to a different resource pool or folder in vCenter. Moving the VMs breaks subsequent patching, deployment and scale-out operations. They must remain in the resource pool and folder where they were originally placed.

Step 4: configure the fleet Software Depot

Before proceeding with any further component upgrades, configure the new fleet-level Software Depot that was just deployed. This replaces the depot configuration that previously lived in SDDC Manager settings. Until the Software Depot is configured, the lifecycle management system cannot download or stage binaries for subsequent upgrades. This is a mandatory gate between deploying management services and upgrading anything else.

Optional components: automation, networks, logs

After the fleet Software Depot is configured, the optional management components can be upgraded in any order. Each has its own upgrade procedure documented in the Broadcom TechDocs. These upgrades are independent of each other but each requires VCF Management Services to be deployed and operational before it can begin.

VCF Automation 9.1

The VCF Automation upgrade follows its own multi-step procedure including an import phase and an in-place upgrade. It requires its own IP planning; a /29 CIDR for VCF Automation nodes and the VCF Services Runtime /27 CIDR must already be in place. Refer to the dedicated VCF Automation 9.1 upgrade documentation for the full sequence.

VCF Operations for Networks and Log Management

These components can be upgraded independently. Until they are upgraded to 9.1, certificate and password management for them remains unavailable through VCF Operations, a temporary limitation introduced when VCF Operations was upgraded in Step 1. Upgrading them to 9.1 restores full lifecycle management capability.

Identity Broker (appliance mode)

If you have VCF Identity Broker running in appliance mode (not embedded in vCenter), upgrade it to 9.1 as part of this phase. If Identity Broker was already deployed as a 9.0.x appliance, the management services deployment in Step 3 skipped its deployment and left it for you to upgrade separately here.

License transfer after upgrading VCF Operations from 9.0.x

If you upgraded from VCF Operations 9.0.x and your VCF Operations instance is in connected mode, the license server is automatically registered, and licenses are automatically transferred to the license server. If your VCF Operations instance is in disconnected mode, there is a separate step to transfer licenses after the VCF Operations upgrade. This is documented in the Broadcom upgrade guide as a distinct post-upgrade task and should not be overlooked.

Upgrading management domain components and workload domains

With the management plane upgraded and stable, the remaining components of the management domain, including vCenter Server, NSX, ESXi hosts and vSAN, can be upgraded through the normal lifecycle management workflows now driven by VCF Operations and the new Fleet Lifecycle service.

Workload domain upgrades are fully optional and can be deferred indefinitely. There is no requirement to upgrade workload domains as part of the 9.1 upgrade. They can be upgraded at any time after the management domain of their respective VCF Instance is at 9.1.

What's different when you're done

After a successful upgrade to 9.1, your environment looks and operates differently from 9.0.x in several ways that matter day-to-day.

VCF Operations is now the lifecycle management UI

SDDC Manager is deprecated. All upgrade, patch and lifecycle operations are driven from VCF Operations going forward. SDDC Manager continues to run but its UI will be removed in a future release.

The Fleet Management Appliance is gone

It was automatically decommissioned during the VCF Operations upgrade. Fleet-level management is now handled by Fleet Lifecycle and SDDC Lifecycle running inside VCF Services Runtime.

Software Depot is now a managed service

The depot is no longer a configuration setting in SDDC Manager. It runs as a containerized service inside VCF Services Runtime and is managed through VCF Operations.

Identity Broker replaces VMware Identity Manager

If your environment previously used VMware Identity Manager (vIDM) for SSO, Identity Broker now handles that role. The transition is managed as part of the upgrade process.

Lifecycle management spans the fleet from one interface

Managing multiple VCF Instances, including upgrading secondary instances, is now orchestrated from the single VCF Operations instance on the first VCF Instance through the fleet-level services.

Activation code replaces download token for depot auth

Authentication to the software depot uses an activation code from the VCF Business Services console, not the download token used in earlier versions.

Key caveats before you start

Final thoughts

The 9.0 → 9.1 upgrade is the most architecturally significant change in the VCF 9.x lifecycle. The management plane comes out the other side leaner, more unified and purpose-built for scale, but it requires careful preparation. The pre-flight work, particularly IP planning, DNS preparation and cloud proxy verification, is where most upgrade complications originate. Get those right before your change window opens and the upgrade itself follows a well-documented, predictable sequence.

If you are planning or evaluating a VCF 9.1 upgrade, WWT has deep experience in VCF architecture, design and upgrades. We can help you assess readiness, validate pre-flight requirements and design the upgrade approach for your environment.