vSphere Upgrade Checklist: vSphere 8.x and the Move to VCF 9

Most vSphere upgrades that go wrong don't fail in the installer. They fail on a check nobody ran: a host that isn't on the compatibility guide, a backup product that doesn't support the new API yet, or a licence that can't be carried forward. This vSphere upgrade checklist covers patching within vSphere 8.x and the bigger step to vSphere 9, which ships as part of VMware vSphere Foundation (VVF) 9 and VMware Cloud Foundation (VCF) 9.

In our own upgrades, two checks catch problems more often than any other: certificates close to expiry, and third-party VIBs on hosts that aren't supported on the target release. Both are quick to find before the window and slow to fix in the middle of it.

1. Decide what you're upgrading to

• Staying on 8.x: move to the latest 8.0 Update 3 patch level and confirm the end-of-general-support date on the Broadcom Product Lifecycle Matrix before you plan further.
• Going to 9: vSphere 9 is delivered through VVF 9 or VCF 9. Decide which bundle you're licensed for first, because it changes which components (VCF Operations, NSX, vSAN) come with the upgrade.
• Read Broadcom's KB on the supported upgrade path from vSphere 8.x to VVF/VCF 9 for your exact source build; source versions older than 8.0 need an intermediate hop.

2. Compatibility checks

• Every host model, CPU, NIC, HBA and storage controller on the Broadcom Compatibility Guide for ESXi 9.0. Hardware supported on 8.0 is not automatically supported on 9.0, and some older CPU generations are dropped.
• Firmware and driver versions matched to the target release (vendor HSM/firmware bundles if you use vLCM images).
• The interoperability matrix for everything that talks to vCenter: backup, replication (Zerto, Rubrik, SRM), monitoring, NSX, Horizon or Citrix, and any automation using older APIs.
• Third-party VIBs on every host (esxcli software vib list): vendor drivers, agents and plug-ins that the target image doesn't include or support. An unsupported VIB can block the host upgrade, or leave the host without a working driver afterwards.
• Guest operating systems and VM hardware versions you intend to upgrade, if any.

3. Licensing before you touch anything

• vSphere 8 keys don't convert into 9 keys. Version 9 uses subscription licence files managed through VCF Operations and the Broadcom Business Services console.
• Confirm your entitlement covers the cores you run, and that the licences are available in the portal before the maintenance window.

4. Back up and plan the rollback

• File-based backup of vCenter (VAMI) to a location outside the cluster, plus a current image-level backup.
• Export distributed switch configurations and record host profiles or vLCM images.
• Write the rollback steps for each stage: vCenter restore, host reinstall to the previous image, and who decides to roll back.

5. Upgrade order

1. Management and integration components that must support the new vCenter first (check each one's matrix).
2. vCenter Server.
3. ESXi hosts, one cluster at a time, using vLCM images and maintenance mode with DRS evacuating VMs.
4. vSAN on-disk format (only after every host in the cluster is upgraded).
5. Distributed switch version, then VMware Tools and VM hardware where there's a reason to.

In a VCF-managed environment, don't upgrade components by hand. SDDC Manager (with VCF Operations fleet management in VCF 9) controls the sequence and checks every component against the release's bill of materials: broadly SDDC Manager and the fleet components first, then NSX, vCenter and ESXi, with the management domain before the workload domains. Run its upgrade precheck well before the window and follow the order it gives you.

6. Pre-checks on the day

• vCenter and host health: no stale alarms, vCenter, ESXi and solution certificates not near expiry, NTP and DNS forward and reverse lookups correct.
• vSAN health green and resync complete; enough free capacity for maintenance mode evacuations.
• No VMs pinned to hosts (local ISOs, passthrough devices, affinity rules that block evacuation).
• Snapshots consolidated, and backups not scheduled during the window.

7. After the upgrade

• Re-run health checks, confirm backup and replication jobs succeed, and check monitoring still collects data.
• Update the as-built documentation and the runbook with what changed and how long each step took.