Migrating off VMware vRA and vRO

1. Why teams leave vRA, and what to move to

1.1 Why teams leave vRA: VCF 9, pricing and roadmap

Teams leave vRA for several reasons, and most have more than one in play. The two that come up most often are both about who controls your automation.

1.2 vRA alternatives: choosing what to move to

The decision, then, is what replaces the automation layer. Because vRA only ever reached VMware well, other teams found their own solutions along the way: the Kubernetes platform has its own operator, the data team runs its own scheduler, and a Jenkins pipeline is quietly doing the provisioning that vRA only triggers. Whatever you choose next has to account for all of that. If you are still building the shortlist, we compare the Aria Automation alternatives side by side, and look at what an open-source vRA replacement takes over and what stays put.

Here are three questions you should ask for every option on your shortlist, including Kestra:

1. Does it cover your whole infrastructure estate, or a different slice of it? Several of the obvious candidates are domain-locked in the same way vRA was. Ansible Automation Platform is strong at configuration. Spacelift and Terraform Cloud are strong at infrastructure as code. Rundeck is strong at operational runbooks. Temporal is strong at durable execution inside application code. If you pick one of them, you have replaced one boundary with another one, and the bolt-on tools stay where they are.

2. How hard would it be to leave? Ask where the workflow definitions live, whether you can read them without the product, whether the scripting language is one your team already knows, and whether you can run the thing yourself if the commercial relationship ends. vRO scored badly on all four, and that is a large part of why this migration is as much work as it is.

3. Is your team the only one who needs this? Step out of the infrastructure project for a moment. The data team has a scheduler. The application team has a CI pipeline doing more than CI. Somebody upstairs is asking the platform team for self-service. Those lines are blurring in most enterprises, and it is worth knowing now whether you are choosing a tool for the infrastructure team or a platform the others could also use. The answer may be that you only want to solve your own problem, and that is a legitimate answer. It is a worse outcome to discover in two years that you needed the broader one.

1.3 Why Kestra

Kestra’s answers to those questions are below:

It reaches the systems outside VMware’s boundary. vSphere and Nutanix, your cloud accounts, Kubernetes, your ITSM and CMDB, IPAM and DNS, Terraform and Ansible, your patch, backup and alert management tooling, and more than two thousand plugins besides. On-prem, across segmented network zones, and fully air-gapped with no outbound connectivity. Dataport, the IT provider for German public administration, runs its private cloud service portal this way because no SaaS option was available to it. Nothing in that list is a second-class integration reached through generic REST.

The workflow definitions stay portable. Flows are declarative YAML that can live in your own Git repository and go through normal pull-request review. Task code can use Python, Shell, PowerShell or another language that runs in a container. The core is open source, so the definitions do not depend on a proprietary editor or scripting dialect.

Other teams can use the same platform. The engine that runs infrastructure provisioning can also run data pipelines, application workflows and business processes, with the same RBAC, secrets and audit trail. A data team can use its own namespace instead of buying and operating a second scheduler. The infrastructure arm of Crédit Agricole runs automation across more than a hundred clusters this way, and describes the change as moving from fragmented automation to a single control plane that all their teams can manage.

Additionally:

• The economics are different. vRA is sold inside VCF and priced per core, so the bill tracks the size of your estate whether or not you automate more of it. Kestra Enterprise is licensed by instance, so adding workflows does not change what you pay. The Fortune 500 manufacturer that replaced vRA reported licensing costs 90% lower than Aria Automation.
• It orchestrates on top of what you already run. Terraform, Ansible, your ITSM, your CMDB, your IPAM and your secrets manager all stay and get called. Kestra does not ask you to re-express your infrastructure in its own object model the way blueprints did.
• 2,300+ plugins, and writing your own is documented. They cover the storage, network and compute systems vRO estates usually integrate with by hand, such as Infoblox, NetBox and SolarWinds, so the integration code your team wrote and maintained for vRO is replaced by a plugin someone else maintains. Extending it further is a normal engineering task rather than a professional services engagement.
• You can prove it before you buy it. Start by running the Migration Assistant on your exports to see what your migration involves, then prove it on real workflows. Section 8 covers how to do that, from an assessment on your own machine to a proof of concept run with us.

1.4 What your security and platform teams will ask

The questions that stop a migration usually come from the security review and the platform team rather than from the workflow inventory: where it runs, whether it can be air-gapped, how identity and secrets work, what the audit trail looks like, and how it behaves across segmented network zones. All of them are answerable, and none of them need to wait until the end. Dataport, which provides IT services to German public administration and had no SaaS option open to it, validated compliance on a self-hosted deployment in three weeks.

The deployment options handout covers where and how Kestra runs, and the security overview is what we share with review teams: compliance, deployment, where your data lives, and the security controls.

2. The migration in four stages

We have worked with enterprises leaving vRA, and the four stages below are the sequence that held up across them. You can run it with your own team, with us, or with a services partner.

