// Guide · Pre-deployment & planning

VCF Upgrade Path Advisor

VCF upgrades aren't direct — you usually have to hop through intermediate versions. This tool calculates the supported sequence between any source and target, lists the component versions at each hop (vCenter, ESXi, NSX, SDDC Manager), and flags End-of-Life issues so you don't plan an upgrade to an unsupported release.

VCF 4.x → 5.x → 9.xUpgrade hopsComponent versionsKB referencesEoL warnings

Open the tool Jump to walkthrough

Quick start

Select your current VCF version from the source dropdown.
Select your target VCF version from the destination dropdown.
Read the hop sequence — each intermediate release shown with its component versions.
Review KB references for each hop — official VMware KB articles for upgrade procedures.
Watch for EoL warnings — the tool flags any version that's reached End-of-General-Support.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool:

Before planning any VCF upgrade — confirm you can actually go from your current version to where you want to be without an unsupported jump.
When auditing a long-overdue upgrade — sites stuck on VCF 4.4 or 4.5 often need 3-4 hops to get current.
To estimate upgrade time — each hop is roughly 4-12 hours of maintenance; hop count drives the schedule.
To check component compatibility — does the upgrade need an NSX major version change? An ESXi major version? Both add complexity.

How it works

VMware doesn't support arbitrary version-to-version upgrades. Every supported source-target pair has a specific path, and skipping intermediate releases breaks the upgrade machinery (LCM, vUM, SDDC Manager workflows).

The tool uses BFS (breadth-first search) over the official VMware compatibility matrix to find the shortest supported path. Each hop shows:

Source and target VCF release
vCenter version delta
ESXi version delta
NSX version delta
SDDC Manager version delta
Linked KB articles for the upgrade procedure
EoL warnings if the version is past general support

Step-by-step walkthrough

1. Pick your current version

Source dropdown lists all known VCF versions from 4.x through 9.x. EoL versions are marked (EOL). Pick the exact version your environment runs — check SDDC Manager UI under About.

2. Pick your target version

Pick where you want to be. Common targets:

Latest 9.x for new feature access
Last release of your current major (e.g. 5.2.x latest) for stability without a major version bump
A specific version mandated by support contract or feature requirement

3. Review the hop sequence

The tool shows each hop with arrows. Example: 4.5.0 → 5.0.0 → 5.1.0 → 5.2.0 → 9.0.0. Each hop is its own maintenance window.

4. Inspect per-hop component versions

For each hop, see what versions of vCenter, ESXi, NSX, and SDDC Manager you'll be running after that hop. Major version jumps in NSX (3.x → 4.x) or vCenter (7.x → 8.x) add risk and may need additional planning.

5. Open the KB articles

Each hop links to the relevant VMware KB article (e.g. "Upgrading VMware Cloud Foundation from 5.1 to 5.2"). Read these — they list known issues, prerequisites, and step-by-step procedures.

6. Plan the schedule

Each hop is 4-12 hours depending on cluster size. Build the maintenance windows, raise change records, and (critically) back up vCenter and SDDC Manager configuration before starting.

Common mistakes

🚨

Trying to skip a hop You CANNOT go directly from 4.5 to 9.0 even if they're both "supported" — the upgrade machinery breaks. Always follow the path the tool shows. Skipping creates orphaned configurations that need manual recovery.

⚠

Upgrading to an EoL version The tool warns when target is past End-of-General-Support. Don't target EoL versions for long-term operation — you'll just need another upgrade soon, with no security patches in between.

⚠

Ignoring NSX major version jumps NSX 3.x → 4.x is a significant change. Test extensively in non-prod, plan for a backout, validate all firewall and routing policies. The tool flags the version delta but you need to read the NSX release notes too.

🚨

Not backing up SDDC Manager A failed SDDC Manager upgrade with no backup is a catastrophic event. Always take the backup, verify it's restorable, and document the location before starting any upgrade hop.

⚠

Reading old KB articles Broadcom occasionally re-issues KB articles with new IDs after the VMware acquisition. Verify the linked article is still current; check broadcom.com/support if a link 404s.

Tools that pair well with VCF Upgrade Path Advisor:

FAQ

Where does the version compatibility data come from?

The tool uses Broadcom's published VCF Lifecycle Management compatibility matrix. Updates lag the official matrix by a few weeks; verify against the official source for production planning.

Why are some paths shown but flagged as "not recommended"?

A path being technically supported isn't the same as being a good idea. Some hops introduce known issues, require complex workarounds, or pass through versions with severe bugs. The tool surfaces these flags from KB articles.

Can I downgrade VCF?

In general, no. VCF upgrades are one-way. Some specific patch-level rollbacks are supported within a release line, but major version downgrade requires backup-restore from before the upgrade.

What about partial upgrades — just NSX or just vCenter?

VCF requires upgrading the whole stack together via SDDC Manager workflows. Component-only upgrades break support. Use SDDC Manager's LCM workflow exclusively.

How long does the average hop take?

4-12 hours for a typical management domain (4-8 hosts). Longer for large clusters or many WLDs. Each component (SDDC Manager → vCenter → NSX → ESXi) is upgraded sequentially within a hop.