Migrating from VMware Cloud Foundation (VCF) 5.2.x to 9.1 is one of the most complex and critical processes in virtualized infrastructure management. Far from a simple component update, this transition involves a deep restructuring of management, orchestration, and network layers, where each step must be executed in a strict order to avoid blocks or service loss. In this runbook we detail the exact sequence, mandatory dependencies, and expected downtime, incorporating practical recommendations that every IT architect should consider.
Context and challenges of the upgrade
VCF 5.2.x to 9.1 is neither a direct nor trivial path. Broadcom, after acquiring VMware, has redefined the product architecture, introducing new services such as VCF Management Services and repositioning Aria Operations as VCF Operations. The main difficulty lies in preserving the dependency chain while multiple control planes (lifecycle management, network, compute, storage) change under the same environment. A mistake in order can leave the infrastructure in an inconsistent state with no simple rollback.
Mandatory dependency-based sequence
The order established by Broadcom places operations components before the VCF core. This hierarchy is not an administrative whim: VCF Operations becomes part of the control path needed to continue lifecycle management in VCF 9.1. Therefore, the sequence is:
1. Source version eligibility check: Not all 5.2.x versions have a supported path. Broadcom provides paths for 5.2.0 through 5.2.3, but 5.2.4 is currently blocked. Before downloading any bundle, confirm with the VCF Upgrade Planner tool that the exact build and BOM combination is valid.
2. Operations (Aria Operations to VCF Operations): This is the first productive step. The Aria Operations cluster must be upgraded, ensuring continuity of metrics, alerts, and dashboards. Cluster health after upgrade is a necessary condition to proceed.
3. SDDC Manager: Once VCF Operations is operational, upgrade SDDC Manager to 9.1. It is the central control point of the domain.
4. VCF Management Services: A mandatory service in 9.1 that includes Fleet Lifecycle, identity, licensing, and software depot. Before deploying, reserve at least 12 IP addresses and ensure forward and reverse DNS records.
5. NSX Federation (if present) and NSX Local Managers: Network must be upgraded before vCenter and ESX. Global Managers lead the transition.
6. vCenter Server: Updated via Fleet Lifecycle. vCenter unavailability affects provisioning, DRS, and automations, but running virtual machines continue.
7. Cluster migration to vLCM image: Clusters managed by baselines must be converted to images before host remediation.
8. ESX hosts and vSAN: Sequential host upgrade, respecting evacuation constraints and vSAN synchronization. Witness hosts in stretched clusters upgrade before data hosts.
9. NSX Edge Nodes: The north-south data plane is updated last, with possible brief packet loss during route convergence.
10. Post-core services: Identity Broker, Logs, Orchestrator, and other conditional products complete the transition.
Critical dependencies and stop points
Each stage has entry conditions that, if not met, must halt the process. For example, if VCF Operations does not collect data correctly after upgrade, do not proceed to SDDC Manager. If Management Services DNS validation fails, resolve it before continuing. Broadcom advises not to force an unsupported path, such as trying to upgrade 5.2.4 to 9.1. In practice, many organizations encounter blockers due to unverified hardware compatibility, insufficient ESX bootbank space, or custom VIBs that conflict with the target image.
Downtime estimation and maintenance windows
There is no single number for total time. It depends on the number of workload domains, number of hosts, evacuation speed, vSAN resynchronization, and application testing. However, we can separate four clocks: execution time, stabilization time, validation time, and decision buffer. A maintenance window covering only execution is incomplete. For example, the VCF Operations upgrade may appear stalled for long periods while database work occurs; monitoring active logs is more reliable than the progress bar. Virtual machines usually stay available during most of the process, but management operations (provisioning, network, observability) are affected.
Validation and evidence
Each stage must generate an evidence package: source and target versions, task logs, service health, validation screenshots. Validation should move from internal component health to representative business-service behavior. For example, after upgrading vCenter, verify that integrations with backup, monitoring, and automation tools work. A green lifecycle task is not enough; application owner confirmation is required.
Rollback strategy
There is no single undo button for the entire upgrade. As you progress, rollback capability decreases. Before the Operations upgrade, a supported cluster restore may be viable. Once VCF Management Services is deployed, rollback becomes much more complex and requires Broadcom support. The rule is: if a stage fails, repair or retry before attempting an independent reversion that could create version mismatch.
Recommendations from Q2BSTUDIO’s experience
At Q2BSTUDIO, specialists in custom software development and digital transformation, we have accompanied numerous organizations through complex infrastructure migrations. Planning a VCF upgrade is not only a technical exercise; it requires integrating automation tools, artificial intelligence to analyze logs and predict failures, and cybersecurity strategies to protect management planes during the change window. Additionally, integration with cloud platforms such as AWS or Azure allows maintaining external backups and facilitating business continuity. In our projects, we apply Business Intelligence (Power BI) methodologies to monitor progress in real time and generate evidence dashboards. We also deploy AI agents that analyze component health and suggest stop points before they become incidents.
Conclusion
Upgrading VCF 5.2.x to 9.1 is a project that must be approached with the same rigor as a data center migration. The sequence is non-negotiable: Operations, SDDC Manager, Management Services, NSX, vCenter, ESX, Edge. Each step needs entry conditions, validation, and evidence. Downtime is not absolute, but there are operational risks in management, network, and storage. With careful planning, proper tools, and support from experts like those at Q2BSTUDIO, the transition can be performed successfully, minimizing business impact and laying the foundation for a modern, scalable, and secure infrastructure.
