Dr. Pranay Jha

Pick the wrong organization type and you do not tune it later, you rebuild. VM Apps and All Apps are not two skins on one engine. They are two architectures, and the choice front-loads consequences you live with for the life of the tenant: which Orchestrator you run, what workloads you can offer, and how many moving parts you maintain. This is the decision I see teams rush, then regret. So let us slow it down.

The two models, precisely

A VM Apps Organization is the VM-centric model. It is the one that feels like Aria Automation 8.x, scoped deliberately to virtual-machine use cases, and it can run on the Orchestrator that ships embedded in VCF Automation or point at an external one. If your self-service catalog is virtual machines and the templates around them, this is home.

An All Apps Organization is the new architecture, built on Kubernetes APIs, designed for container-native workloads alongside virtual machines. It is broader and more capable for modern application platforms, and it carries a hard requirement: it only works with an external Orchestrator. That single requirement is not a footnote. It means an extra appliance to deploy, patch, and back up, and it should weigh on the decision.

The comparison that matters

Strip away the marketing and the decision comes down to a handful of dimensions. Here they are side by side, in the order I actually weigh them.

Read that table top to bottom and a pattern appears. All Apps wins on capability and breadth. VM Apps wins on simplicity and familiarity. There is no row where one is strictly better; there is a row where each is better, and your environment decides which rows carry weight.

How to choose

Do not start from which sounds more current. Start from the workloads you actually offer and the Orchestrator you are prepared to run. The decision tree is short.

Choose VM Apps if

Your catalog is virtual machines and the services around them. Your team is coming from vRA or Aria Automation 8.x and you want the shortest path to a familiar, working platform. You want fewer components to operate, and the embedded Orchestrator covers your extensibility. This is the right default for the majority of enterprise self-service rollouts, and choosing it is not settling.

Choose All Apps if

You have a real, present requirement to offer container-native self-service, not a someday-maybe. You are building a developer platform where Kubernetes is a first-class citizen alongside VMs. And you are ready to deploy, patch, and back up an external Orchestrator as part of normal operations. If all three are true, All Apps is the right tool and the extra complexity is paying for capability you will actually use.

You are not forced to pick one

Here is the relief valve teams miss: a single VCF Automation deployment can host both organization types. You can run a VM Apps tenant for the business units that live on virtual machines and an All Apps tenant for the platform team that needs Kubernetes, side by side, under one provider. The decision is not a company-wide, one-way door. It is a per-tenant, per-use-case call, and treating it that way removes most of the pressure from getting it perfect on the first try.

The cost of switching later

The reason this decision deserves care is that switching an existing organization from one type to the other is not a setting, it is a migration. The org type determines the underlying architecture, so changing it means standing up a new organization of the other type and moving workloads, templates, catalog items, and identity mappings across. There is no in-place flip. That is why I treat the org type as a design-time decision with the same weight as the tenant boundary itself.

What is actually tied to the org type: the Orchestrator model, the workload types you can offer, and the shape of the catalog and extensibility your tenants build on top. None of those are trivial to redo. A tenant that has spent six months building catalog items and day-2 actions on a VM Apps organization does not casually move to All Apps; it rebuilds, retests, and re-onboards its users, and someone has to explain the downtime. De-risk it by starting narrow: stand up the org type you are confident about for the workloads you have today, keep the first tenant small, and prove the model end to end before you scale users onto it. If there is genuine uncertainty about whether containers are coming, do not hedge by picking All Apps early. Pick VM Apps for the VM workloads now and add an All Apps tenant when the container requirement is real. Adding a tenant is cheap. Converting one is not.

Getting the tenancy around the choice right

The org-type choice does not live in isolation. It sits inside the provider and tenant model from Part 1, and the two decisions interact. A provider organization can create tenants of either type, so your provider design does not force your hand, but each tenant’s identity source, networking, and resource boundaries attach at the tenant level and below. Get those wrong and the org type barely matters, because the tenant is mis-scoped regardless of which architecture sits under it.

The first thing I validate when designing around the choice: does each tenant map to a real ownership and billing boundary, and does its org type match the workloads that boundary actually runs. A shared-services tenant that hosts platform tooling might justify All Apps. A finance business unit that runs packaged applications on virtual machines almost never does. Drawing those lines by workload, not by org-chart politics, is what keeps the design clean a year later. The mistake teams make is letting the more exciting org type set the standard for everyone: one platform team wants All Apps, so the architecture meeting decrees every tenant will be All Apps for consistency, and now four VM-only tenants carry an external Orchestrator dependency and a steeper learning curve for no benefit.

Before you create a single organization, run a short checklist: list every tenant, name the workloads each runs today and over the next year, mark which genuinely need container-native self-service, and confirm whether you can operate an external Orchestrator for the ones that do. That one page settles the org-type question for the whole estate in an afternoon, and it is far cheaper than discovering the answer one rebuilt tenant at a time.

The Verdict

Default to VM Apps. For VM-centric self-service and any team arriving from vRA or Aria Automation 8.x, it is the right starting point: familiar, simpler to operate, and complete for the job. Choose All Apps when you have a concrete, funded requirement for Kubernetes-native self-service and you are ready to run an external Orchestrator as a first-class component. And because one VCF Automation can host both, you do not have to bet the whole platform on a single answer; assign the model per tenant. The only wrong move is choosing All Apps for prestige, then maintaining an external Orchestrator for tenants that only ever asked for a virtual machine. Pick from the workload in front of you, not the architecture that photographs well.

Next we get hands-on: deploying and enabling VCF Automation through Fleet Management. For the platform context, see VCF 9 Multi-Instance Fleet Management. Are you leaning VM Apps, All Apps, or both? Tell me where you landed and why in the comments.

References

• VCF Automation 9 VM Apps Organization (Brock Peterson)
• VCF Automation 9: External VCF Operations Orchestrator (vrealize.it)
• What’s New in VCF Automation (Broadcom TechDocs)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts