TL;DR · Key Takeaways
- VCF Automation is the product formerly named VMware Aria Automation, and before that vRealize Automation (vRA). Same lineage, new architecture.
- In VCF 9 it also takes over the multi-tenant cloud-provider role that VMware Cloud Director used to own. One product now covers enterprise self-service and provider-style multi-tenancy.
- You work in three services: Automation Assembler (author templates), Automation Service Broker (publish the catalog and govern requests), and VCF Operations Orchestrator (workflow extensibility).
- The model is provider organization, then tenant organizations, then projects. That provider/tenant boundary above projects is the big shift from vRA 8.x.
- The VCF 9 fork in the road: VM Apps organizations (VM-centric, like 8.x) versus All Apps organizations (Kubernetes-API-native, external Orchestrator required).
Looking for vRealize Automation in VCF 9? It is still here. It just answers to VCF Automation now, and the new name hides a bigger change than a fresh logo. The product you knew as vRA, then as Aria Automation, is now the self-service layer of VCF, and in version 9 it quietly absorbed VMware Cloud Director’s multi-tenancy as well. If your mental model stopped at vRA 8.x, parts of it are now wrong in ways that bite on day one, starting with how organizations work.
The name, and what it actually is
Three names in a handful of years: vRealize Automation, then VMware Aria Automation, now VCF Automation. The renames track ownership and packaging more than a ground-up rewrite each time, so much of your 8.x knowledge still carries. But VCF 9 is a real architectural shift, not just branding, and treating it as a logo swap is the fastest way to design something you regret.
What it is, plainly: the self-service cloud management product for VCF. Admins model infrastructure once, then users request workloads from a catalog without filing a ticket and waiting three days. The part that surprises returning vRA users is the scope. In VCF 9, VCF Automation also takes over the multi-tenant cloud-provider role that VMware Cloud Director held, so a single product now spans both enterprise self-service and provider-style multi-tenancy. That is why the org model looks different the moment you log in.
The three services you actually work in
VCF Automation is not one screen. It is three services with different jobs and different users, and knowing which one you are in saves a lot of confusion. The good news for vRA veterans: the names barely changed.
| Service | What it does | Who lives in it |
|---|---|---|
| Automation Assembler | Model infrastructure and author VMware Cloud Templates (blueprints), cloud accounts, zones, mappings | Cloud admins and architects |
| Automation Service Broker | Publish templates and workflows as catalog items, add custom forms, govern requests | Admins to publish, end users to consume |
| VCF Operations Orchestrator | Run workflows for extensibility, custom logic, and day-2 actions (was Aria Automation Orchestrator / vRO) | Automation engineers |
Provider, tenant, project: the mental shift
This is the part that trips up vRA veterans. In 8.x you thought in projects under a single organization. VCF 9 adds a boundary above that. A provider organization owns the infrastructure and creates tenant organizations. Inside each tenant, projects scope who can deploy, what they can deploy, and how much. That provider/tenant split is the VMware Cloud Director tenancy model folded into the product, and it is not optional furniture you can ignore.
Why you should care before you build anything: the provider/tenant boundary is expensive to refactor later. Resources, identity sources, and networking attach at specific levels, and moving a workload estate across a tenant boundary after the fact is migration work, not a setting change. The first thing I check on a new VCF Automation design is whether the team has drawn the tenant boundaries on purpose or by accident.
VM Apps vs All Apps organizations
This is the single most VCF-9-specific decision in the product, and it is one you make early. VCF Automation 9 introduces two organization types, and they are not just presets. They are different architectures.
| Dimension | VM Apps Organization | All Apps Organization |
|---|---|---|
| Model | VM-centric, close to Aria Automation 8.x | New Kubernetes-API-based architecture |
| Orchestrator | Embedded or external | External Orchestrator required |
| Best for | VM-first estates, familiar 8.x experience | Container-native and mixed VM plus Kubernetes |
| Moving parts | Fewer | More, plan for the external Orchestrator |
My recommendation: if your world is virtual machines and you want the experience closest to Aria Automation 8.x, start with a VM Apps Organization. Choose All Apps only when you genuinely need the container-native, Kubernetes-API model and you are ready to run and maintain an external Orchestrator. The mistake teams make is picking All Apps because it sounds more current, then carrying the extra moving parts for a workload mix that never needed them. Pick All Apps for a real container requirement, not for prestige.
Where it sits in VCF 9
VCF Automation is not a standalone OVA you deploy and patch on its own anymore. It is deployed and lifecycle-managed through Fleet Management, the VCF Operations and Fleet Management appliance that runs on the management domain, and it integrates with SDDC Manager, vCenter, and NSX underneath. Its install, patching, and upgrade ride the VCF fleet lifecycle.
What breaks if you miss this: your old vRealize Suite Lifecycle Manager runbooks no longer apply. The operational model moved under the VCF umbrella, so you plan capacity, upgrades, and backups as part of the fleet, not as a separate product island. For the infrastructure side of that picture, see my VCF 9 fleet management walkthrough, and for the wider product context, VCF Automation in VCF 9 Explained.
Worked example
Picture a modest provider setup: one provider organization, three tenant organizations (say, two business units and a shared services tenant), and four projects inside each tenant for dev, test, staging, and prod. That is 12 projects, each with its own members, roles, and resource limits, and a default 30-day lease on requested workloads to keep sprawl in check. None of that fits the single-org vRA 8.x mental model. Sketch the provider and tenant boundaries first, then the 12 projects drop in cleanly. Sketch the projects first and you will redraw the tenants twice.
Migrating from vRA or Aria Automation 8.x
Most teams reading this are not starting clean. They are carrying a vRA or Aria Automation 8.x estate and want to know how much survives the move to VCF Automation. The honest answer: the skills and the content survive, the structure does not. That split is worth understanding before you plan a single import, because it tells you where the real work is.
What carries over
Your investment in templates, workflows, and catalog design mostly transfers. VMware Cloud Templates are still the blueprint format, so the YAML you wrote and the patterns you learned still apply. Orchestrator workflows carry over conceptually and often literally, because the engine is the same VCF Operations Orchestrator under a new name. ABX actions, custom forms, and the catalog mental model are all still here. If you spent years building a library of reusable templates and actions, that library is an asset, not a write-off, and it is the reason the move is an evolution rather than a fresh start.
What changes
The frame around that content is what moves, and it moves a lot. The provider and tenant model sits above your old single-org world, so you re-plan tenancy before you import anything of substance. Deployment and lifecycle run through VCF Fleet Management, which retires the separate vRealize Suite Lifecycle Manager process you used to babysit. The VM Apps versus All Apps decision has no 8.x equivalent at all, so you are making a structural call you never had to make before. And some API paths and integration endpoints shifted, so any automation that called the old endpoints needs re-pointing, which is exactly the kind of detail the API Part later in this series digs into. None of these are cosmetic; each one touches how you design, not just how you click.
What I tell clients planning the move: do not treat it as an in-place upgrade of a mindset. Build the provider and tenant structure fresh in VCF Automation, decide the org type from the workloads you run today, and then bring templates and workflows across into that new structure rather than trying to recreate your old org shape inside it. The content migration is the easy half and the part your existing skills already cover. The tenancy redesign is the half that decides whether the result is clean and durable or a museum of 8.x habits that you refactor under pressure a year later. Spend your planning time there.
My Take
Treat VCF Automation as vRA’s lineage running on VCF’s architecture. The catalog, templates, and Orchestrator you knew are all here, so the skills transfer. What changed is the frame around them: a provider and tenant model above projects, two organization types that are really two architectures, and a lifecycle that lives inside VCF Fleet Management. If you are coming from Aria Automation or vRA 8.x, the two decisions to get right before anything else are the tenant boundaries and the org-type choice. My default starting point for most teams: one provider, a VM Apps organization with the embedded Orchestrator, a couple of tenants, and a handful of projects, then grow from something correct rather than refactor from something convenient.
Next in this series we go under the hood of the architecture: Assembler, Service Broker, Orchestrator, and how a request actually becomes a deployment. If you are automating the infrastructure underneath VCF rather than the self-service product on top, that is a separate series, starting with the Automating VCF Series. Coming from vRA or Aria Automation 8.x? Tell me in the comments which part of your setup you expect to be hardest to carry over.
Previous: this is Part 1 (start of the series). Next: Part 2, the VCF Automation 9 architecture (coming soon). Up: VCF Automation Guide (pillar).
References
- What’s New in VCF Automation (Broadcom TechDocs)
- VCF Automation 9: External VCF Operations Orchestrator (vrealize.it)
- VCF Automation Datasheet (VMware)
About The Author
