TL;DR
A VCF 9.1 upgrade should not be treated like a normal maintenance window where each team updates its component, checks a dashboard, and leaves.
The sequence matters. The ownership model matters. The readiness evidence matters.
For VCF 9.1, VCF Operations is not a side task after the platform upgrade. Existing Aria Operations instances must be handled before core VCF components move forward, and VMware guidance requires Aria Operations to be at version 8.18 before it can be upgraded to VCF Operations 9.1. VCF Operations is also mandatory in VCF 9.x, which means environments without it need to account for it in the upgrade path.
That single sequencing requirement changes the shape of the project.
The upgrade is not only about SDDC Manager, NSX, vCenter, ESXi, and edge clusters. It is about moving the environment toward a different operating model where lifecycle, fleet operations, licensing, observability, management services, and Day-N execution are more tightly connected.
The right question is not:
“When is the patch window?”
The better question is:
“Is the organization ready to operate the platform the way VCF 9.1 expects it to be operated?”
The Mental Model: Upgrade Readiness Is a Chain of Ownership
A patch window is a time slot.
An operating model is a set of owners, decisions, dependencies, escalation paths, and acceptance criteria.
VCF 9.1 upgrade readiness should be viewed as a chain. If one link is weak, the project may still start, but it will not be governed well.
What matters in this diagram is not only the order.
What matters is that each step has a different ownership profile.
The team that owns VCF Operations may not own DNS. The team that owns NSX may not own application validation. The team that owns SDDC Manager may not own certificates, backup evidence, or identity integrations. The upgrade exposes those boundaries.
That is why the runbook needs more than tasks. It needs decision rights.
Scenario: The Upgrade Looks Technical Until the Dependency Map Shows Up
Consider a typical enterprise VCF environment:
- A management domain with SDDC Manager, vCenter, NSX, ESXi, and NSX Edge.
- One or more VI workload domains.
- Existing Aria Operations or adjacent Aria components.
- Shared DNS, IPAM, PKI, identity, backup, monitoring, and logging services.
- Application teams that expect platform stability but are not involved in infrastructure sequencing.
- A platform team responsible for “the upgrade,” but not every prerequisite.
On paper, this looks like a lifecycle management activity.
In reality, it becomes an operating model test.
The VCF team may own SDDC Manager. The virtualization team may own vCenter and ESXi. The network virtualization team may own NSX managers, transport nodes, routing, and edge behavior. The monitoring team may own Aria Operations content, dashboards, alerts, adapters, and collector paths. The security team may own certificates, firewall policy, syslog, identity, and audit requirements. Backup may own recovery points. Application owners may own functional validation.
VCF 9.1 does not create all of those boundaries, but it does make them harder to ignore.
Scope and Terminology Guardrails
This article is not a click-by-click upgrade guide. It is a readiness model for teams preparing to move to VCF 9.1.
The goal is to clarify ownership, sequencing, and operating-model implications before the technical runbook is executed.
The prior VCF 9.1 Upgrade Planning Tool article helps answer:
“What upgrade path applies to my environment?”
This article answers the next question:
“Who owns the operating model required to execute that path safely?”
Assumptions
This model assumes:
You are upgrading an existing VMware Cloud Foundation environment or converging a related VMware estate toward VCF 9.1.
You have more than one operational team involved.
You have production workloads or management dependencies that require evidence-based change control.
- You need a recoverable runbook, not just a list of UI steps.
- You will validate all version-specific details against current Broadcom documentation, KBs, release notes, interoperability data, and compatibility guidance before execution.
That last point matters.
VCF 9.1 guidance is version-sensitive. Patch-level details can change. For example, Broadcom has documented upgrade-path nuance around specific Aria Operations 8.18.x patch levels. Treat “Aria Operations must be at 8.18” as the starting requirement, not as permission to skip exact build validation.
The Decision Criteria: When Is the Organization Ready?
The environment is not ready because the maintenance window is approved.
The environment is ready when the team can answer six questions with evidence.
This is where many upgrade plans are too thin.
They list tasks, but not decision rights.
For VCF 9.1, decision rights matter because the upgrade touches operations, licensing, observability, identity, management services, network control planes, and compute lifecycle.
Why the Patch-Window Mindset Breaks
The patch-window mindset assumes three things:
- The platform is already operationally aligned.
- The upgrade is mostly a technical task.
- Recovery is simply a matter of reverting the last changed component.
Those assumptions are risky in a VCF 9.1 project.
The public upgrade flow places VCF Operations before the core VCF component upgrades. Existing Aria Operations must be upgraded first, and VCF Operations is mandatory in VCF 9.x. After that, SDDC Manager moves forward, VCF Management Services and licensing are deployed, and then the remaining management-domain core components continue through the supported upgrade sequence.
That is not the shape of a routine patch event.
It is a control-plane transition.
The upgrade is doing more than moving binaries forward. It is changing where certain operational functions live and how future lifecycle work is expected to be handled.
Ownership Comes Before Execution
The runbook should contain an ownership model before it contains execution steps.
A simple starting point looks like this:
| Workstream | Primary Owner | Supporting Teams | Required Artifact |
|---|---|---|---|
| Upgrade path selection | VCF platform owner | Architecture, change manager, vendor/partner support | Approved upgrade path and source references |
| Current-state inventory | Platform engineering | Virtualization, network, storage, monitoring | Component inventory and dependency map |
| VCF Operations readiness | Monitoring / VCF operations owner | Platform, identity, DNS, backup | Aria/VCF Operations version plan, collector plan, content export plan |
| SDDC Manager upgrade | VCF platform owner | Backup, network, security | Precheck results, backup evidence, change record |
| VCF Management Services | Platform architecture | DNS, IPAM, security, network | IP/DNS plan, management network validation, service deployment checklist |
| NSX upgrade | Network virtualization owner | Security, routing, application teams | NSX backup, edge validation, north/south and east/west test plan |
| vCenter and ESXi upgrade | Virtualization owner | Storage, backup, application owners | vCenter backup, host remediation plan, cluster evacuation criteria |
| Application validation | Application owners | Platform, monitoring, service desk | Acceptance test record |
| Fallback and escalation | Change owner | All workstream leads | Stop/go criteria and escalation path |
This table should drive the upgrade meeting.
Every phase needs one role that can say:
- We are ready.
- We are not ready.
- We can proceed with risk acceptance.
- We must stop.
- We need vendor support before continuing.
Without that authority model, the team is only coordinating tasks. It is not governing the upgrade.
Sequencing: VCF Operations Is the First Operating Gate
The most important sequencing point is that VCF Operations is not an afterthought.
Existing Aria Operations instances must be upgraded before VCF core components. If Aria Operations is not present, VCF Operations must be installed as part of the upgrade path. A Cloud Proxy may also be required for integration between VCF Operations, SDDC Manager, and VCF Management Services.
That changes the way the monitoring and operations workstream should be treated.
In older operating models, many teams treated Aria Operations as “the monitoring tool.”
That framing is too narrow for VCF 9.1.
VCF Operations becomes part of the lifecycle and management control story. The operations workstream needs design attention before the core upgrade begins.
Key questions include:
- Who owns the VCF Operations upgrade?
- Who validates dashboards, alerts, policies, adapters, and custom content?
- Who confirms collector groups and Cloud Proxy placement?
- Who owns integrations into ticketing, logging, reporting, or event management?
- Who validates observability after VCF Management Services is deployed?
- Who accepts the new operational model after the upgrade?
The mistake is treating monitoring as a post-upgrade check.
In VCF 9.1, operations readiness is upstream from core lifecycle execution.
The VCF Management Services Gate
VCF 9.1 also introduces a management-services dependency that requires infrastructure planning before execution.
VCF Management Services is a required part of VCF 9.1 deployment. It requires management-network IP planning, DNS planning, and awareness of internal service runtime addressing. It also changes how certain lifecycle and operational services are delivered.
That is not something to discover during the change window.
The readiness checklist should include:
This is where the upgrade becomes a governance exercise.
The platform team may be accountable for the VCF upgrade, but it may not own DNS, IPAM, firewall policy, certificates, identity, or licensing. The upgrade depends on all of them anyway.
The Core Upgrade Is Not the Finish Line
After VCF Operations, SDDC Manager, VCF Management Services, and licensing are ready, the remaining core components can move through the supported sequence.
That usually includes NSX, vCenter, ESXi hosts, and NSX Edge finalization for the management domain.
But the management domain is not the whole estate.
Workload domains may become Day-N work. Additional management components may need to be imported, upgraded, migrated, replaced, or decommissioned. Logging, automation, identity, and network observability may require separate decisions. Application owners may need validation windows that do not fit inside the infrastructure window.
The operating model needs to track the work that remains after the first major upgrade event.
A useful Day-N backlog includes:
| Day-N Area | Why It Matters |
|---|---|
| Workload-domain sequencing | Prevents the management-domain upgrade from becoming a false finish line. |
| VCF Operations cleanup | Confirms dashboards, policies, alerts, and collectors align to the new state. |
| License cleanup | Ensures vCenter and related components are correctly connected and licensed. |
| Identity transition | Avoids leaving deprecated or transitional identity services unmanaged. |
| Log management plan | Clarifies whether existing log platforms remain, migrate, or get replaced. |
| Documentation updates | Updates support paths, escalation steps, diagrams, and operations guides. |
| Operational handoff | Confirms the steady-state team knows how to operate the upgraded platform. |
The upgrade is complete when the platform can be operated cleanly, not when the first domain reports 9.1.
Operational Implications After the Upgrade
A VCF 9.1 upgrade should leave behind an updated operating model.
At minimum, the team should update:
- platform ownership records,
- lifecycle runbooks,
- VCF Operations administration procedures,
- DNS and IP allocation documentation,
- license server documentation,
- certificate and identity workflows,
- NSX validation procedures,
- vCenter and ESXi lifecycle notes,
- monitoring and alert routing,
- Day-N workload-domain sequencing,
- support escalation paths.
This matters because the upgrade changes more than versions.
It changes where lifecycle authority lives, how management services participate in the platform, how operations integrates with lifecycle, and how future patching and upgrades should be approached.
Conclusion: VCF 9.1 Readiness Is an Operating Model Test
A VCF 9.1 upgrade can be described as a sequence of technical tasks.
It should not be governed that way.
The sequence quickly reveals the larger issue: VCF Operations comes before core upgrades, management services require infrastructure planning, licensing must be handled deliberately, and workload domains may continue as Day-N work.
That makes the project a coordination problem, an ownership problem, and a readiness problem.
The teams that succeed will not be the ones with the longest maintenance window. They will be the ones with the clearest operating model:
- named owners,
- explicit gates,
- validated prerequisites,
- realistic fallback decisions,
- and a clean handoff into Day-N operations.
The VCF 9.1 Upgrade Planning Tool helps answer what path applies to the environment.
The operating-model question is what determines whether the organization is ready to execute that path.
External References
- VMware Cloud Foundation Blog: How to Upgrade to VMware Cloud Foundation 9.1
https://blogs.vmware.com/cloud-foundation/2026/06/18/how-to-upgrade-to-vmware-cloud-foundation-9-1/ - Broadcom KB 440630: Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1
https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html - Broadcom KB 430778: Unable to Upgrade Aria Operations 8.18.6 to VCF Operations 9.0, 9.0.1, or 9.0.2 from Aria Suite Lifecycle Manager
https://knowledge.broadcom.com/external/article/430778/unable-to-upgrade-aria-operations-8186-t.html - VMware Cloud Foundation 9.1 Release Notes
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes.html - VCF 9.1 Interactive Upgrade Planning Tool
https://williamlam.com/2026/05/vcf-9-1-interactive-upgrade-planning-tool.html
Private AI is not just a question of where to place GPUs. That is where the conversation often begins, but it is…
The post The VCF 9.1 Upgrade Is an Operating Model Project, Not a Patch Window appeared first on Digital Thought Disruption.