VMware's own datasheet describes VCF Automation, the product that used to be vRealize and then Aria Automation, as a self-service catalog, blueprints and infrastructure as code, governance policies, orchestration and extensibility, and cost visibility, all in one box. Most teams pricing a replacement look for one product that does all five. There isn't a good one, and the teams that move fastest stop looking for it.
This post splits vRA into the jobs it does and names the tool that does each job well, with what it costs as published on the vendor's site. We make Windmill, which covers some of these jobs and not others, so read it as a partisan post that tries to be precise about where we stop. It follows Size your vRO migration before you price it, which covers the other half of the estimate: how much of your vRO content you actually have to move.
Five jobs in one license
Read the datasheet with a migration in mind and vRA comes apart into five jobs:
- Provisioning: blueprints that describe machines, networks and Kubernetes resources, written in a visual editor or YAML.
- Configuration: what happens inside the machine after it boots, usually handed to a tool such as Ansible.
- Self-service and approvals: the catalog a requester picks from, its forms, and the policies that send a request to an approver.
- Orchestration: vRO workflows, now called VCF Operations orchestrator, and the event broker subscriptions that run them when something happens.
- Governance and cost: projects, quotas, placement policies, and cost estimates pulled from VCF Operations.
The datasheet lists Terraform and Ansible as integrations, and in many estates vRA was already calling them for the first two jobs. Those tools don't have to change. The jobs that leave with vRA are the third, fourth and fifth.
The short version
| Tool | Jobs it covers | What it leaves to something else | Public pricing |
|---|---|---|---|
| VCF Automation (for reference) | All five, on VMware Cloud Foundation | Nothing, if you stay on VCF | No. Sold only as a component of VCF, through Broadcom or a reseller (datasheet) |
| Terraform or OpenTofu CLI | Provisioning | Catalog, approvals, schedules, events, cost | No license fee for the CLIs |
| HCP Terraform | Provisioning, policy as code and a no-code catalog (Standard and Premium) | Anything that isn't a Terraform run, events, Day 2 jobs | Yes, per managed resource per month: Essentials $0.10, Standard $0.47, Premium $0.99, free up to 500 resources. Terraform Enterprise is contact sales (pricing) |
| Red Hat Ansible Automation Platform | Configuration, workflows with approval nodes, self-service portal, event-driven runs | Provisioning state, cost | No. Quote from Red Hat or a partner (pricing) |
| HPE Morpheus Enterprise | Catalog, multi-cloud provisioning, orchestration of Terraform, OpenTofu and Ansible, cost analytics | Little, it's the closest one-for-one swap | Partly. One AWS Marketplace contract is listed ($198,500 for 12 months, 1,000 workload entitlements, managed), other terms by private offer (listing) |
| ServiceNow Service Catalog | Request forms, approvals, CMDB | The work itself, and REST calls to other systems need Integration Hub | No. Packages are sold by custom quote (pricing) |
| AWS Service Catalog | Catalog and launch constraints for AWS, with CloudFormation and Terraform products | Anything on-premises | Yes, per API call, with 1,000 free calls per account, region and month (pricing) |
| Windmill | Orchestration, forms, approvals, schedules and event triggers, running Terraform, OpenTofu and Ansible as steps | Provisioning state, deployment inventory, cost management | Yes. Community Edition is free to self-host. Self-hosted Enterprise is $20 per seat per month plus $50 per month for each standard 2 GB worker, with a calculator (pricing) |
Prices as published on each vendor's site, checked on 2026-11-01. HPE's own product pages didn't load for us, so the Morpheus figure comes from Morpheus Data's AWS Marketplace listing.
Provisioning: Terraform or OpenTofu
If your blueprints already call Terraform, or you can rewrite them as modules, this job is solved and has been for years. The vSphere provider manages virtual machines on vCenter, and the same module style covers the public clouds you also run. OpenTofu is the open source fork, under the Linux Foundation.
The CLI alone isn't a vRA replacement, though. It has no catalog, no approvals and nothing that runs on a schedule or an alert. HCP Terraform adds some of that: no-code provisioning lets someone deploy a module from a form without writing configuration, and Sentinel or OPA policies gate the plan. Both are on the Standard and Premium tiers. It's also one of the few rows in the table with a per-unit price list, which makes it easy to model. What it won't do is run the steps around the Terraform run: the IPAM lookup before, the ticket update after, the patch window next month.
Configuration: Ansible Automation Platform
If your estate is mostly Ansible, Red Hat Ansible Automation Platform is a strong replacement for more than configuration. Automation controller chains job templates into workflows, and a workflow can pause on an approval node until someone approves or denies the next step. The self-service automation portal, built on Red Hat Developer Hub and Backstage, turns job templates into forms that people without Ansible skills can run. Event-Driven Ansible runs playbooks from events.
The catch is the same as Terraform's in reverse. Everything is shaped like a playbook, so provisioning goes through Terraform anyway, and logic that isn't host configuration (calling an API, branching on a CMDB lookup) ends up as a module or a shell task. Red Hat doesn't publish list prices.
The closest swap: HPE Morpheus Enterprise
If what you want is another cloud management platform, with a catalog, multi-cloud provisioning, policies and cost reports in one product, Morpheus is the category match. Its AWS Marketplace listing describes provisioning of VMs, containers and multi-tier apps from a central catalog, orchestration of Terraform, OpenTofu, CloudFormation, Pulumi and Ansible, and cost analytics with right-sizing and budget policies, across hypervisors, public clouds and Kubernetes.
Windmill isn't that. We have no deployment inventory, no cost reports and no showback, and if those are why you bought vRA, Morpheus or staying on VCF is the honest answer.
The catalog you may already own: ServiceNow
Many vRA catalogs were never the front door. Requests started in ServiceNow, and vRA did the work. If that's your setup, the catalog and the approvals can stay where they are: a catalog item with a Workflow Studio flow and an Ask for Approval step already covers job three.
ServiceNow doesn't do the work, though. Something still has to clone the VM, run the playbook and close the ticket, and calling that something from a flow with a REST step requires Integration Hub, a separate subscription. A business rule can also call a webhook directly.
Leaving on-prem: the cloud's own catalog
Some teams use the renewal to leave vSphere for a public cloud. VCF Automation is moving the other way: in 9.1.1 its native AWS, Azure and GCP endpoints are deprecated and disabled by default, and VMware says the feature will be discontinued in a future release.
On AWS, Service Catalog gives you portfolios of CloudFormation and Terraform products with launch constraints, priced per API call. It covers the catalog for that one cloud. It doesn't cover anything left in the data center, and Terraform products don't yet support template constraints or service actions.
Orchestration: where Windmill fits
The job nobody else in this list takes over cleanly is vRO: the workflows, the scheduled runs and the event subscriptions that glue provisioning, configuration and the ticket together. That's what Windmill does.
A Windmill flow is a sequence of scripts in TypeScript, Python, PowerShell, Bash or Ansible. Terraform and OpenTofu run as the CLI from a script on a worker where the binary is installed, with state in your own backend, so Windmill sits on top of the tools in the previous sections instead of replacing them.
The parts that map to vRA:
- Self-service: every script and flow gets a generated form from its inputs, and you can build an app on top when a form isn't enough.
- Approvals: an approval step suspends the flow until the approvers resume it. Adding a form to the approval page is an Enterprise Edition feature.
- Schedules and events: schedules and webhooks are in every edition, so a ServiceNow business rule or an Alertmanager alert can start a flow. Kafka, NATS and SQS triggers are self-hosted Enterprise.
- Network reach: workers run where vCenter is reachable. Agent workers, which connect out over HTTP from isolated segments, are Enterprise.
What it leaves out is the list from the Morpheus section: no record of deployed machines (that lives in Terraform state, a CMDB or NetBox), no cost reports, no blueprint canvas. The flows themselves are files in Git, and the core is open source under AGPLv3, so the workflows you move out of vRO don't move into another closed format.
Three combinations that work
- One platform, cost reports included: Morpheus, or stay on VCF and negotiate. Port the vRO workflows only if the new platform can't run them.
- An Ansible shop: Ansible Automation Platform for configuration, the portal and approvals, Terraform for provisioning. It gets awkward where the logic isn't a playbook.
- Code you own: Terraform or OpenTofu for provisioning, Ansible for configuration, ServiceNow or Windmill forms for intake, and Windmill for the workflows, schedules and events vRO ran. This is the combination our vRA replacement guide walks through.
Whichever you pick, the timeline is set by the renewal date, not the migration. Run the inventory on your vRO export first, so the number you multiply by is the workflows you actually have to move.
You can self-host Windmill using a
docker compose up, or go with the cloud app.