The Kestra Migration Assistant for vRA does most of Stage 1 for you, on your own machine (see section 2.2 below). You can also talk to us before you start, and we will guide you through it. Sections 3 to 6 are one stage each.

2.1 Coexistence runs across Stages 3 and 4

vRA keeps running until each migration wave is verified and switched over. Plan for three consequences while both systems are live:

• Nothing gets frozen. The automation keeping the lights on continues to run, and continues to be changed, while the migration happens alongside it.
• The overlap costs infrastructure and people, not licence. The vRA licence you have already paid covers the overlap. What doubles up is the infrastructure and the team running both platforms at once.
• Every wave is reversible until you retire it. If a converted flow does not behave, the vRA version is still there. Nothing is cut over unverified.

This lets the migration run alongside normal operations without a change freeze across the full estate.

2.2 The Kestra Migration Assistant for vRA

The Kestra Migration Assistant for vRA is an AI-powered tool that does the reading for you. Its assessment is free and open source: point it at your vRO package and, if you have one, your vRA export, run one command on your own machine, and it works through Stage 1 in the order this guide describes. It sanitizes your export before anything reaches a model, and it also runs without one.

Here’s what its brief contains:

• A description of each workflow: what it does, what starts it (a catalog item, an event subscription, a schedule) and which systems it touches, with possible defects flagged for the owner.
• A recommendation for each workflow and action: retire, merge into another, treat as a wrapper, convert, or rebuild.
• A translation table: what each part of your estate becomes in Kestra, and which plugins cover your integrations, checked against Kestra’s plugin catalog.
• A migration plan in waves, each starting with its first of a kind.

In Stage 2, its brief helps you pick the workflows for your proof of concept. In Stage 3, the migration follows its waves. The conversion is the other half of the Migration Assistant, and we run it with you: tests are written from the original workflow before anything is converted, and each wave is verified before it reaches your environment (section 5.2).

Get the Kestra Migration Assistant for vRA

2.3 The three handouts

Three handouts go with this guide, each written to be passed to someone who will not read the whole thing:

• The capability map. One row per thing in the vRA and vRO world, what it becomes in Kestra, and which edition you need. Grouped by the six parts, with Direct and Redesign marking how each one converts.
• Deployment options. Where Kestra runs, backends, components, restricted network zones, HA and sizing, and the named gaps, including what an air-gapped install needs before anything starts.
• The security overview. Kestra Enterprise’s security and compliance posture, written for the reviewer: the SOC 2 Type 2 and GDPR audit, self-hosted and air-gapped deployment, where your data lives, and the controls for identity, secrets, audit, tenant isolation and transport.

2.4 What the migration costs, and what pays it back

A migration costs money up front, and the first estimate is usually alarming because it assumes every workflow moves on its own. In practice some workflows are already dead, many of the rest are near-duplicates of one another, and wrappers carry no conversion cost at all. What pays for the remaining work is the vRA and vRO renewal you do not sign. Section 7 shows how to work out both sides with your own numbers, and when the move pays for itself.

2.5 Four enterprise VMware estates, from assessment to completed migration

These four environments informed the approach in this guide. They differ in scale, security requirements and migration progress. They also show how teams have handled the catalog, resource inventory and systems that stay around the orchestration layer.

3. Stage 1 - Assess: Your Estate and Workflows

Stage 1 happens before Kestra is installed, and it has two steps. First, decide what happens to each part of the estate so you do not revisit the same architectural decisions for every workflow. Then inventory the workflows, remove what no longer needs to exist, and classify what remains into repeatable patterns.

At the end of Stage 1 you will know which workflows to start with in Stage 2 (Proof of Concept), which Kestra features and plugins those workflows need, and how to split the rest of your estate into migration waves.

The Kestra Migration Assistant for vRA does most of this for you. Run it on your exports and it produces the workflow list, the pattern breakdown and the waves, and asks for what it can’t find in them. The rest of this section is the method it follows, so you know what it’s doing and which calls stay with your team, and the method works just as well if you’d rather do it by hand. Many teams also talk to us first, and we guide them through it.

Get the Kestra Migration Assistant for vRA

Talk to our team

3.1 The Estate: Decide Once

3.1.1 The parts of your estate, and what to do with each

vRA and vRO are two different things, and this guide treats them separately. vRA is the automation product: the Service Broker catalog, blueprints, deployments and the lifecycle around them. vRO, VMware vRealize Orchestrator and now VCF Operations Orchestrator, is the workflow engine underneath it, where your workflows, actions and scriptable tasks live. Most teams just call it the orchestrator. Both products go when you migrate, but not everything they did moves to Kestra. Some of it, such as the catalog or the inventory, may stay in your ITSM.

Together they own the workflow engine and the pieces that support it: the Service Broker catalog in front of it, the schedules and lifecycle events that fire it, the blueprints it executes, and the deployment records it keeps. Everything else, the ITSM portal, Terraform and Ansible, the CMDB, the enterprise secrets vault, are separate, predate vRA in most cases, and will outlive it.

