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 VCF 5.2.x, many operational responsibilities were still organized around product lanes and appliances: SDDC Manager, Aria Operations, Aria Suite Lifecycle, Aria Automation, Log Insight, Identity Manager, vCenter, NSX, and ESXi.
VCF 9.1 pushes the model toward a fleet-level management plane. That does not remove instance and workload-domain ownership. It changes the question from:
“Who owns this appliance?”
to:
“Is this a fleet-level responsibility, an instance-level responsibility, or a workload-domain execution responsibility?”
That distinction matters because VCF Operations, VCF Automation, VCF Management Services, identity, licensing, software depot, lifecycle, metrics, and logging now sit closer to a shared private cloud operating model.
The practical outcome is simple:
Fleet services need fleet ownership. Instance services need instance ownership. Workload-domain execution still needs domain owners. The upgrade works best when those lines are clear before the first precheck runs.
Ownership model at a glance
The easiest way to understand the shift is to separate scope from placement.
Some services may run inside or near the management domain, but their operational scope is broader than one domain. That is the part teams often miss. A service can be physically deployed in a management environment while still being accountable at fleet scope.
What to notice in the diagram: the fleet layer does not replace instance operations. It changes who owns the shared control plane. The local domain team still owns the infrastructure condition where the plan is executed. The fleet team owns more of the policy, sequencing, identity, licensing, depot, observability, and lifecycle context.
That is why the VCF 5.2.x to 9.1 transition can feel like an organizational change even when the upgrade steps are technically clear.
The 5.2.x ownership model most teams recognize
A typical VCF 5.2.x environment often has ownership boundaries that look something like this:
This model is not automatically wrong. It reflects how many environments grew over time.
The problem is that VCF 9.1 pulls several of those lanes into a shared management-services model. When that happens, appliance ownership stops being a clean answer. The owner of the old appliance may not be the right owner for the new fleet-scoped capability.
That is where confusion starts.
Scope and terminology guardrails
This article is not a step-by-step upgrade runbook. It is an ownership model for teams planning the move from VCF 5.2.x to VCF 9.1.
Use these terms carefully:
| Term | Practical meaning |
|---|---|
| VCF fleet | One or more VCF instances managed through shared fleet-level operations and lifecycle capabilities. |
| VCF instance | A VCF deployment boundary containing a management domain and optional VI workload domains. |
| Management domain | The domain that hosts core management components for a VCF instance. |
| VI workload domain | A workload domain used to run application or tenant workloads. |
| Fleet ownership | Accountability for shared management services, policy, identity, licensing, depot, lifecycle coordination, and fleet observability. |
| Instance ownership | Accountability for local VCF instance readiness, management domain health, and execution conditions. |
| Workload-domain ownership | Accountability for cluster, host, NSX, vSAN, workload, and maintenance-window readiness in a specific domain. |
| VCF Management Services | The VCF 9.1 management-services layer that hosts lifecycle and management capabilities such as fleet lifecycle, SDDC lifecycle, software depot, and license services. |
| Unified Management Services layer | A useful mental model for explaining the VCF 9.1 shift, but the implementation language you will see in workflows is VCF Management Services. |
The most important guardrail is this:
Placement is not ownership.
A component may live in or near the management domain, but if it governs multiple domains or instances, it should be treated as a fleet responsibility.
Assumptions
This model assumes a starting point of VCF 5.2.x and a target of VCF 9.1.
It also assumes the environment has some combination of SDDC Manager, vCenter, NSX, ESXi, Aria Operations, Aria Automation, Aria Operations for Logs, Aria Operations for Networks, Aria Suite Lifecycle, or VMware Identity Manager.
The exact upgrade path can vary by starting version, hardware, compatibility, existing Aria Suite footprint, remediation needs, and whether all management components are present. That is why this article focuses on ownership and operating model alignment instead of replacing the official upgrade guide.
In most enterprise environments, the teams involved look something like this:
| Team | Typical concern |
|---|---|
| VCF platform team | Fleet, lifecycle, SDDC Manager, VCF Operations, VCF Management Services |
| Virtualization team | vCenter, ESX hosts, clusters, vSAN, remediation |
| NSX / network virtualization team | NSX Managers, NSX Edge, routing, firewalling, overlays |
| Automation team | VCF Automation, projects, catalog, workflows, extensibility |
| Observability team | Logs, metrics, dashboards, alerting, forwarding |
| IAM / security team | Identity provider, roles, audit, certificates, password policy |
| Network / IPAM team | DNS, IP allocation, routing, firewalls, management network reachability |
| Licensing / procurement | Entitlements, license service process, renewals |
The upgrade will cross all of those lines. The ownership model should be written before the maintenance window, not discovered during it.
The core shift: from appliance ownership to scope ownership
The largest operating-model change is not the rename from Aria to VCF-branded components. The larger change is that responsibilities should now be assigned by scope.
In VCF 5.2.x, it was common to say:
“We own Aria Operations.”
“We own Log Insight.”
“We own Aria Suite Lifecycle.”
“We own SDDC Manager.”
Those answers are no longer enough. In VCF 9.1, the better question is:
“Does this function operate at fleet scope, instance scope, workload-domain scope, or consumption scope?”
That gives you a cleaner model.
| Capability | 5.2.x mental model | 9.1 ownership model |
|---|---|---|
| Lifecycle planning | SDDC Manager-led, often domain-by-domain | Fleet lifecycle governs sequence and policy; instance owners validate execution readiness |
| Aria Operations | Monitoring product owner | VCF Operations becomes part of the fleet operating surface |
| Aria Suite Lifecycle | Tool owner for Aria products | Transitional role; lifecycle responsibility moves into VCF Operations and VCF Management Services workflows |
| Licensing | Tool-specific, vCenter, or VCF admin concern | Centralized fleet governance with license service visibility |
| Identity | Often vIDM / Workspace ONE Access ownership | Identity becomes part of the VCF management and fleet access model |
| Logging | Log Insight or Aria Operations for Logs owner | Logging becomes part of the VCF Operations / VCF Management Services model |
| Software depot | SDDC Manager or local repository concern | Shared depot responsibility tied to VCF management services |
| Automation | Aria Automation team | VCF Automation becomes a fleet-consumption and provider-management concern |
| vCenter / ESX / NSX upgrades | Virtualization and NSX owners | Still instance/domain execution owners, but sequenced through fleet lifecycle policy |
This is the practical translation of the architecture change.
You are not just upgrading components. You are moving accountability from isolated product lanes into scope-based operating boundaries.
Decision criteria for ownership
When ownership is unclear, use these questions.
Does the function apply across more than one domain or instance?
If yes, treat it as fleet-level ownership.
Examples:
| Function | Ownership |
|---|---|
| Fleet lifecycle policy | Fleet platform owner |
| Certificate and password governance | Fleet platform + security |
| License service | Fleet platform + licensing admin |
| Software depot | Fleet platform + security/network |
| Centralized identity pattern | Fleet platform + IAM |
| Centralized observability standards | Fleet platform + observability |
| VCF Operations health | Fleet operations owner |
| VCF Automation provider model | Automation owner + fleet owner |
Does the function affect local infrastructure execution?
If yes, treat it as instance or workload-domain ownership.
Examples:
| Function | Ownership |
|---|---|
| ESX host remediation | Virtualization / domain owner |
| vCenter upgrade readiness | Virtualization / instance owner |
| NSX Manager readiness | NSX owner |
| NSX Edge upgrade sequencing | NSX / network owner |
| vSAN health | Virtualization / storage owner |
| Cluster maintenance windows | Domain owner |
| Management network reachability | Network / instance owner |
| Backup and rollback readiness | Instance owner + backup owner |
Does the function define how users consume infrastructure?
If yes, treat it as automation and cloud-consumption ownership.
Examples:
| Function | Ownership |
|---|---|
| VCF Automation projects | Automation owner |
| Catalog items | Automation owner |
| Blueprints / templates | Automation owner |
| Day 2 actions | Automation owner |
| Approval policies | Automation owner + governance |
| Tenant access | Automation owner + IAM |
| Placement behavior | Automation owner + fleet/domain owners |
Does the function control access, audit, or compliance?
If yes, treat it as shared governance ownership.
Examples:
| Function | Ownership |
|---|---|
| Identity provider integration | IAM / security owner |
| Identity Broker transition | IAM + fleet owner |
| Role assignments | IAM + platform owner |
| Audit logs | Security + observability |
| Password policy | Security + platform owner |
| Certificate policy | Security + platform owner |
| Compliance evidence | Security + platform owner |
These categories are not meant to create silos. They are meant to clarify who is accountable when something breaks.
What the fleet owner should own
The fleet owner is accountable for the shared private cloud management plane.
In some organizations, this is the VCF platform team. In others, it may be a private cloud engineering team, cloud foundation team, or platform operations team.
The name matters less than the accountability.
A practical rule:
If the decision changes how the private cloud is governed across domains or instances, the fleet owner is accountable.
What the instance owner should still own
The instance owner remains accountable for the health and readiness of the local VCF instance.
That includes the management domain and any workload domains inside that instance.
The instance owner should own:
- Local management domain readiness
- SDDC Manager health
- vCenter health and upgrade prerequisites
- ESX host remediation readiness
- NSX Manager and NSX Edge readiness
- vSAN and storage health
- Workload-domain maintenance windows
- Local DNS and management network reachability validation
- Backup and rollback readiness
- Capacity for upgrade operations
- Change coordination with application owners
A practical rule:
If the decision changes a specific domain, cluster, vCenter, NSX instance, host group, datastore, or maintenance window, the instance or domain owner is accountable.
What the automation owner should own
The automation owner still matters, but the boundary changes.
In VCF 5.2.x, the Aria Automation team may have operated as a mostly separate platform group. In VCF 9.1, VCF Automation sits closer to the fleet consumption model. It is not just a portal. It represents how infrastructure is requested, governed, and consumed.
The automation owner should own:
- VCF Automation upgrade planning
- Project and organization model
- Catalog and blueprint validation
- Extensibility and workflow dependencies
- Tenant access behavior
- Approval policies
- Day 2 action behavior
- Integration testing
- Cloud zone and placement behavior
- Custom code remediation
- Consumption-facing validation after platform upgrade
A practical rule:
If the decision changes how users request, govern, or automate infrastructure consumption, the automation owner is accountable.
But the automation owner should not independently define identity, license, provider, or fleet governance patterns. Those are shared with the fleet owner and IAM/security owner.
The clean ownership sentence
A useful way to explain the VCF 9.1 operating model is this:
The VCF platform team owns the fleet. Domain teams own local execution. Automation teams own consumption. Security owns identity and governance. Network teams own reachability. Observability owns signal quality.
That sentence is simple, but it changes how the upgrade is planned.
It tells you who must be in the room before the maintenance window. It tells you who owns failed prechecks. It tells you who decides whether a broken service is a fleet problem, an instance problem, a network problem, an identity problem, or an automation problem.
Most importantly, it prevents the upgrade from becoming a rename exercise.
Operational implications
Build the RACI before the upgrade schedule
Do not build the upgrade calendar first and then ask who owns each issue.
Start with ownership.
The RACI does not need to be bureaucratic. It needs to be clear enough that failed prechecks do not turn into a conference-call scavenger hunt.
Treat DNS, IPAM, and certificates as platform prerequisites
VCF 9.1 puts more pressure on management-plane consistency.
That means DNS, IP allocation, certificate validity, password policy, time synchronization, routing, and firewall rules cannot be treated as side tasks. They are prerequisites for the management layer.
The fleet owner may not own DNS or PKI directly, but the fleet owner should own the requirement that those dependencies are validated before the window.
Separate governance from execution
Fleet ownership does not mean the fleet team remediates every host or fixes every NSX Edge.
It means the fleet team owns the platform-level plan, policy, and sequencing.
Domain owners still execute local work. Network owners still validate reachability. Security still validates identity and audit requirements. Automation still validates catalog and integration behavior.
VCF 9.1 makes those dependencies more visible.
Do not decommission legacy components by instinct
Some legacy-looking components may be transitional by design. Others may need migration or Day-N decommissioning. The fact that a tool looks replaced does not mean it can be powered down immediately.
Build decommissioning into the operating model as a planned activity.
The right question is not:
“Is this old?”
The right question is:
“What capability has replaced it, what data or configuration must move, and who signs off on decommissioning?”
Common ownership mistakes
Conclusion: ownership becomes architectural
The VCF 5.2.x to 9.1 transition is a technical upgrade, but the fleet model makes it an ownership change.
The old model was appliance-oriented. The new model is scope-oriented.
Fleet services need fleet ownership. Instance services need instance ownership. Automation consumption needs automation ownership. Identity, licensing, logging, certificates, and depot strategy need explicit governance.
That is the practical reason the VCF 9.1 management layer matters.
It is not just where services run.
It is where accountability moves.
The next article in this series should turn that ownership model into a practical upgrade operating model: workstreams, gates, RACI, and Day-N cleanup after the VCF Management Services transition.
