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.

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
• 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/

The post VCF 5.2.x to 9.1: The Fleet vs Instance Ownership Model appeared first on Digital Thought Disruption.