TL;DR
VCF 9.1 changes the upgrade conversation because the management layer is no longer just a collection of adjacent appliances.
VCF Operations, VCF Automation, VCF Management Services, license services, software depot, identity, logging, and lifecycle workflows become part of a more unified private cloud operating model.
That means the VCF 5.2.x to 9.1 upgrade should not be planned as one large VMware maintenance window. It should be planned as a set of coordinated workstreams:
Fleet platform readiness
VCF Operations and management services readiness
SDDC Manager and management domain upgrade
Identity, licensing, depot, certificates, and logging
Automation and consumption validation
vCenter, ESX, NSX, and workload-domain execution
Day-N migration and decommissioning
The technical sequence matters. The ownership sequence matters more.
Why the Management Services layer changes the runbook
In many VCF 5.2.x environments, the runbook is shaped around products.
Upgrade Aria Operations. Upgrade SDDC Manager. Upgrade NSX. Upgrade vCenter. Remediate ESX hosts. Deal with Automation. Check logging. Clean up identity. Move to the next domain.
That kind of runbook can work when every product lane has a clear boundary.
VCF 9.1 changes that because VCF Management Services becomes part of the platform’s shared management capability. Lifecycle, licensing, software depot, log management, identity, and operational control are no longer isolated concerns owned by whichever team happened to own the older appliance.
The operating model has to change with the architecture.
A better runbook starts with scope:
What to notice in the diagram: this is not only a sequence of software updates. It is a sequence of ownership gates. Each gate has a different accountable owner, different prerequisites, and different validation criteria.
That is where many upgrade plans need to mature.
The practical split: core upgrade vs operating-model transition
The VCF 5.2.x to 9.1 path has two overlapping stories.
The first story is the technical upgrade path. Components have to be upgraded or deployed in the correct order. Prechecks must pass. Core management domain components must be remediated. Workload domains may need later upgrade planning.
The second story is the operating-model transition. This is where the old Aria boundary, identity boundary, logging boundary, licensing boundary, and lifecycle boundary get redrawn.
Most teams pay attention to the first story because it has obvious tasks.
The second story is where ownership issues surface.
For example:
This is why the upgrade should not be managed as a simple product checklist.
It should be managed as an operating model cutover.
Scope and terminology guardrails
This article focuses on operating-model planning for VCF 5.2.x to 9.1. It is not a replacement for the official upgrade documentation.
The focus is on how teams should divide responsibility across the management-services transition.
TermPractical meaningVCF OperationsThe fleet operations and lifecycle control surface for VCF 9.x operations.VCF AutomationThe automation, self-service, and consumption layer for infrastructure services.VCF Management ServicesThe VCF 9.1 services layer that hosts management capabilities such as lifecycle services, depot, licensing, and related platform services.Fleet lifecycleThe lifecycle capability used to coordinate management components across the fleet scope.SDDC lifecycleLifecycle capability for SDDC and domain-level components.Identity BrokerThe VCF identity component used to broker SSO between VCF components and external identity providers or directory services.Day-N workWork that happens after the core upgrade window, such as workload-domain upgrades, migration tasks, validation, and decommissioning.Operating-model gateA decision checkpoint that validates ownership, prerequisites, and rollback before execution continues.
The key distinction is that VCF Management Services is not “one more appliance.” It is part of the shared management layer. Treating it as a product-only task weakens the upgrade plan.
Assumptions
This model assumes:
The starting environment is VCF 5.2.x.
The target environment is VCF 9.1.
Aria Operations or other Aria Suite components may already exist.
The organization has separate platform, virtualization, network, IAM/security, observability, automation, and licensing stakeholders.
The environment has enough operational complexity that a single-person upgrade plan is not realistic.
Workload-domain upgrades may be separated from the core management-domain upgrade as Day-N work.
The goal is not to document every click in the upgrade workflow.
The goal is to define the ownership gates that prevent a technical upgrade from becoming an operational mess.
Workstream 1: Fleet platform readiness
The fleet platform workstream owns the shared management plane.
This is where VCF Operations, VCF Management Services, license services, software depot, lifecycle workflows, cloud proxies, and collector continuity need to be treated as platform dependencies.
The accountable owner is usually the VCF platform team or private cloud engineering team.
Key responsibilities:
ResponsibilityAccountable ownerSupporting teamsVCF Operations upgrade or deployment readinessFleet operations ownerObservability, network, securityVCF Management Services deployment readinessFleet platform ownerDNS, IPAM, security, networkLicense service readinessFleet platform ownerLicensing admin, procurementSoftware depot accessFleet platform ownerSecurity, network, offline repository ownerCloud Proxy placementFleet operations ownerNetwork, instance ownerLifecycle workflow readinessFleet platform ownerInstance/domain ownersFleet health validationFleet operations ownerObservability, support teams
This workstream should answer the following before execution:
What components must exist before the rest of the upgrade can proceed?
What IP ranges, DNS records, certificates, and firewall rules are required?
Who owns the license service and entitlement assignment process?
Who owns software depot access in connected and disconnected environments?
Who validates VCF Operations health before and after the upgrade?
Who signs off that management services are ready for the next upgrade gate?
The output of this workstream is not a spreadsheet only. It should produce a go/no-go decision for the shared management layer.
Workstream 2: SDDC Manager and management domain execution
The management domain workstream owns local infrastructure execution.
This includes SDDC Manager, vCenter, NSX, ESX hosts, vSAN, management networks, and the operational condition of the management domain.
The accountable owner is usually the VCF instance owner, with strong support from virtualization and NSX teams.
Key responsibilities:
ResponsibilityAccountable ownerSupporting teamsSDDC Manager readinessVCF instance ownerFleet platform ownervCenter upgrade readinessVirtualization ownerNetwork, DNS, backupESX host remediationVirtualization ownerStorage, app ownersNSX Manager readinessNSX ownerNetwork/securityNSX Edge finalizationNSX/network ownerInstance ownervSAN healthVirtualization/storage ownerHardware supportTemporary IP and network validationNetwork/IPAM ownerVirtualization ownerBackup and rollback readinessInstance ownerBackup platform owner
This workstream should answer:
Are management-domain prechecks clean?
Are temporary IP addresses and DNS records available?
Are certificates and passwords valid?
Are backups current and restorable?
Are hosts ready for remediation?
Is NSX healthy enough to proceed?
Is there capacity for evacuation, maintenance, or host reboot activity?
Who owns rollback decisions if the execution gate fails?
The fleet team may sequence the work, but the instance team owns local readiness.
Workstream 3: Identity, licensing, certificates, and logging
This is the workstream that often gets under-planned.
Identity, licensing, certificates, and logging are not cosmetic tasks. They affect access, audit, supportability, automation, lifecycle, and operations.
The accountable owners are shared across fleet platform, IAM/security, observability, licensing, and network teams.
Key responsibilities:
CapabilityAccountable ownerSupporting teamsIdentity provider integrationIAM/security ownerFleet platform ownerIdentity Broker transitionIAM + fleet ownerAutomation ownerRole and access validationIAM/security ownerPlatform ownersCertificate policySecurity/platform ownerPKI ownerPassword policySecurity/platform ownerOperationsLicense service processFleet owner + licensing adminProcurementLog management transitionObservability owner + fleet ownerSecurity operationsLog forwarding and retentionObservability ownerCompliance/securityAudit evidenceSecurity ownerObservability/platform
The mistake is treating these as cleanup tasks.
They should be operating-model gates.
Before the upgrade continues, the team should know:
How administrators will authenticate after the transition.
Which identity source is authoritative.
Which roles need validation.
How break-glass access works.
Which certificates must be valid before the window.
How license assignment will work after the license service is available.
Where logs will live during and after the migration.
What retention, forwarding, and audit requirements apply.
Which legacy components can remain temporarily and which must be decommissioned later.
If the platform upgrade succeeds but identity, licensing, or logging is unclear, the operating model is not finished.
Workstream 4: VCF Automation and consumption validation
VCF Automation deserves its own workstream.
It is tempting to treat automation as an add-on because it may not block the core management-domain upgrade in every environment. That is the wrong operating model.
Automation is the consumption layer. It is where projects, catalogs, blueprints, policies, integrations, approvals, and Day 2 actions meet real users.
The accountable owner is the automation or cloud consumption team, with support from fleet platform, IAM, network, and integration owners.
Key responsibilities:
ResponsibilityAccountable ownerSupporting teamsVCF Automation upgrade planningAutomation ownerFleet platform ownerProject and organization validationAutomation ownerIAM/securityCatalog item validationAutomation ownerApplication/platform teamsBlueprint or template validationAutomation ownerVirtualization/networkCustom workflow remediationAutomation ownerIntegration ownersApproval policy validationAutomation owner + governanceIAM/securityDay 2 action testingAutomation ownerPlatform teamsCloud zone and placement behaviorAutomation ownerFleet/domain ownersTenant access validationAutomation owner + IAMService owners
The automation workstream should answer:
Which catalog items are business-critical?
Which integrations use custom code?
Which workflows depend on identity behavior?
Which endpoints or providers need validation?
Which approval paths must be tested?
Which users or groups must be revalidated?
Which Day 2 actions could behave differently after upgrade?
Which teams sign off that consumption is restored?
Treat VCF Automation as a product only, and you will miss tenant impact.
Treat it as the consumption layer, and the validation plan becomes clearer.
Workstream 5: Workload domains and Day-N sequencing
Not every workload domain has to be upgraded in the same core window.
That is useful, but it can also create drift if Day-N sequencing is not owned.
Workload-domain owners should have a separate plan for:
vCenter readiness
ESX host image readiness
NSX readiness
NSX Edge readiness
vSAN health
Maintenance windows
Application coordination
Capacity for remediation
Backup and rollback validation
Post-upgrade health checks
The fleet owner should maintain visibility across Day-N execution, but workload-domain owners remain accountable for the local execution.
A simple Day-N ownership model looks like this:
The important point is that Day-N does not mean “someone will handle it later.”
It means the work has a separate execution window with clear ownership.
Upgrade gates to add to the runbook
A VCF 5.2.x runbook may have been mostly product-focused. A VCF 9.1 runbook should have operating-model gates.
Gate 1: Fleet readiness
Confirm:
VCF Operations path is understood.
VCF Management Services prerequisites are ready.
DNS and IP ranges are available.
License service process is understood.
Software depot access is validated.
Cloud Proxy and collector behavior is planned.
Fleet lifecycle workflows are ready.
Support and escalation paths are known.
Gate 2: Management domain readiness
Confirm:
SDDC Manager health is clean.
Management-domain prechecks are clean.
vCenter upgrade requirements are understood.
NSX readiness is validated.
ESX host remediation readiness is confirmed.
vSAN health is clean.
Temporary IP and network requirements are ready.
Backups and rollback paths are validated.
Gate 3: Identity and access readiness
Confirm:
Identity provider requirements are understood.
Identity Broker transition is planned.
Administrator access is tested.
Role mappings are known.
Break-glass access is documented.
Audit requirements are covered.
Certificate and password policies are validated.
Gate 4: Observability and logging readiness
Confirm:
Log migration or transition plan is documented.
Forwarding destinations are known.
Retention requirements are understood.
Dashboards and alerts are reviewed.
Cloud proxies and collectors are validated.
Security operations knows what changes.
Gate 5: Automation and consumption readiness
Confirm:
VCF Automation path is planned.
Projects and organizations are inventoried.
Catalog items are ranked by importance.
Custom workflows and integrations are known.
Tenant access validation is planned.
Day 2 actions are tested.
Cloud zones and placement logic are validated.
Gate 6: Day-N decommissioning readiness
Confirm:
Legacy components are not removed prematurely.
Migration dependencies are documented.
Data retention requirements are known.
Decommission approvals are assigned.
Monitoring has been updated.
Runbooks reference the new operating model.
These gates should be in the upgrade plan before the maintenance window.
Common mistakes to avoid
Practical RACI starter
Use this as a starting point for planning.
This table will need to be adjusted for each organization, but it gives the upgrade a better starting point than appliance ownership alone.
Conclusion: the upgrade is the forcing function
The VCF 5.2.x to 9.1 upgrade is the forcing function that exposes whether the organization still thinks in product silos or has moved to a private cloud operating model.
VCF Management Services changes the runbook because it changes the center of gravity.
Fleet lifecycle, SDDC lifecycle, software depot, licensing, identity, logging, operations, and automation are connected more tightly than they were in many VCF 5.2.x environments.
That does not mean one team owns everything.
It means the ownership model has to be explicit:
Fleet platform owns shared management services.
Instance owners own local execution.
Automation owners own consumption.
IAM and security own identity, access, and audit.
Observability owns signal quality and log continuity.
Network and IPAM own reachability.
Domain owners own workload-domain readiness and Day-N execution.
A technically successful upgrade can still fail operationally if those boundaries are unclear.
The practical goal is not just to get to VCF 9.1.
The goal is to get there with an operating model that can survive the next lifecycle event.
External References
VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guidehttps://blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide/
How to Upgrade to VMware Cloud Foundation 9.1https://blogs.vmware.com/cloud-foundation/2026/06/18/how-to-upgrade-to-vmware-cloud-foundation-9-1/
Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
VMware Cloud Foundation 9.1 Documentationhttps://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
Deploy VCF Management Services and License Serverhttps://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deploy-vcf-management-services.html
VCF 9.1 Upgrade Planning Tool Announcementhttps://blogs.vmware.com/cloud-foundation/2026/05/28/announcing-the-vmware-cloud-foundation-9-1-upgrade-planning-tool/
VCF 5.2.x to 9.1: The Fleet vs Instance Ownership Model
TL;DR The VCF 5.2.x to 9.1 upgrade is not just a component upgrade. It changes how teams should think about ownership. In…
The post VCF 9.1 Management Services and Aria: Turning the Upgrade into an Operating Model appeared first on Digital Thought Disruption.