Upgrading from VCF 5.2.x to 9.1: A Field-Ready Playbook
Upgrading from VCF 5.2.x straight to 9.1 is a supported, but non-trivial, path — you’re crossing not just a version boundary but an architectural one. This post lays out the sequence, the gotchas, and the readiness questions to answer before you open the Upgrade Planner.
Step Zero: Confirm the Path Is Actually Supported
VCF only allows upgrades to a version released after your current release date, validated against the Interoperability Matrix. Both VCF 5.2.x and VCF 9.0.x are supported starting points for 9.1; there is no direct path from anything earlier than 5.2. Use the VCF Upgrade Planning Tool to generate a environment-specific plan — it will also flag NSX-specific and Aria-specific starting-state variations (vSphere-only, NSX + vSphere, or Aria Automation + vSphere + NSX) and route you to the correct guide.
Readiness Checklist Before You Touch the Planner
Before entering versions into the planner, resolve these structural questions — they change the entire plan, not just a step in it:
- DNS hygiene. All forward and reverse DNS records must be strictly lowercase. This is the number one field-reported cause of certificate handshake failures during the SDDC Manager / VCFMS deployment stage. Audit this first.
- Syslog transport. Confirm vCenter isn’t still sending unencrypted syslog on port 514 — 9.1 blocks it. Migrate to TLS-encrypted port 1514 before the upgrade window, not during it.
- Environment drift. 9.1 introduces “programmatic rigor” that is markedly less forgiving of configuration drift than 5.2.x was. Reconcile SDDC Manager inventory against actual vCenter/NSX state beforehand.
- Ownership and ELM. vCenter must not be part of Enhanced Linked Mode if you plan to deploy VCF Automation later, and clusters should already be vLCM-based.
- License Server capacity planning. Because the new centralized VCF License Server, Software Depot, and Salt RaaS now live inside VCF Management Services, plan compute/network for that new services cluster as its own workload domain-adjacent footprint — it’s not “free.”
The Orchestrated Sequence
At a high level, the 5.2.x → 9.1 path runs as an eight-step orchestrated sequence:
- Upgrade VCF Operations (out of band, ahead of SDDC Manager) — if Aria Operations is not yet deployed, it’s deployed as part of this step.
- Upgrade SDDC Manager, selecting 9.1.0.0 as the target from Lifecycle Management. Run and clear the precheck before executing.
- Deploy VCF Management Services (VCFMS) — this new component must exist before any other core component upgrade can proceed. This is the step most commonly underestimated on time and resource planning.
- Transition Aria components into VCF Operations, including the license server and identity broker consolidation (VMware Identity Broker 9.1 is deployed as part of the VCFMS step, not separately).
- Upgrade the Management Domain core: NSX Manager cluster first, then vCenter/ESX (NSX host bits are bundled with ESX), then NSX Edge clusters last — a sequence change from pre-9.x versions.
- Repeat for each Workload Domain.
- Deploy VCF Log Management as a Day-N operation, if desired — there is no direct upgrade path for VMware Aria Operations for Logs; it’s a net-new component build plus a manual log-data transfer.
- Validate and decommission legacy standalone appliances that VCFMS now supersedes (Fleet Management, prior Identity Broker instances, etc.).
Note that VMware Aria Suite Lifecycle has no upgrade path to 9.1. If you have Aria Automation 8.x, upgrading it to VCF Automation 9.1 causes Aria Suite Lifecycle to stop managing VCFA — but you should preserve the Aria Suite Lifecycle instance to continue Day-N operations for VMware Identity Manager, which remains an active authentication source for VCFA. Do not delete VMware Identity Manager during this transition.
Known Failure Modes (and the KBs Behind Them)
An incorrect upgrade path or sequencing error commonly manifests as one of these:
- 9.1 upgrade binaries not visible in VCF Operations 9.0 — usually a Fleet Depot sync issue; confirm depot connectivity and metadata sync before retrying.
- “Unable to license vCenter after upgrading to 9.1” — vCenter instances not connected to the new centralized License Server. Confirm the License Server component of VCFMS deployed cleanly before troubleshooting downstream.
- License assignment failures on 9.1 — same root cause family as above; check VCFMS License Server health first.
In-Place vs. Reduced-Downtime (When You’re on 9.0.x)
This distinction only applies once you’re already at 9.0.x moving to 9.1 — 5.2.x customers go through the full sequence above. But it’s worth knowing for the second hop: from 9.0.x, you can choose between an in-place upgrade or a reduced-downtime upgrade, configurable during the update workflow via a temporary network parameter.
What to Tell the Customer
Set expectations clearly: this is not a weekend maintenance window in most estates. The VCFMS deployment alone is a new build, not a patch, and NSX-present environments add a meaningful precheck and sequencing burden. The right posture is a readiness review — DNS, syslog, drift, ELM, and licensing — conducted as a distinct engagement before a maintenance window is scheduled, followed by a planner-generated, environment-specific runbook exported to PDF for change management sign-off.
Modernizing Infrastructure: VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide
VCF 5.2 to VCF 9.1.0.0400 – With Automation
https://vmware.github.io/vcf-upgrade-planner/VCF-5.2-to-VCF-9.1-(VCF-Automation-included).html
