Legacy vSphere: Plan a Supported Upgrade Path Safely

A direct vSphere 6.7-to-7 upgrade guide is obsolete. Broadcom states that general support ended for 6.7 in 2022 and for 7.0 in 2025. The correct target and path depend on exact builds, hardware, licenses, dependencies, and current vendor matrices.

Publication boundary: This article provides general educational and operational guidance. Publishing it does not mean ITECS or any specialist approved a reader’s organization-specific implementation, measured its results, made a legal or compliance determination, or verified a vendor’s configured capability.

Establish the exact estate

Record vCenter, ESXi, vSAN, NSX, plugins, backup, replication, hardware, firmware, drivers, storage, networking, licenses, support contracts, workloads, clusters, certificates, identity, and current health.

Resolve compatibility and sequence

• Current lifecycle and interoperability matrices.
• Supported source-to-target paths and required intermediate releases.
• Hardware compatibility, firmware, drivers, add-ons, and vendor integrations.
• Licensing, entitlement, backup, monitoring, automation, and operational dependencies.

Prepare recovery and rehearsal

Verify configuration and data backups, restore procedures, management access, dependency order, maintenance windows, capacity, communications, rollback thresholds, and vendor escalation. Rehearse in representative nonproduction where possible.

Execute only under approved change control

Use current vendor documentation for the resolved versions. Validate management, hosts, storage, networking, clusters, workloads, backup, monitoring, security, performance, and owner acceptance at each gate.

Next step for your environment

Create an exact-version compatibility and recovery record before choosing a supported vSphere target or running any upgrade.

Record the accountable owner, baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.

Before approval, separate observed facts from assumptions, assign every unresolved gap, and preserve the evidence needed to reproduce the decision. Revisit the outcome after implementation so incomplete activity is not mistaken for durable improvement.

For every recommendation, record the affected service, responsible owner, prerequisites, supporting source, test method, failure threshold, exception, and acceptance decision. Confirm that operations, security, users, suppliers, and recovery remain supportable after the proposed change.

Keep the evidence auditable, dated, reproducible, and understandable to the accountable business and technical owners.

If you need an independent baseline before changing production systems, start with an ITECS technology and security assessment and keep the resulting evidence with the decision record.

Sources and update trigger

• Broadcom — End of General Support for vSphere
• Broadcom — vCenter supported upgrade paths

Review trigger: Review immediately before planning or execution and after any build, hardware, dependency, license, or vendor change.