Before converting anything, decide what happens to each part of the estate. We describe it as six parts plus the targets they act on.

The distinction between keep and integrate matters when you plan the work, because integrating a system means agreeing on an interface with the team that owns it, while keeping one usually means nothing more than a plugin call.

These four verdicts sort into two motions with different owners and different timelines.

• Keep and integrate are about governing the tools that stay, which is mostly a list of things that do not change and the interfaces you agree with the teams who run them.
• Replace and retire are about replacing the glue that held those tools together, and that is the migration this guide describes.

Most of the six parts stay. The two decisions that change the target architecture are where the catalog lives and where the resource inventory lives.

3.1.2 The shape you end up with

Those decisions usually produce one of two target architectures. They differ in where the catalog and resource inventory live, and the table under each example shows where each part ends up.

Both shapes support the same transport choices for events (webhook or a message bus such as Kafka or RabbitMQ), and both can be deployed on-prem, across network zones or fully air-gapped. Those are deployment decisions rather than architecture ones, and the deployment options handout covers them.

3.2 The workflows: count the work

3.2.1 Inventory what has to move

Now that you’ve made decisions about the estate as a system, this section is where you find out how many vRO workflows you’ll actually need to migrate.

Start with an export rather than a manual count or a list assembled from people’s memory. You need two things from it: the content, and when each workflow last ran.

The content is a .package export from the vRO client, holding the workflows, actions, configuration elements and resource elements. It is also what the Kestra Migration Assistant for vRA reads. If vRA starts your workflows, export its content as well.

When each workflow last ran is not in a .package, and it is what the retirement decisions rest on. There are three practical ways to get it, and each also gives you a fuller inventory:

The first count may be large. Workflows that have not run in twelve months are candidates for retirement, and in the estates behind this guide that group is usually 10 to 20 percent of the list.

Treat the workflows that ran in the last year as in scope until an owner confirms otherwise. The next two steps reduce the work by consolidating duplicates and separating wrappers from workflows that contain their own logic.

3.2.2 Rationalize

Review the inventory in three passes:

• Retire what nobody runs. Your export includes usage data. Workflows that have not executed in a year, or ever, are candidates for retirement rather than migration. Some of them are genuinely dead, some are annual processes, and only the people who own them can tell the difference.
• Group near-duplicates. Teams accumulate variants: the same provisioning workflow copied once per environment, per business unit, or per requester type, differing only in a few hard-coded values. In Kestra these collapse into one flow with inputs.
• Separate the workflows that hold logic from the ones that are wrappers. Some vRO workflows do the work themselves. Others exist only to call something else: an Ansible job, a script on a jump box, a pipeline, a homegrown tool, or a single integration Kestra has a plugin for, such as a ServiceNow request, a Teams message or an Infoblox record. Wrappers do not need rewriting. Kestra calls the same thing the wrapper called, and whatever is on the other end never knows the difference.

The third pass often changes the estimate the most. A wrapper carries no conversion cost, because there is no logic inside it to convert, and neither do its near-duplicates. Each one is still tested and cut over like any other flow.

The libraries go too. The export also contains actions and script modules, and many of them are integration libraries: a REST client for Infoblox, one for the load balancer, one for SolarWinds, written by hand because vRO had no plugin for any of them. Where Kestra has a plugin for the target, that library is deleted rather than converted, and any business logic layered on top of it still moves. Where there is no plugin, the integration is rebuilt, through an HTTP task or a plugin of your own. Count these libraries separately from the workflows, because once a plugin covers the target, maintaining that integration stops being your team’s job.

Run the review with the owners of each functional area. The person holding the export usually cannot tell whether an annual workflow is dead or whether an unclaimed script still supports a production process. Give each owner their slice of the list and use the three passes above as the agenda.

The Migration Assistant runs these passes for you. It lists retirement candidates (and asks for run history), groups near-duplicates, separates wrappers from workflows with logic of their own, and marks which integration libraries a Kestra plugin replaces. The owners still confirm each one.

Your rough count. Apply the three passes in order and the export resolves into four numbers:

• vRO workflows, the raw export.
• Migrate to Kestra, what is left after retiring workflows that have not run in twelve months, which in a large environment are usually 10 to 20 percent of the list.
• Flows in Kestra, what is left once each group of near-duplicates becomes a single flow with inputs.
• Wrappers (easy migration), the flows that only call something else.

The payback calculator applies these three passes to your export count and carries the result straight into the cost estimate, so you do not size the inventory twice.

Work out your payback

3.2.3 Classify what moves

You now have a list of distinct workflows that genuinely need to move. The last step of Stage 1 is to organize them, so the migration becomes a small number of repeatable patterns rather than hundreds of individual pieces of work.

Sort by lifecycle stage first:

• Day 0 - Provisioning. Standing up the resource. VM and environment provisioning, standing up something new.
• Day 1 - Configuration. Making it usable. Configuration rollout, joining a domain, installing agents, registering with monitoring.
• Day 2 - Operations. Everything after that, for the rest of the resource’s life.

