Dr. Pranay Jha

Most VCF 9 upgrade failures I see are not bugs. They are assumptions. Teams plan the upgrade as a bigger version of the 5.1 to 5.2 patch they did last year, then hit a wall the precheck never warned them about until the maintenance window was half gone. The jump to 9.0 is mostly streamlined, but it quietly changes how the platform is managed, and a few components do not upgrade at all. They get redeployed. If you do not plan for that up front, you find out the hard way at 2am.

This is the failure list. Seven things that bite real migrations from older VCF to 9, each with the symptom you will actually see, the reason it happens, and what to do about it.

1. You cannot jump from 4.x, and 5.2.x is the real floor

Symptom: You point an old VCF 4.5 or early 5.x instance at the 9.0 path and the planner refuses it, or the management domain ESX upgrade step rejects your build.

Likely cause: The supported upgrade path to 9.0 starts from VCF 5.x, and the management domain upgrade procedure is written against 5.2.1 specifically. Anything older has to climb to 5.2.x first. A 4.x estate is two migrations, not one: 4.x to 5.2.x, then 5.2.x to 9.0.

Fix: Treat reaching 5.2.x as its own project with its own change window. Upgrade the management domain and every workload domain to 5.2.x, then start the 9.0 work. Do not under-scope the interim hop. The skip-level patching in SDDC Manager helps, but each domain still moves on its own clock, and the 4.x to 5.x leg has its own interoperability checks for NSX and vCenter.

2. vLCM baselines will stop the ESX upgrade cold

Symptom: Everything upgrades fine until the ESX host phase, then the workflow blocks on clusters still managed by vSphere Lifecycle Manager baselines.

Likely cause: Image-based lifecycle management is the only model going forward. Any cluster still on the old baseline (VUM) model has to be converted to a vLCM image before the host upgrade can run. This is the single most common reason a 9.0 host upgrade stalls.

Fix: Convert every cluster to a vLCM image well before the upgrade window, not during it. Image conversion surfaces firmware and driver compliance gaps against your hardware vendor add-on, and those gaps take time to close. Check the image against the 9.0 hardware compatibility list per cluster. A representative pre-flight check:

# Confirm each cluster is image-managed, not baseline-managed
Get-Cluster | Select Name, @{N='Mgmt';E={
  ($_ | Get-View).ConfigurationEx.DesiredSoftwareSpec ? 'Image' : 'Baseline' }}

# vSAN on-disk format and health must be green before host upgrades
esxcli vsan storage list
esxcli system version get

3. Identity Manager does not migrate, and that is the worst surprise

Symptom: You expect vIDM to roll forward like everything else. It does not. There is no upgrade and no in-place migration to VCF Identity Broker.

Likely cause: VCF Identity Broker (VIDB) is a new component with no migration tooling from vIDM. You stand up a fresh VIDB and re-establish identity from scratch. This bites hardest when VCF Automation is in the picture, because the new automation stack needs a clean VIDB deployment to authenticate against.

Fix: Plan a greenfield VIDB deployment in parallel, then re-create your identity sources, directory connections, and role mappings by hand. Document every group-to-role binding before you start, because nothing carries over automatically. One catch that trips people: do not delete the old Aria Suite Lifecycle 8.x instance or its vIDM. After you upgrade Aria Automation 8.x to VCF Automation 9, Aria Suite Lifecycle 8.x still owns Day-N operations for vIDM 3.3.x, and vIDM remains an authentication source until you have fully cut over. Keep it parked.

4. SDDC Manager did not disappear, it moved

Symptom: After the upgrade your team logs in looking for the familiar SDDC Manager UI and cannot find it.

Likely cause: The SDDC Manager interface is now folded into the VCF Operations console under fleet management. The asynchronous patching and scheduling you already know are still there, just reached through a consolidated console. The mechanics of upgrading did not change much; the front door did.

Fix: Set expectations with your operators before go-live. More important: VCF Operations and VCF Operations fleet management are mandatory in 9.0 even if you never ran a single Aria product. The upgrade deploys them for you. Size and place those appliances in your design now, or you will be scrambling for management-domain capacity mid-upgrade. Revisit your VCF 9 licensing and consumption model at the same time, since licensing now runs through VCF Operations across the whole fleet.

