Planning a vSphere Major Upgrade: Order, Interoperability and a Go/No-Go Record

Direct answer: a major vSphere upgrade is a change to a whole set of products, not just two installers. Start with the lifecycle date that forces the work. vSphere 7.0 reached end of general support on 2 October 2025, and vSphere 8.0 reaches it on 11 October 2027. Then follow Broadcom's published update sequence. Every integration above vCenter goes first, including backup products that use the vSphere Storage APIs for Data Protection, vSphere Replication, Site Recovery Manager and NSX. After them come vCenter, then ESXi, then VMware Tools, virtual hardware and vSAN formats. Check each pair of products in the Broadcom Product Interoperability Matrix and confirm the upgrade path is supported. Clear the features vSphere 8.0 removes, run the pre-checks, and record a go/no-go decision with a tested backup and rollback for vCenter. Patching within a release is a separate job, covered in the Lifecycle Manager article listed under Related articles.

Why it matters

Most failed major upgrades do not fail in the installer. They fail afterwards, when something that depended on the old version stops working:

• A backup product that no longer connects to vCenter.
• A monitoring pack that reports nothing.
• A storage plug-in or driver that is missing on the new ESXi image.
• An identity source that no longer authenticates.

These breakages are often found days later, for example at the first failed backup.

The order also matters in its own right. Broadcom KB 372863 says to always upgrade vCenter Server before the ESXi hosts. KB 314601 gives the same rule for minor and major updates within 7.0 and 8.0.

Lifecycle sets the deadline. Broadcom KB 415405 records that vSphere 7.0 (ESXi, vCenter and vSAN 7.x) reached end of general support on 2 October 2025. KB 459135 gives 11 October 2027 for vSphere 8.0. For what support is still available after those dates, see the Broadcom Maintenance Policy Handbook linked from those KBs. This article does not summarise it.

How it works

The update sequence

Broadcom KB 308161, "Update Sequence for VMware vSphere 8.0 and Compatible VMware Products", lists the products in the order they should be updated. The list uses current product names; the KB notes that its body still uses the older vRealize names.

1. VMware Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)
2. VMware Identity Manager
3. Aria Operations for Logs (vRealize Log Insight), plus content packs if required
4. Aria Operations (vRealize Operations), plus management packs if required
5. Aria Operations for Networks
6. Aria Automation
7. vSphere Storage APIs – Data Protection (VADP), which is where backup products that use VADP fit
8. vSphere Replication
9. Site Recovery Manager
10. NSX
11. vCenter Server
12. ESXi
13. VMware Tools
14. Virtual hardware
15. vSAN on-disk format
16. vSAN File Services

The KB's rules for using the list:

• Start with the lowest number.
• Skip products you do not have.
• Products sharing a number can be done in either order.

The KB's preconditions for 8.0

KB 308161 also sets these conditions:

• vCenter Server must be at least 6.7 to upgrade to 8.0.
• Hosts must be at least 6.7 to be upgraded to 8.0, or to be managed by vCenter 8.0.
• On vSAN, upgrade the witness host before the data hosts.
• NSX for vSphere must be migrated to NSX before the upgrade.
• vRealize products must be at version 8.x first.
• vSphere 8.0 rejects certificates with weak signature algorithms such as SHA-1 and MD5. A pre-check blocks the upgrade if any are present.

The KB also lists minimum versions for the integrated products, for example NSX 4.0.1.1, Site Recovery Manager 8.6 and vSphere Replication 8.6. Treat the KB and the matrix as the authority, because these minimums can change.

Version alignment and linked mode

KB 314601 describes vCenter being updated first in every scenario. The vSphere 8.0 release notes (Upgrade notes) give as best practice that the vCenter version is always greater than or equal to the ESXi version, so that new capabilities can be used. Check the specific pair against the Interoperability Matrix as well. KB 314601 gives one exception for minor updates: an ESXi express patch may have no matching vCenter release.

For Enhanced Linked Mode (ELM), KB 372863 says all vCenter servers must be on the same version. They may differ only during the upgrade itself, which should be finished on the same day, upgrading each vCenter in turn. It adds a snapshot rule that is easy to miss. If the vCenters are in ELM, all of them must be powered off together and snapshotted while they are all off. If you revert, revert every vCenter in the linked group to the same point in time.

Features vSphere 8.0 removes or deprecates

The vSphere 8.0 release notes list changes that commonly block an upgrade or change behaviour after it:

The vSphere 8.0 release notes also list guest operating systems that are deprecated or terminated. Check any very old VMs against the Compatibility Guide's guest OS list.

Read-only checks

None of these was run for this article. Interoperability and upgrade-path lookups are done in a browser. The inventory checks need at least read-only access to vCenter, and the pre-check tools run on the appliance with administrative access.