Note that some teams use Day 0 for design rather than provisioning and shift the rest along by one. This guide uses provisioning, configuration and operations. Also note that these stages classify an environment rather than individual workflows: it is common and perfectly reasonable for one flow to provision a VM and configure it in the same run, which puts it in both Day 0 and Day 1.

Day 2 is worth splitting in two, because the two halves are different kinds of work:

• Resource actions act on a specific thing, usually because someone asked. Patch, resize, snapshot, extend a lease, decommission.
• Operational automation watches and reacts, usually with nobody asking. Certificate expiry, configuration drift, compliance sweeps, failure alerting, incident response.

Then sort within each stage by pattern. In large estates, many workflows turn out to fall into a much smaller set of patterns, so the number of patterns matters more than the raw count. Check that ratio against your own inventory before you use it to estimate effort. Kestra’s blueprints are organized the same way, so each pattern has a working template to build against, and a wave becomes “these 40 workflows are all patching, here is the blueprint, do them as a batch.”

Classify the conversion effort. Lifecycle stage and pattern help organize migration waves. Complexity helps estimate the effort. Sort the workflows that move into three groups:

• Wrappers. Flows that only call Ansible, a script, a pipeline, or a single integration Kestra has a plugin for. They carry no conversion cost, because Kestra calls the same thing directly.
• Medium. Flows with their own logic and understood dependencies. The Migration Assistant handles much of the conversion, and an engineer reviews the result.
• Complex. Flows nobody fully understands, deep custom JavaScript, or behavior that should be redesigned rather than carried across. These are rewritten by hand.

Before a flow goes into complex, check what its JavaScript actually does. Much of what looks like deep custom code is an integration library for a target Kestra already has a plugin for. That code is deleted, and the flow is classified on what is left, which is often medium and sometimes a wrapper.

Within each group, separate the first of a kind from its near-duplicates. Twenty workflows sharing one implementation are one first of a kind and nineteen near-duplicates. A standalone workflow is a first of a kind with no near-duplicates. Most of the effort goes into the first of a kind, and each near-duplicate afterwards is mostly a matter of inputs.

Keep near-duplicates in the same group as their first of a kind. If one needs substantial redesign, count it as a first of a kind of its own.

These counts are inputs to the payback estimate in Section 7.2. Retain the workflow list behind each group so you can check that every workflow in scope is counted once.

The Migration Assistant does this classification too, and adds what a spreadsheet can’t: for each workflow, the systems it calls and the Kestra plugin or HTTP route for each one, and a wave plan with the first of a kind for each wave.

3.3 Summary of what you leave Stage 1 with

Stage 1 is done when you can put the following four things on one page:

The pattern breakdown identifies candidates for the proof of concept and suggests how the remaining workflows can be grouped into waves. The decision table and target architecture show which Kestra features and plugins the proof of concept needs to exercise. None of this requires Kestra to be installed, and neither does the Migration Assistant.

Download the PDF

4. Stage 2, Proof of Concept: Prove the pattern and get it funded

In Stage 2, a Kestra field engineer works alongside your team to build and measure real workflows in your environment. The proof of concept needs to show how those workflows behave in Kestra, how long conversion takes, and whether the result is credible enough to fund the migration.

Build on the deployment shape you intend to run and connect the systems those workflows actually use. If the proof of concept succeeds, the flows can become part of the first production wave.

4.1 Before it starts

A scoping session where we agree on four things:

• The executive sponsor. Who decides on the business metrics of the PoC and approves the budget.
• The requirements and the context. What the chosen workflows touch, what your environment allows, and what is already decided.
• The success criteria, agreed in advance. Usually five to eight items, chosen by your team, measurable within the PoC, and tied to something the executive sponsor cares about.
• Who is involved and how much time they have.

Here is one success criterion written out in full as a starting point for your own:

Most of this comes straight out of your Stage 1 outputs.

A start date both sides can hit. We need to schedule our engineers, and you need people free to deploy on the first day. This is the single most common reason a PoC slips.

4.2 What a migration proof of concept proves

A migration proof of concept should answer four questions:

The last one is the link between the stages. Stage 1 gives you the counts. Stage 2 gives you the rate, and how much of the conversion the Migration Assistant actually handles on your own code. Together they give you an estimate you can defend.

Some answers arrive faster than others. At the Fortune 500 manufacturer above, the difference in day-to-day engineering was clear within the first few days: errors were legible, execution was predictable, and the workflows stopped behaving like a black box.

4.3 How it runs

A PoC runs for three weeks from the kick-off call, including the install. Most of the work happens in weekly working sessions of 30 to 45 minutes, each one setting up or solving one success criterion, with a shared Slack or Teams channel in between so you are never waiting for a meeting to get unblocked. If criteria are still open at three weeks, the PoC continues only while those weekly sessions do.

It moves through five phases:

