A client migrating an existing Aria Automation 8.x deployment into VCF 9 asked me why nobody flagged this org model decision during their initial scoping call with another firm. Fair question. The honest answer is that it's easy to miss entirely, because for anyone upgrading an existing environment, the tool makes the decision for you and nothing looks different afterward.
Existing Aria Automation organizations get auto-mapped into what VCF 9 calls a VM Apps organization during upgrade. No disruption, no reconfiguration, no prompt asking which model you'd prefer. The environment comes up looking and behaving exactly like it did before. That's precisely why the decision gets skipped over in most migration conversations — it doesn't register as a decision the first time it happens to you. It just feels like an upgrade that went well.
Two Models, One Quiet Default
VCF Automation 9 supports two organization types. VM Apps is the classic experience — the same VM provisioning model Aria Automation customers have used for years, running against Cloud.vSphere.Machine resource schemas and the event topics that have always driven that workflow. No vSphere Supervisor requirement. No NSX Supervisor dependency. It's designed specifically so existing customers land softly.
All Apps is the newer model, and it's the one Broadcom is actively steering everyone toward. It's built on vSphere Supervisor underneath, and it provisions VMs, Kubernetes workloads, and containers through the same API. It ships as the default organization type in a clean deployment, and it comes with a broader set of built-in cloud services — Harbor, a Secret Store, database provisioning, and more — that VM Apps simply doesn't have. Creating an additional VM Apps organization from the UI, by contrast, requires enabling a feature flag called Classic Tenant Creation, which is off by default and which most people scoping a fresh VCF 9 deployment never encounter.
An upgrade that preserves everything you had is a good upgrade. It's also the exact scenario where a structural decision slips past everyone involved, because nothing appears to have been decided at all.
The vCenter Binding Nobody Mentions
The cost shows up later rather than immediately. In VCF 9.0, a given vCenter Server can only be associated with one organization type at a time. Land in VM Apps because that's where the upgrade put you, then decide six months in that you want Kubernetes workloads or the built-in services All Apps provides, and you're not flipping a setting. You're standing up a separate vCenter and NSX instance to host the new organization type.
That's a workload domain. Not a settings change, not a feature toggle, not something a support ticket resolves in an afternoon. It's new infrastructure, provisioned and integrated, because the two organization types can't currently share the same underlying vCenter in a 9.0 environment.
- Whether this is a clean VCF 9 deployment (All Apps by default) or an upgrade from existing Aria Automation (auto-mapped to VM Apps).
- Whether Kubernetes, containers, or Supervisor-based workloads are on the roadmap for this environment at any point — not just at launch.
- Whether ServiceNow or another ITSM integration is part of the current or planned operational model.
- Which VCF version the environment is targeting — 9.0's strict one-vCenter-per-org-type limitation, or 9.1's bimodal option.
The ServiceNow Wrinkle
There's a narrower gotcha specific to anyone running ServiceNow for ITSM or catalog fulfillment. The standard ServiceNow plugin path is built around VM Apps organizations. If ITSM integration matters to your operational model and you jump into All Apps without checking that first, the discovery usually happens mid-project, not during planning — which is a worse time to learn it.
What Changes in VCF 9.1
VCF 9.1 introduces a bimodal consumption model that lets both organization types share the same vCenter and NSX instance, activated through a feature flag rather than requiring separate infrastructure. Broadcom's stated intent for this is specifically to smooth the transition path for existing Aria Automation customers — run VM Apps and All Apps side by side on shared infrastructure while gradually shifting workloads to the modern model instead of committing all at once. Genuinely useful if the target environment is on 9.1 or headed there. It doesn't help much if the decision is being made today against a 9.0 deployment.
Is Kubernetes or container workload support a real requirement in the next 12–18 months, even if it isn't one today?
Does the ITSM or catalog integration strategy depend on ServiceNow, and if so, has the plugin's org-type requirement been confirmed against the current VCF version?
Is the target platform version 9.0, where org types require separate vCenter and NSX instances, or 9.1, where bimodal sharing is available?
If this is an upgrade rather than a greenfield build, has anyone explicitly confirmed the auto-mapped VM Apps organization is actually the right long-term fit — or did it just happen?
None of this makes VM Apps the wrong choice for most existing Aria Automation shops migrating forward — for a lot of environments it's exactly right, at least for now. The problem isn't the default. It's that the default gets set by an upgrade path rather than a conversation, and the two organization types don't share infrastructure cleanly enough on 9.0 to fix that decision cheaply once workloads are already running on top of it.