VCF 9.1 Management Services and Aria: Turning the Upgrade into an Operating Model
VMware News, virtual machine, vm, VMwareTL;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.
| Term | Practical meaning |
|---|---|
| VCF Operations | The fleet operations and lifecycle control surface for VCF 9.x operations. |
| VCF Automation | The automation, self-service, and consumption layer for infrastructure services. |
| VCF Management Services | The VCF 9.1 services layer that hosts management capabilities such as lifecycle services, depot, licensing, and related platform services. |
| Fleet lifecycle | The lifecycle capability used to coordinate management components across the fleet scope. |
| SDDC lifecycle | Lifecycle capability for SDDC and domain-level components. |
| Identity Broker | The VCF identity component used to broker SSO between VCF components and external identity providers or directory services. |
| Day-N work | Work that happens after the core upgrade window, such as workload-domain upgrades, migration tasks, validation, and decommissioning. |
| Operating-model gate | A 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:
| Responsibility | Accountable owner | Supporting teams |
|---|---|---|
| VCF Operations upgrade or deployment readiness | Fleet operations owner | Observability, network, security |
| VCF Management Services deployment readiness | Fleet platform owner | DNS, IPAM, security, network |
| License service readiness | Fleet platform owner | Licensing admin, procurement |
| Software depot access | Fleet platform owner | Security, network, offline repository owner |
| Cloud Proxy placement | Fleet operations owner | Network, instance owner |
| Lifecycle workflow readiness | Fleet platform owner | Instance/domain owners |
| Fleet health validation | Fleet operations owner | Observability, 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:
| Responsibility | Accountable owner | Supporting teams |
|---|---|---|
| SDDC Manager readiness | VCF instance owner | Fleet platform owner |
| vCenter upgrade readiness | Virtualization owner | Network, DNS, backup |
| ESX host remediation | Virtualization owner | Storage, app owners |
| NSX Manager readiness | NSX owner | Network/security |
| NSX Edge finalization | NSX/network owner | Instance owner |
| vSAN health | Virtualization/storage owner | Hardware support |
| Temporary IP and network validation | Network/IPAM owner | Virtualization owner |
| Backup and rollback readiness | Instance owner | Backup 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:
| Capability | Accountable owner | Supporting teams |
|---|---|---|
| Identity provider integration | IAM/security owner | Fleet platform owner |
| Identity Broker transition | IAM + fleet owner | Automation owner |
| Role and access validation | IAM/security owner | Platform owners |
| Certificate policy | Security/platform owner | PKI owner |
| Password policy | Security/platform owner | Operations |
| License service process | Fleet owner + licensing admin | Procurement |
| Log management transition | Observability owner + fleet owner | Security operations |
| Log forwarding and retention | Observability owner | Compliance/security |
| Audit evidence | Security owner | Observability/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:
| Responsibility | Accountable owner | Supporting teams |
|---|---|---|
| VCF Automation upgrade planning | Automation owner | Fleet platform owner |
| Project and organization validation | Automation owner | IAM/security |
| Catalog item validation | Automation owner | Application/platform teams |
| Blueprint or template validation | Automation owner | Virtualization/network |
| Custom workflow remediation | Automation owner | Integration owners |
| Approval policy validation | Automation owner + governance | IAM/security |
| Day 2 action testing | Automation owner | Platform teams |
| Cloud zone and placement behavior | Automation owner | Fleet/domain owners |
| Tenant access validation | Automation owner + IAM | Service 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 Guide
https://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.1
https://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.1
https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html - VMware Cloud Foundation 9.1 Documentation
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html - Deploy VCF Management Services and License Server
https://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 Announcement
https://blogs.vmware.com/cloud-foundation/2026/05/28/announcing-the-vmware-cloud-foundation-9-1-upgrade-planning-tool/
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.