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 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:

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:

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.

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:

Does the function affect local infrastructure execution?

If yes, treat it as instance or workload-domain ownership.

Examples:

Does the function define how users consume infrastructure?

If yes, treat it as automation and cloud-consumption ownership.

Examples:

Does the function control access, audit, or compliance?

If yes, treat it as shared governance ownership.

Examples:

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.