1. Inventory what is integrated. List every product that talks to vCenter or ESXi:

• Backup, replication and DR products
• Monitoring and log forwarding
• Storage array plug-ins and multipath software
• NSX and network appliances
• Identity sources
• Automation that uses the APIs or PowerCLI

For each one, note its version and who owns it. Backup software belongs on this list as a product whose compatibility is a vendor statement. Its supported vSphere versions come from the backup vendor's own compatibility documentation, not from Broadcom.

2. Check interoperability (KB 343230). In the Product Interoperability Matrix (interopmatrix.broadcom.com), choose Interoperability. Select vCenter at the target version and check it against ESXi and each VMware product you run. Use 3rd Party Solution for supported third-party combinations. Save the results with the date.

3. Check upgrade paths (KB 343230). In the same matrix, choose Upgrade Path and select the product. Clear Hide Patch Releases to see paths from your exact build. A path that is not listed is not supported. Plan an intermediate step instead.

4. Check hardware and I/O devices. For each host model, NIC, HBA and storage controller, look up the target ESXi version in the Broadcom Compatibility Guide (compatibilityguide.broadcom.com), as KB 390293 advises. Read the installed driver versions from each host:

esxcli software vib list
esxcli network nic list
esxcli storage core adapter list

These commands only list. They change nothing and run in the ESXi Shell or over SSH as root. Check any VIB from a third party against the vendor's 8.0 support statement.

5. Check certificates and identity.

• Look for SHA-1 or weak-signature certificates. KB 372863 links Broadcom's vCert tool for certificate review.
• Confirm no identity source uses IWA. The AD Users Cannot Sign In to vCenter After a Domain Controller Certificate or Server Change covers LDAPS identity sources.

6. Run the pre-check tools.

• KB 372863 points to the VCF Diagnostic Tool for vSphere (VDT). It runs on the vCenter appliance and reports PASS, FAIL or WARN for known configuration issues.
• The vCenter installer has its own pre-checks, which run in stage 1 before anything is migrated.

7. Confirm recovery. Make sure a current vCenter file-based backup exists and has been rehearsed. See the published vCenter backup article under Related articles. KB 372863 says not to proceed past stage 2 unless a valid VAMI backup was taken first. Without one, a failed upgrade can mean redeploying vCenter from scratch.

Interpreting the results

Decision guidance

Write the go/no-go record

Keep one page per upgrade with:

• Current and target builds, and the lifecycle date that drives the work.
• The integration inventory, with each product's interoperability result and the date checked.
• The upgrade paths found.
• The sequence actually planned: the KB 308161 order, with products you don't have crossed out.
• Hardware and driver results per host model.
• Pre-check and VDT output.
• The date of the last vCenter backup and the date its restore was rehearsed.
• The rollback for each stage.
• Who approved it, and the go/no-go decision.

If any line is unknown, the decision is no-go or a conditional go that names the gap.

Stage the work in sequence

1. Integrations above vCenter. Upgrade them in the KB 308161 order, and verify each one works against the current vSphere before you touch vCenter.
2. vCenter. - Before: reboot it to clear any pending reboot, set DRS on the vCenter's own cluster to Partially Automated or Manual, and remove vCenter HA if you use it (KB 372863). - Take a VAMI backup and snapshots, with all ELM vCenters powered off together. If the vCenter runs vSphere Supervisor or VKS, KB 313886 warns that snapshot rollbacks will not work with the Supervisor Control Plane VMs; make the file-based backup, taken as part of the Supervisor backup and restore process, the rollback point. - The 7 to 8 upgrade deploys a new appliance and migrates data in two stages. Ports 443 and 902 must be open between the appliances (KB 372863). - Verification: sign in, check inventory, permissions and identity sources, and confirm every integration reconnects. - Rollback: KB 372863 says to gather logs and revert to the pre-upgrade snapshot. For ELM, revert all linked vCenters to the same point. With Supervisor or VKS, recover from the file-based backup under the Supervisor recovery plan instead of reverting snapshots.
3. ESXi hosts. - Upgrade one host, or one cluster, at a time, in maintenance mode, using an image that contains the drivers you verified. - Verification: each device present, datastores and networks visible, HA and vMotion working, and backup jobs succeeding on VMs on that host. - Rollback: keep 7.x hosts in the cluster until the 8.0 hosts are proven, and stop the rollout if a host fails verification.
4. VMware Tools, then virtual hardware, then vSAN formats. These come last and separately. Virtual hardware upgrades are one-way per VM (see the Planning a VM Hardware Version Upgrade in vSphere: When, How and What to Check). Plan the vSAN on-disk format upgrade as its own step, checking the vSAN upgrade documentation for whether it can be reversed.