5. Some components are a redeploy, not an upgrade

Symptom: You scope the project as an upgrade, then discover two pieces of the stack have no upgrade path and have to be rebuilt.

Likely cause: Aria Suite Lifecycle has no path to version 9; instead a VCF Operations fleet management appliance is deployed and the existing connection to Aria Operations 8.x is imported into it. Aria Operations for Logs also has no upgrade path, so VCF Operations for logs 9.0 is a fresh deploy. vIDM, from point 3, is the third.

Fix: Build the redeploys into the plan as named workstreams with their own owners and time. For logs, that means re-creating log forwarding, content packs, alerts, and retention on the new VCF Operations for logs instance. None of it migrates. Inventory what each of these services is doing today and rebuild it deliberately, rather than discovering the gap after cutover when an alert that used to fire has gone silent.

6. There is no rollback button, so build your own checkpoints

Symptom: A component upgrade fails partway, the window is shrinking, and there is no single control to revert the whole fleet.

Likely cause: VCF has no holistic rollback. The upgrade runs serially through the components in a fixed order, and a failure in one does not automatically unwind the others.

Fix: Make every serial step its own checkpoint. Back up the component before you upgrade it, so a failure means reverting one piece rather than the entire instance. The order is not negotiable, so plan your backups around it:

Upgrade and backup order (management domain)

1. VCF Operations components: snapshot and backup, then upgrade.
2. SDDC Manager: file-level backup, then upgrade.
3. NSX: NSX Manager backup, then upgrade.
4. vCenter: file-based backup, then upgrade.
5. ESX hosts: per-cluster, rolling, with vSAN health green.

If a step fails and the clock is against you, revert that one component to its checkpoint, get the environment back to a known-good running state, and open a support case rather than improvising deeper into the stack. This single discipline, a backup before each serial step, is the difference between a bad hour and a bad weekend.

7. The edge cases that fail prechecks: VCD, standalone NSX, and OSA hardware

Symptom: A dependency you assumed was supported turns out to have no path, or NSX behaves differently than the docs you read last month.

Likely cause and fix, case by case:

• VMware Cloud Director. VCD is not supported with VCF 9.0 and there is no official migration path. If your tenancy model depends on VCD, that is a blocker to resolve with your account team before you schedule anything, not a detail to handle later.
• Standalone NSX and the 9.0.0 vs 9.0.1 gap. NSX 4.x deployments that are not part of a VCF instance must first be imported as a workload domain before they upgrade to 9.0. Starting in 9.0.1, NSX 4.1.0.2 or later that is registered to a vCenter not using Enhanced Linked Mode can be upgraded through the installer convergence workflow. Confirm your exact target build, because the behavior changed between 9.0.0 and 9.0.1.
• vSAN OSA hardware. OSA is not deprecated in 9.0, so you do not need new ESA-ready hardware to upgrade. But verify your existing controllers and firmware are on the 9.0 compatibility list. If you are weighing a storage architecture change at the same time, read the trade-offs in vSAN ESA vs OSA in VCF 9 before bolting it onto the upgrade.

My take

If your estate is heavily wired into vIDM, Aria Automation, and VCD, an in-place upgrade is not automatically the cheapest route. Once you are redeploying identity, logs, and possibly rebuilding automation anyway, a fresh 9.0 instance with a clean import of workloads can be less risky than dragging years of management-plane debt through the upgrade. Run that comparison honestly. The decision framework is in VCF 9 adoption paths: when to converge, import or start fresh.

What I’d Do

Stage it. Get the whole fleet to 5.2.x and stable first, convert every cluster to vLCM images, and inventory the three redeploys (vIDM, logs, Aria Suite Lifecycle) as separate workstreams before you schedule a single 9.0 step. Back up before every serial component upgrade without exception. The upgrade itself is well-engineered; the projects that go sideways are the ones that treated it as a patch instead of a platform change. Which of these seven caught you off guard, or is there one you would add to the list?

References

• Broadcom TechDocs: Overview of Deploy, Converge, and Upgrade (VCF 9.0)
• VCF Blog: Upgrading VMware Cloud Foundation 5.2 to 9.0, the Top 10 Questions Answered
• VCF Blog: Modernizing Infrastructure, VCF 5.2.x to 9.1 Upgrade Guide

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