Open Source VMware vRA Replacement: What Moves, What Stays, and How to Start

An open source VMware vRA replacement is an automation platform with a publicly licensed core that takes over what VMware Aria Automation (vRA) and its embedded vRealize Orchestrator (vRO) did: run the workflows, start them from schedules, events and catalog requests, and call the systems around them. The hypervisor is not part of the swap. vSphere stays where it is and gets called from the new workflows.

Most of a vRA estate does not move at all. ServiceNow, Terraform, Ansible, the CMDB, IPAM and the secrets vault predate vRA and will outlive it. What moves is the workflow engine and the glue code written for it, plus two decisions: where the catalog lives, and where the inventory of provisioned resources lives. This page covers what that engine has to do, what Kestra Open Source covers without a licence, and the free tools that count the work before anyone commits a budget.

TL;DR — Replacing vRA means replacing vRO’s workflow engine and deciding where the catalog and resource inventory go; VMware itself can stay. Kestra Open Source (Apache 2.0) runs the flows, triggers and Terraform/Ansible/ServiceNow calls; native vSphere plugins, Apps, Assets and RBAC are Enterprise. Size the work first with an export and the open-source Kestra Migration Assistant.

What a vRA replacement takes over, and what stays put

vRA and vRO are two products. vRA is the front end: the Service Broker catalog, cloud templates (blueprints), deployments and their lifecycle. vRO is the engine underneath, where workflows, actions, scriptable tasks in JavaScript, configuration elements and resource elements live. Both go when you migrate, but not everything they did moves to the new orchestrator.

A practical way to scope the replacement is to split the estate into six parts and give each one a verdict: replace (the new orchestrator takes it over), integrate (the incumbent stays and exchanges events with the orchestrator), keep (the incumbent stays and gets called) or retire (nothing replaces it).

Targets (vSphere, Nutanix, the public clouds, Kubernetes) get the keep verdict without debate. The difference between keep and integrate is direction: a kept tool is invoked and returns a result, an integrated one also originates events that start flows.

Why teams look for an open source option

Two pressures show up in almost every vRA exit, and both are about who controls the automation.

The first is price. vRA is no longer sold on its own; it ships inside VMware Cloud Foundation, licensed per core on subscription, so the automation bill tracks the size of the hypervisor estate rather than how much you automate. Gartner expects most VMware customers’ bills to grow by 200 to 500 percent at their next renewal, as reported by The Register. An engineer at a Fortune 500 industrial company put it plainly before replacing it: “We’re using Aria Automation, that’s a massive cost, the cost doesn’t justify it anymore.”

The second is the roadmap. What your automation can reach is decided by the vendor. In VCF Automation 9.1.1, native management of AWS, Azure and GCP resources is deprecated and disabled by default. Every integration outside VMware’s list is a library your team writes in vRO’s JavaScript dialect and then maintains, and the number of people who can read that code shrinks every year.

An open source core answers the question a proprietary platform cannot: what happens if the commercial relationship ends. If the workflow definitions are plain files in your Git repository and the engine is Apache 2.0, you can keep running it, read it and change it without asking anyone. That is the practical meaning of avoiding vendor lock-in in orchestration, and it is the test vRO failed.

Four tests for any open source vRA replacement

Several open source projects come up in vRA replacement searches. Most are strong in one slice of the estate, which is the same domain-lock problem in a new place. Ask four questions of each.

1. Does it replace the workflow engine, or one tool the engine called? Ansible configures, Terraform and OpenTofu provision, Rundeck runs runbooks. vRO called all of them.
2. Can it be started without a human? vRA workflows fire from schedules, lifecycle events, ITSM state changes and message buses, not only from a form.
3. How hard is it to leave? Where do definitions live, can you read them without the product, and is the scripting language one your team already knows?
4. Is your team the only one who needs it? The data team runs its own scheduler, and a CI pipeline is often doing provisioning that vRA only triggered.

Choose Ansible or Terraform to keep doing what they already do in your estate; they stay either way. Choose Temporal when the workflow logic belongs inside an application your developers own. Choose Kestra when you need the layer vRO was: one place that starts on an event or a request, calls Terraform, Ansible, vCenter and ServiceNow in order, waits for approvals and records what happened. The VMware Aria Automation alternatives page compares commercial platforms for the same job.

What Kestra Open Source covers, and where Enterprise starts

Kestra’s open-source edition is a production engine, not a demo. Every core vRO construct has an open-source equivalent, which means you can test the conversion pattern on real workflows without a licence or a sales call.

The open-source edition stops where a vRA migration crosses into governance and native hypervisor access. The VMware plugin and the Nutanix plugin (create, clone, snapshot, power-manage VMs without Terraform) are Enterprise, as are external secrets managers such as HashiCorp Vault, unit tests for converted flows, and Promote for moving flows between environments with a review. In open source, vSphere provisioning runs through the Terraform provider, which is how many vRA estates already did it. The open-source vs. Enterprise comparison lists the full split.

A vRA catalog item rebuilt as an open source flow

The most common vRA pattern is a catalog request that provisions a VM, configures it and closes the ServiceNow ticket. In vRA that is a cloud template, an event subscription and two or three vRO workflows. In Kestra it is one flow, and it runs on the open-source edition.

id: provision_vsphere_vm
namespace: infra.provisioning
description: Replaces a vRA catalog item and the vRO workflows behind it.

inputs:
  - id: vm_name
    type: STRING
  - id: size
    type: SELECT
    values: [small, medium, large]
    defaults: small
  - id: ritm_sys_id
    type: STRING
    description: sys_id of the ServiceNow request item that ordered the VM