1. Scoping. The session described above, covering the sponsor, the requirements, the success criteria and the people. It also confirms that your deployment requirements fit one of our reference installation templates, so the install is a known quantity before anyone starts.
2. Launchpad. A one-hour kick-off with your engineers and executive sponsor, and ours. The shared channel is live before the call, and we go through a pre-flight checklist covering the network connectivity, identity, storage and secrets the install will need.
3. Install. Kestra is self-hosted, so this is your environment. We send an Enterprise licence ahead of time, so nothing is gated during the evaluation, and provide a Helm chart or Docker Compose template configured for what you described at scoping. The aim is the UI running within two days and a first workflow executed in the first week. Security and the target architecture are settled here rather than discovered later.
4. Sprint. Your team builds the workflows and we advise. Where the Migration Assistant converts one, we run it with your team and your engineers review and own the result, because the point is that your team leaves ready to do this without us. The integrations with your ITSM, CMDB, IPAM and monitoring get wired up first. Then come retries, error branches, SLAs, monitoring and parallel execution at close to real volume, which is where the team tests production behavior rather than the happy path.
5. Review and decision. Progress is checked against the success criteria each week. At the end you have the results against each one and what production actually needs, so the cost side of your business case is measured rather than estimated. Whether to proceed is decided with your executive sponsor.

4.4 Choosing the workflows

Choose two or three workflows from the pattern breakdown.

1. Choose one difficult workflow that you would run in production. A simple happy-path workflow will not expose the migration risk you need the PoC to measure.
2. Include at least one the business cares about, so the outcome is something the executive sponsor recognizes without the architecture explained.
3. Cover more than provisioning. If all of them are Day 0, the PoC has not tested the half of your environment where most of the work sits.

Record any other candidates for the migration plan rather than adding them to the PoC.

4.5 What we measure

The success criteria decide whether the proof of concept passed. The measurements are what the business case needs from it. They only mean something if the same workflow is measured on both platforms, so we baseline in vRA before converting anything. Two kinds of number come out:

• Conversion effort, which sizes the rest of the migration. For each workflow, record the hands-on hours to understand, convert and validate it, whether it is medium or complex, and whether it is a first of a kind or a near-duplicate. For medium workflows, also record how much of the conversion the Migration Assistant handled. These replace the starting assumptions in the payback calculation with rates measured on your own code.
• The four measures, which show what changes once you have migrated: speed of delivery (request to working automation), development effort (hours to build or change a workflow on each platform), people who can build automation, and consolidation (instances and consoles you run). Take each on the same workflows in vRA first and in Kestra afterwards. The business case section shows how to present them.

Keep shared deployment and integration work out of the per-workflow numbers, and note any workflow that needed redesign or produced a different result from the original. Two or three workflows will not cover every combination, so use them to inform estimates for the rest rather than as the estimate itself.

5. Stage 3, Migrate: one pattern at a time, with vRA still running

Stage 1 defines what moves, and Stage 2 gives you a measured conversion rate. Stage 3 is where most of the people cost and production risk sit. The goal is to reuse each pattern and keep every cutover reversible.

5.1 Waves by pattern, not by team

Take your pattern breakdown and convert one group at a time. Forty patching workflows, one blueprint to build against, done as a batch. Then the next group.

Organizing waves by team is convenient because it matches the ownership model, but each team’s workflows usually span several patterns. That makes every workflow a new conversion problem. A pattern-based wave solves one pattern and then repeats it across the teams that use it.

Two rules that hold for every wave:

• Acceptance criteria are written before the wave starts. What has to be true for this group to be considered migrated, agreed with whoever owns those workflows, in writing, before anyone converts anything. Retrofitting criteria at the end is how waves stall.
• Sequence by risk, not by size. Start with a pattern where a failure is recoverable and visible. Leave the one where a failure means someone cannot provision in a production datacentre until the team has done two or three waves.

5.2 How to convert vRO workflows to Kestra

There are three ways to convert a workflow, and most estates use all three. The mix is what determines the cost per workflow. Wrappers need none of them, since Kestra calls what they called. Integration libraries that a Kestra plugin covers are not converted either. The library is deleted, and the workflows that used it are rebuilt on the plugin, which is faster than converting the code, though not free.

Manual rewrite. An engineer reads the vRO workflow and writes the Kestra flow. Use this for complex workflows, code the team no longer understands, or logic that should be redesigned instead of carried across.

Templated. Build the first of a kind once, then apply it to its near-duplicates. Kestra blueprints can provide a starting point, but the first flow you finish in your environment becomes the template. The near-duplicates are then mostly inputs and integration details.

With the Migration Assistant. This is the route for medium workflows, and we run it with you. It works from the migration plan in Stage 1, one wave at a time:

1. Tests come first. Kestra unit tests are written from each workflow’s description before any conversion exists, one per path through the vRO workflow. Behavior you chose to keep, including a possible defect, gets a test that pins it.
2. The first of a kind is converted and reviewed. The tool converts the structure (folder hierarchy to namespaces, configuration elements to the KV Store, SecureStrings to secrets, resource elements to namespace files) and rewrites the JavaScript as Kestra tasks, using a plugin wherever one covers the integration. Every vRO item becomes a Kestra task or an explicit TODO, so nothing is dropped silently. An engineer reviews the first of a kind before the rest of the wave follows, and every converted flow is reviewed before it is certified.
3. The flows pass their tests, in your Kestra.
4. The wave runs against a simulated copy of your environment, then against your non-production systems, side by side with vRA, until the owner certifies it against the acceptance criteria agreed before the wave started. Only then is the vRA version retired.

How much of the conversion the Migration Assistant handles depends on how much logic sits in JavaScript, how consistent that code is, and which SDK calls it uses. The payback calculation in the business case lets you set your own share, and a proof of concept measures it on your code.

For some estates, the right answer is not to convert at all. When most of the JavaScript turns out to be integration libraries that plugins replace, and what is left is logic the team would design differently today, rebuilding from the pattern breakdown can be faster than converting workflow by workflow. Stage 1 applies either way: the inventory, the decisions and the patterns are what you build to. The Migration Assistant’s brief says which side of that line your estate falls on, and why.

5.3 Who does the work

Most migrations use a mix of three delivery models.

Level 1, on your own. The assessment is yours to run, along with the extraction tools from Stage 1, Kestra’s blueprints, and your own templates once each first of a kind exists. Teams with engineering capacity can do the conversion by hand or from templates. The completed migration in Section 2.5 was done by the five or six people who already owned the platform, alongside their normal work.

Level 2, migrating with us. We run the Migration Assistant’s conversion with your team, wave by wave: we review each first of a kind before it’s replicated, unblock the patterns that don’t convert cleanly, and verify each wave. Kestra support tiers include Expert Advisory hours, which are also available separately. This is the level most estates need, because the expensive mistakes in a migration are made once, early, and then repeated.

Level 3, a partner. For a very large estate, or a migration that’s part of a broader architectural change rather than a like-for-like replacement, a systems integrator can do the conversion work, starting from the same assessment.

5.4 Verification has to be supplied

One estate behind this guide had no test framework for vRO. If your estate is the same, the migration needs to add verification instead of inheriting it.

The minimum for each wave:

• A test per converted flow. Kestra’s unit tests are an Enterprise feature and they are what Stage 3 runs on.
• Output equivalence against the vRA run for the PoC set, so you can show that the converted flow does the same thing rather than merely running.
• The acceptance criteria you agreed before the wave started, checked before it is called done.

This is where the Migration Assistant does the most work. Tests are written from the original workflow before conversion, and each wave runs its full lifecycle against a simulated copy of your environment, with mocks of the systems it calls, built from the vendors’ published APIs where they exist, before it reaches yours. In our own testing, that step caught a conversion bug the unit tests had missed.

5.5 Running both systems

vRA keeps running the estate until each wave is verified and switched over, which has three consequences worth planning for.

• Nothing gets frozen. The automation keeping the lights on continues to run and continues to be changed while the migration happens alongside it.
• The overlap costs infrastructure and people, not licence. The vRA licence you have already paid covers the overlap. What doubles up is the infrastructure and the team running both platforms at once. It sits outside the payback calculation, so add it to your estimate alongside the other one-off costs.
• Every wave is reversible until you retire it. If a converted flow does not behave, the vRA version is still there and still working. Nothing is cut over unverified.

6. Stage 4, Exit: retire vRA wave by wave, end the licence at renewal

6.1 The renewal date is the one fixed point

Term licences do not refund mid-contract, so a cutover in month four of a twelve-month term usually produces no licence savings that year. If you own a perpetual licence, the date that matters is the support and maintenance renewal, or the point at which you would be moved to subscription. Either way, build the wave plan backwards from that date and leave enough time to validate the final wave before notice is due. If the last wave slips past it, you renew, and the saving moves out by a full term.

6.2 Retire per wave, and validate the exit

Once a wave is verified, switch off the vRA side of it rather than leaving it running quietly. Estates that defer this end up paying for parallel running long after the parallel running stopped being useful.

Validate the exit from each wave with a checklist:

• Nothing still routes to vRO for these workflows.
• No schedule still fires there.
• No catalog item still points at it.
• No subscription still listens for a lifecycle event that these workflows depended on.

6.3 Decommission and close out

Export what you need for audit before anything is switched off, because vRO’s execution history does not survive the appliance and your retention policy probably does not care that the system was retired. Then decommission the appliances, release the licences, and tell procurement the renewal is not happening early enough that they can act on it.

7. Build the business case

The business case needs to show why replacing vRA and vRO with Kestra is worth the investment. The investment is the migration. The return is the vRA and vRO renewal you do not sign, together with the improvements the move brings. It has three parts: what improves, what leaving costs and when it pays back, and why Kestra rather than the alternatives.

Where the case also depends on engineering capacity or reduced operational risk, present those benefits separately and be clear about which ones the proof of concept demonstrated and which remain projections.

7.1 What improves, and how to measure it