When to stop

Stop at the current stage if any integration fails verification after its own upgrade, or after vCenter's. Fixing a broken backup integration while hosts are half upgraded is harder than holding the hosts where they are.

What not to do

• Do not upgrade ESXi before vCenter (KB 372863, KB 390293).
• Do not leave ELM vCenters on different versions beyond the upgrade window, or snapshot them one at a time (KB 372863).
• Do not treat "Compatible" in the matrix as proof that a third-party backup product works. That is the vendor's statement to obtain, followed by your own backup and restore test.
• Do not start stage 2 of the vCenter upgrade without a valid file-based backup (KB 372863).
• Do not upgrade virtual hardware or the vSAN on-disk format in the same window as the hosts.
• Do not rely on a deprecated feature (IWA, baselines, CIM) because it still works in 8.0. Plan its replacement.

Limitations

• The sequence, minimum versions and removed features come from the 8.0 KBs and release notes. vSphere 9.x upgrades have their own sequence, and this article does not cover them.
• The Interoperability Matrix and Compatibility Guide change over time. Record the date you checked them, and check again shortly before the window.
• Support terms after end of general support are covered by Broadcom's Maintenance Policy Handbook. This article does not summarise them.
• Third-party product compatibility is outside Broadcom's documentation and is not assessed here.

Acceptance checklist

• [ ] Lifecycle dates recorded (7.0 EoGS 2 October 2025; 8.0 EoGS 11 October 2027)
• [ ] Integration inventory complete, with owners and versions
• [ ] Interoperability and upgrade-path results saved with dates
• [ ] Backup vendor's support statement for the target version on file, and backup and restore tested after the integration upgrade
• [ ] Hardware, NIC/HBA drivers and third-party VIBs checked against the Compatibility Guide
• [ ] Weak certificates and IWA cleared, and VDT and pre-checks clean
• [ ] vCenter file-based backup taken and its restore rehearsed; ELM snapshots taken together; with Supervisor or VKS, the file-based backup is the rollback point
• [ ] Go/no-go record signed; hosts upgraded only after vCenter is verified
• [ ] Tools, virtual hardware and vSAN formats scheduled separately

References

All accessed 2 November 2026. Broadcom knowledge base articles do not display a last-updated date; TechDocs pages show "Last Updated October 28, 2026" where readable.

• Broadcom KB 308161, Update Sequence for VMware vSphere 8.0 and Compatible VMware Products: https://knowledge.broadcom.com/external/article/308161/update-sequence-for-vmware-vsphere-80-an.html
• Broadcom KB 372863, Upgrade vCenter Server 7.0 to 8.0: https://knowledge.broadcom.com/external/article/372863/upgrade-vcenter-server-70-to-80-vcenter.html
• Broadcom KB 390293, Install or upgrade ESXi from 7.x to 8.x: https://knowledge.broadcom.com/external/article/390293
• Broadcom KB 314601, vCenter Server version and ESXi host version recommendations and considerations: https://knowledge.broadcom.com/external/article/314601/vcenter-server-version-esxi-host-versio.html
• Broadcom KB 415405, End of General Support for vSphere 7.0: https://knowledge.broadcom.com/external/article/415405/end-of-general-support-for-vsphere-70.html
• Broadcom KB 459135, End of General Support for vSphere 8.0: https://knowledge.broadcom.com/external/article/459135/end-of-general-support-for-vsphere-80.html
• Broadcom KB 343230, Using the VMware Product Interoperability Matrixes: https://knowledge.broadcom.com/external/article/343230/using-the-vmware-product-interoperabilit.html
• Broadcom TechDocs, VMware vSphere 8.0 Release Notes: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vmware-vsphere-80-release-notes.html

Related articles

• How to patch an ESXi cluster with vSphere Lifecycle Manager
• How to back up and rehearse recovery of the vCenter appliance

• VMware Tools Not Running or Out of Date: What It Breaks

• AD Users Cannot Sign In to vCenter After a Domain Controller Certificate or Server Change

• Planning a VM Hardware Version Upgrade in vSphere: When, How and What to Check

Learning notes

1. The lifecycle date sets the deadline. The update sequence sets the order: integrations, then vCenter, then ESXi, then Tools, hardware and vSAN formats.
2. vCenter is always upgraded before ESXi, and linked vCenters move together on the same day.
3. Interoperability and upgrade paths come from the Broadcom matrix. Backup compatibility comes from the backup vendor.
4. vSphere 8.0 removes or deprecates real dependencies (NSX-V, old VIBs and drivers, software FCoE, TPM 1.2, SHA-1 certificates, IWA), so audit them before the window.
5. A go/no-go record with a rehearsed vCenter backup turns a risky change into a controlled one.