tasks:
  - id: build
    type: io.kestra.plugin.core.flow.WorkingDirectory
    namespaceFiles:
      enabled: true
    tasks:
      - id: terraform
        type: io.kestra.plugin.terraform.cli.TerraformCLI
        beforeCommands:
          - terraform init -input=false
        commands:
          - terraform apply -input=false -auto-approve -var="vm_name={{ inputs.vm_name }}" -var="size={{ inputs.size }}"
          - terraform output -raw ansible_inventory > inventory.ini
        env:
          TF_VAR_vsphere_user: "{{ secret('VSPHERE_USER') }}"
          TF_VAR_vsphere_password: "{{ secret('VSPHERE_PASSWORD') }}"

      - id: configure
        type: io.kestra.plugin.ansible.cli.AnsibleCLI
        commands:
          - ansible-playbook -i inventory.ini configure.yml

  - id: close_request
    type: io.kestra.plugin.servicenow.Update
    domain: "{{ secret('SNOW_DOMAIN') }}"
    username: "{{ secret('SNOW_USERNAME') }}"
    password: "{{ secret('SNOW_PASSWORD') }}"
    table: sc_req_item
    sysId: "{{ inputs.ritm_sys_id }}"
    data:
      state: "3"
      work_notes: "VM {{ inputs.vm_name }} provisioned by Kestra execution {{ execution.id }}"

The Terraform configuration (main.tf with the vSphere provider and a remote state backend) and the Ansible playbook live as namespace files, so they are versioned with the flow. The three inputs replace the catalog form. A ServiceNow catalog item calls the flow through the API, or a webhook trigger, with the request item’s sys_id. Size variants that used to be separate blueprints are one SELECT input.

That is the open-source version. With the Enterprise plugin, the Terraform step becomes a vCenter clone task; the VMware provisioning blueprint with Ansible and ServiceNow registration shows that route end to end. Day 2 patterns have their own templates, such as event-driven VM cleanup from vCenter removal events for decommissioning or an SSL certificate expiry monitor for operational checks. Converting by pattern rather than by team is what keeps a migration from turning into hundreds of one-off jobs.

Size the migration with open source tools first

The first workflow count from a vRA estate is almost always alarming, because it assumes every workflow moves on its own. It rarely does. Three free tools and one sizing method get you to a defensible number before anyone installs a new platform.

Export the estate. Build Tools for VMware Aria, VMware’s own open-source toolchain, exports vRO workflows, actions, configuration and resource elements, plus vRA blueprints, subscriptions, catalog items and resource actions. The community project mcp-vcf-orchestrator wraps the same vRO and VCF Automation APIs as an MCP server, so an AI assistant can query the export directly. Both can also write, so run them with a read-only service account against a non-production instance first. Make sure the export carries last-execution dates.

Assess it on your machine. The Kestra Migration Assistant is a free command-line tool under Apache 2.0. It reads the vRO package and, optionally, the vRA export, and writes a migration brief you open in a browser: what each workflow does and what starts it, which systems it touches and whether a Kestra plugin already covers them, a recommendation per workflow (retire, merge into another, treat as a wrapper, convert, or rebuild) and a migration plan in waves ordered by risk and dependency.

pipx install kestra-migration-assistant
kestra-migrate init
kestra-migrate vra run ./my-estate

It runs locally and sends nothing to Kestra. Host names, IP addresses, accounts and credentials are replaced with placeholders before anything reaches a model, you choose the model (including one you host yourself), and it still produces an inventory and call graph with no model at all. When the export cannot answer something, such as how often a workflow runs, it writes the question to a file; you answer it and run the same command again. The tool stops at the plan.

Run the three passes. Whatever produced the inventory, three passes shrink it to the real work. The figures below are illustrative, not a benchmark; plug in your own export.

The integration libraries go too. Hand-written vRO clients for Infoblox, a load balancer or SolarWinds are deleted wherever a plugin covers the target, and only the business logic on top of them moves. Count them separately from the workflows.

Price it against the renewal. The migration is the investment and the vRA renewal you do not sign is the return. The licence already paid is sunk, so savings start at the renewal date, not at cutover. Work the wave plan backwards from the notice deadline and run the estimate twice, with low and high assumptions, labelling every rate as measured or estimated.

How teams have run the switch

Open source is where most evaluations start, not where every migration ends. Leaving vRA crosses the catalog, the inventory and the security review, and the teams that finished used both editions.

A Fortune 500 industrial company replaced VMware Aria Automation with Kestra to cut costs and secure hybrid cloud automation across IT and OT. Its security policy forbade a control plane spanning security zones, so it runs four isolated Kestra platforms for OT and one for IT. The company reports a 90% reduction in licensing cost versus Aria Automation and delivery that went from six months to six days. Ansible kept doing the heavy lifting, now called from flows, and ServiceNow stayed the system that tickets and incidents flow through.

Dataport, Germany’s public-sector IT services provider, standardized API-driven cloud orchestration on its private cloud, with a government-grade orchestration control plane. CAGIP, Crédit Agricole’s IT production arm, transformed its infrastructure operations and scaled workflows across more than 100 clusters, showing that the same engine scales past one team’s workflows.

Where to start

Start with real workflows, not a feature checklist.

1. Export the estate and run the Kestra Migration Assistant to get the brief and the three-pass count.
2. Install Kestra Open Source with Docker Compose and rebuild two or three workflows from the brief: one provisioning flow, one Day 2 action and one scheduled check, including at least one difficult workflow you would run in production.
3. Measure the hours each one took. That rate, multiplied across your pattern counts, is the migration estimate.
4. When the test needs the catalog, the inventory, native vSphere access or RBAC, run a proof of concept on Enterprise against the same workflows.

The vSphere estate keeps running throughout. Every wave stays reversible until the vRA side of it is switched off, and the VMware orchestration overview shows how flows call vCenter, snapshots and events once the engine underneath has changed.