Teams that replace vRA report the same four improvements: infrastructure requests get delivered faster, building and changing automation takes less engineering time, more people on the team can do it, and the number of things to run and upgrade goes down. How much of each you get depends on your estate, so measure all four rather than assuming.

Use the four measures below to present the results.

Start with the numbers you already have

Most of the baseline is already recorded somewhere, and none of it needs Kestra installed. Pull it before the proof of concept, because it is what the after figures get compared against and because it describes the current state on its own:

• Ticket volume and average time to fulfil for infrastructure requests, from your ITSM.
• Average time to resolution when an automation fails, from your incident records.
• Requests reopened, escalated or abandoned, which is where the cost of a slow process actually shows up.
• The automation backlog: requests the team has accepted and not started.

These numbers describe what the current platform costs you in delivery terms, and they are usually more persuasive than anything a proof of concept produces, because leadership already recognizes them. Four hundred provisioning tickets a year at an average of eleven days is a problem a leader understands without the architecture explained.

Separate the cash savings from the capacity gains

Finance treats them differently, and the case should too.

• Cash savings are payments that stop. The largest is usually the vRA and vRO renewal you do not sign, then the infrastructure the retired instances ran on and the consulting or specialist support you no longer buy. These are the numbers a CFO looks at first, and the payback calculation below starts from them.
• Capacity gains are engineering hours returned to the team. Reducing maintenance effort frees capacity without reducing payroll, so it is not a saving unless something is actually cut. Where it avoids a planned hire or reduces consulting spend, name that specific saving and count it once, as cash.

Consolidation is the measure that converts most directly. Count the instances, consoles and supporting infrastructure that are actually retired, and apply the hosting, licensing and support cost of each. Unlike freed engineering hours, those payments stop.

Delivery time and development effort are different from each other. Removing a handoff may shorten delivery without saving many engineering hours. Faster development may free capacity even when an approval process still determines the delivery date. Where development effort falls, use the expected annual volume of comparable work to estimate the hours recovered, and state what the team would do with that capacity. Do not assume that a result from one workflow applies to every category, or count the same hours under both development effort and consolidation.

Some benefits will remain projections until the migration is complete. A proof of concept can demonstrate that more engineers can work with the flows, but wider training still takes time. It can validate a consolidated deployment, but operating costs fall only when the old instances are retired.

7.2 What leaving costs, and when it pays back

The migration is the investment. What pays it back is the vRA and vRO renewal you do not sign, together with the other annual costs that stop when vRA goes. The licence you have already paid is sunk, whether it is perpetual or a term already under way, so the saving starts at the renewal date rather than at cutover.

The calculation has three inputs:

1. The renewal you avoid. Your annual vRA and vRO spend at renewal, plus other annual costs that stop, such as support, infrastructure and consulting.
2. What getting out costs. Only medium and complex flows carry a conversion cost, since wrappers and their near-duplicates do not. For each group, estimate the hours for a first of a kind and for each near-duplicate, reduce the medium first-of-a-kind hours by the share the Migration Assistant handles, and multiply by your blended hourly rate.
3. What you would spend on Kestra. Licence and hosting, a year.

Payback is the month in which the renewal you avoided has covered the migration and Kestra. Compare over your finance team’s planning horizon, or three years if there is none.

The payback calculator takes your renewal, your workflow counts from 3.2.2 and your migration rates, and gives you the month the move pays for itself, with a CSV and a shareable link for the finance review.

Work out your payback

Two habits make the estimate hold up in front of a CFO:

• Run it twice, once with low assumptions and once with high. The result should be a range, not a single number.
• Label every rate as measured or estimated. A proof of concept of two or three workflows gives you a few measured rates. The rest are engineering estimates informed by them, and a reviewer should be able to see which is which.

Count every workflow once. Keep near-duplicates in the same group as their first of a kind. Workflows retired during the assessment are already out and near-duplicates are already priced at their own rate, so do not discount either a second time.

Then add the work that happens once, and the overlap. Platform deployment, shared integrations, security review, training, cutover and project coordination all sit outside the per-flow estimate. So does the period when both platforms run, which costs infrastructure and people rather than licence. If proof of concept flows can be used in production, deduct their completed work.

Only count a saving when the payment actually stops. If vRA is part of a VCF bundle you will keep buying for the hypervisor, removing vRA may not reduce that invoice at all. Confirm the amount and timing with procurement before it goes in the case.

As a reference point rather than a projection: the Fortune 500 manufacturer above reports licensing costs 90% below Aria Automation after replacing it.

The result is a cost and payback estimate rather than a delivery date. How long the migration takes depends on team availability, access to systems and approval windows, and if the last wave finishes after the renewal, the saving moves out by a full term.

7.3 Explain why Kestra fits

The argument leadership needs is the one this guide opened with. The proof of concept is what makes that believable, so answer the three questions from the start of this guide with your own results rather than ours.

