The migration from VMware Cloud Foundation (VCF) 5.2.x to 9.1 represents a paradigm shift that goes far beyond a simple component upgrade. In previous versions, management was organized around products and appliances: SDDC Manager, Aria Operations, Aria Suite Lifecycle, vCenter, NSX, ESXi, among others. Each team used to own 'their' appliance, creating operational silos that hindered a holistic view of the environment. With VCF 9.1, the model evolves toward a fleet-level management plane, where the key question is no longer 'who owns this appliance?' but 'does this responsibility operate at fleet, instance, or workload-domain scope?'. This change has profound organizational implications that should be analyzed before starting any upgrade plan.
At Q2BSTUDIO, as a software and technology development company, we have accompanied numerous organizations in this transition. We know that clarity in the ownership model is as critical as the technical execution itself. Therefore, in this article we break down the new fleet vs instance ownership model, offering an original perspective based on our experience in custom software development, cloud integration, and intelligent automation projects.
The first common mistake is to think that the fleet is simply the old SDDC Manager renamed. In reality, the fleet layer in VCF 9.1 groups shared services such as lifecycle management, centralized identity, licensing, software depot, observability, and security policies. These services no longer belong to a specific domain; they operate at the instance or even multi-instance level. Therefore, the fleet owner must have a global vision and the ability to decide on policies that affect all domains. Conversely, the instance owner remains responsible for the health of the local management domain and workload domains, including preparation of ESXi hosts, vCenter, NSX, and vSAN.
An often overlooked aspect is that the physical location of a service does not determine its scope of responsibility. A service may be deployed within the management domain, but if its operational scope spans multiple instances, it should be treated as a fleet responsibility. This seemingly simple principle avoids confusion during maintenance windows. For example, if the new VCF Operations service (successor to Aria Operations) monitors the entire fleet, the observability team must coordinate with the fleet owner, not with the local vCenter administrator.
To ease the transition, we recommend building a RACI matrix (Responsible, Accountable, Consulted, Informed) before the upgrade, clearly assigning each function to a scope: fleet, instance, workload domain, or consumption. Some functions like certificate policy or identity management must be shared between the VCF platform team and the security team. Others, like ESXi host remediation, remain the responsibility of the local virtualization team. The automation owner (VCF Automation) now aligns with the consumption model: they define how users request and govern infrastructure, but they cannot independently decide on identity or licensing.
In this new ecosystem, cybersecurity takes a central role. Centralizing identities, certificates, and password policies at the fleet layer reduces the attack surface but also requires stricter governance. At Q2BSTUDIO we help companies integrate cybersecurity into their upgrade processes, ensuring that every change meets compliance standards and that access controls are consistently applied across all domains. Moreover, unified observability (logs, metrics, dashboards) becomes a fleet service, enabling earlier detection of security anomalies.
Artificial intelligence and AI agents also find their place in this model. VCF 9.1 incorporates predictive analytics and AI-driven automation for lifecycle management. For example, AI agents can recommend optimal maintenance windows or detect degradation patterns before they affect production. At Q2BSTUDIO we develop AI and AI agent solutions that integrate with VCF APIs to optimize upgrade planning and incident response. Similarly, integration with cloud platforms like AWS and Azure allows extending the hybrid fleet while maintaining unified identity and policy management. For organizations already operating in multicloud environments, our cloud AWS/Azure services facilitate secure connectivity between VCF and hyperscalers.
Another area where the ownership change is evident is license management and the software depot. In VCF 5.2.x, each team used to manage its own licenses (vCenter, NSX, Aria). In 9.1, the software depot and license service become fleet capabilities. This means the procurement team must coordinate with the fleet owner to ensure subscriptions are renewed on time and the software inventory is up to date. A common mistake is keeping duplicate licenses or not properly migrating entitlements, which can block the upgrade.
Business analytics and dashboards are also affected. With centralized logs and metrics in VCF Operations, information for business decision-making is more available than ever. BI teams can consume fleet performance data to build executive dashboards. At Q2BSTUDIO we offer BI/Power BI services that help transform VCF data into actionable insights, connecting data sources from multiple instances and domains.
To conclude, the fleet vs instance ownership model is not just a technical concept; it is an organizational decision that must be made before the first pre-check of the upgrade. Companies that invest time in defining who owns each function—fleet, instance, domain, consumption, security—drastically reduce the risk of incidents during migration. At Q2BSTUDIO, as a technology partner, we help design that ownership model and execute it with guarantees, combining our experience in custom software development, cloud, cybersecurity, and AI. The transition to VCF 9.1 is an opportunity to modernize not only the infrastructure but also the way it is governed.