Does it cover your whole infrastructure estate, or a different slice of it? Name the integrations you validated, inside VMware and beyond it: vCenter, your ITSM and CMDB, IPAM, the cloud accounts, Kubernetes. Then show which of your existing tools stay and get called, such as Terraform, Ansible and ServiceNow, and which implementations change. That makes the scope of the replacement clear and explains the migration estimate.

How hard would it be to leave? Show that the flows your team built are YAML in your own Git repository, written in languages your engineers already use, on an open-source core. The strongest evidence is an engineer other than the original author modifying and troubleshooting one of those flows without help.

Is your team the only one who needs this? If another team could run its own automation on the same platform, or another orchestration tool or custom integration layer could be retired, say so. Include any retirement you can confirm in the payback calculation, and treat the rest as a future opportunity until its scope is agreed.

Does the deployment meet your constraints? Summarize the security, network separation and operating requirements you validated, and be specific about the resulting architecture. Some environments can consolidate control planes. Others need separate deployments because of security policy, and it is better to say so than to let leadership assume one.

Leadership will ask about the alternatives: staying on VCF, moving to another commercial cloud management platform, or building on Ansible and scripts. Answer each against the same lesson. Staying keeps your automation priced and scoped by your infrastructure vendor. Another platform may solve today’s problem and recreate the same dependency on a different vendor. Building it yourself avoids the dependency, but leaves your team owning everything around the scripts, from the catalog to the audit trail. Put the cost of each next to the payback above.

Close with the requirements that decided the recommendation and any gaps that remain. Keep untested assumptions visible.

7.4 Assemble the migration approval package

Your team and Kestra assemble the case together. Kestra contributes the proof of concept findings, deployment sizing and quotation. Your team supplies the operating costs, procurement terms and internal priorities.

Keep the leadership summary short, with the supporting calculations available behind it:

• The recommendation. What moves to Kestra, what stays, and why this is the preferred option.
• The investment. Migration effort and cost range, Kestra pricing, and the infrastructure and people cost of running both platforms during the overlap.
• The expected return. The renewal you do not sign first, then other cash savings, then the capacity gains and operational improvements, with projections identified separately.
• The delivery plan. Owners, team allocation, migration waves and expected retirement dates.
• The risks. Unresolved gaps, untested workflow categories and dependencies, with allowances and mitigations.
• The approval requested. Budget, people and the proposed start date.

Tie the timing to your environment. If savings depend on avoiding a renewal, work backward from the notice deadline and allow time for approval, migration and retirement. If the case depends on delivery capacity, show which work remains delayed until that capacity is available.

The final proposal should make clear what the organization will spend, what it expects to gain, and which evidence supports the decision.

Download the PDF

8. Getting started

There are three ways to start. The quickest is to run the Migration Assistant on your own estate, which needs no conversation and no Kestra install. From there, the next step is a migration proof of concept with us, built on what the assessment found. A vRA migration usually crosses several systems, and many of the capabilities needed to test it properly are available only in Enterprise Edition. If you want to explore the product and its authoring model first, you can install Kestra Open Source without contacting us.

8.1 Run the assessment on your own estate

Export your vRO package, and your vRA content if vRA starts your workflows, then run the Kestra Migration Assistant for vRA on your own machine. It’s free and open source, and installs with one command. You get a brief describing your estate, a recommendation for every workflow, the Kestra plugins that cover your integrations, and a migration plan in waves. It covers the workflow side of Stage 1 for you and asks the questions behind the estate decisions, which makes it the best starting point for a conversation with us.

Get the Kestra Migration Assistant for vRA

8.2 Run a proof of concept with us

A migration PoC uses two or three workflows from your environment, including at least one difficult one, and connects them to the systems they use today. Before converting anything, we agree on the success criteria and baseline the same workflows in vRA.

Your team builds the flows with guidance from Kestra. This tests more than whether the workflows run. It shows how much work conversion takes, where the two platforms differ, and whether your team can develop and operate the result. The deployment should reflect the environment you intend to run, including the relevant network zones, integrations and security requirements.

At the end, you have working flows, a measured conversion rate, before-and-after results on the four measures, and enough deployment sizing to estimate the migration and build the business case. Section 4 explains how the PoC works and how to choose the workflows.

Talk to our team

8.3 Start with open source

Kestra’s core is open source and requires no commercial agreement. Install it, choose a small set of real workflows from section 3.2.3, and build them. The infrastructure automation use case is a practical starting point.

What open source covers. You can test the workflow engine, the conversion pattern, and the point where manual work begins. vRO workflows, actions, configuration elements, schedules, error handling, retries and dynamic request forms have open-source equivalents. You can also provision against vSphere or Nutanix through Terraform and see whether the authoring model fits your team.

Where it stops for a vRA migration. Many of the capabilities needed to test the wider environment are available only in Enterprise Edition:

Whichever route you take, use real workflows from your environment. They will show you what converts cleanly, where redesign is needed and how much work the migration is likely to take. From there, you can build the plan around your own systems and conversion rates instead of relying on a generic estimate.