Migration Decisions That Hold Up

Why Automation Migrations Fail, and the 3 Steps That De-Risk Them

Migrations fail when they miss the objective that justified them in the first place. The five common causes are underestimated technical complexity, strategic drift, business disengagement, transferred legacy technical debt, and governance or skill gaps. De-risking runs on three interdependent steps: identify the gaps you are trying to close, justify the move with a business case that survives executive scrutiny, and mitigate through roadmap sequencing, testing access, guardrails, and enablement. AI accelerates parts of the execution. It does not touch the organizational work that makes a migration stick.

A migration is one of the most consequential decisions an automation leader makes. It trades short-term pain for long-term benefit, which means the conviction behind it has to hold up under pressure, because the short-term pain arrives on schedule every time.

Kevin Hong and Ryan Neal have spent seven years at Ashling working migrations from both sides, first as hands-on developers and now advising clients on program operating models and strategic direction. They have been part of migrations that went very well and migrations that did not. On a recent webinar, they laid out what separates the two.

What Counts as a Migration

Migration gets used loosely, so define it before you scope one.

For an intelligent automation program, a migration is the transition of automation assets within or across environments. That definition is broad on purpose. It covers:

• Platform-to-platform moves
• On-premise to cloud transitions
• Major version upgrades within the same platform
• Significant refactoring efforts

The governance principles apply across all four, some more heavily than others. What makes intelligent automation migrations distinct from other IT migrations is that the assets themselves have to move. You are not just standing up a new environment. You are relocating every solution built in the old one.

The list is not exhaustive, and the drivers overlap. That overlap is useful. The strongest business cases stack several drivers together, which is what moves an executive leadership team from interest to approval.

Modernization deserves a specific note, because technical debt compounds quietly. Every automation built on the old platform or the old version makes the eventual migration more complex and more expensive. Organizations that modernize now get to build on a platform designed for the next five years. Organizations that keep the lights on are narrowing their options with each new build.

How Strategic Drift Actually Happens

The mechanism is worth spelling out, because it never announces itself.

Say the migration was driven by necessity. The current version is approaching end of life and there is a hard date attached. Six weeks into a long program, a business unit says: we understand you have to do this, and while you are in there, could you add one small feature? Could you account for one change in business logic?

The developer estimates four hours. Then six hours somewhere else. Then another day. Then another week. Often none of it reaches the program level. Then something unanticipated happens, and now the program has missed the migration deadline and shipped an asset that does not deliver the core requirements it needed to deliver to get off the old platform.

The fix is unglamorous. Write down the strategic objective, communicate it across the program, and keep pointing back to it through the full life cycle.

The 3 Steps That De-Risk a Migration

De-risking does not eliminate uncertainty. It designs for it. These three steps are interdependent rather than sequential, and each one should inform the others.

Step 1: Identify

Take stock of the current state and map what you want from the future one.

• Legacy limitations. What are the constraints you feel today, and which complexities will compound if you leave them alone?
• Capability mapping. Match the new platform's capabilities to the problems you actually have. A solution running around looking for a problem is how programs end up with expensive features nobody uses.
• Modernization triage. Does everything need to migrate? It is rarely all or nothing. Some assets deserve a rebuild, some a lift, and some a retirement.
• Operational readiness. Assess the governance model, the CoE structure, the team, and the skills on it. This feeds directly into enablement planning later.

Step 2: Justify

Build the case that will hold up in front of an executive leadership team or a technology evaluation board. The questions are predictable, so answer them early.

• Total cost of ownership. Current licensing and maintenance cost against projected future state cost.
• The innovation dividend. Quantify what the new capabilities unlock. A cloud move or a platform change should pay for the risk it introduces, and naming that value specifically is what makes the case land.
• Timeline. How long, in what sequence, and when the business value shows up.
• Migration risk pricing. Parallel running costs money. The legacy platform keeps operating while the new one is tested, and that overlap belongs in the budget. In most cases the overlap is the right call rather than an immediate cutover.

Step 3: Mitigate

Once you have the green light, the goal is to keep the delivery engine moving instead of getting caught flat-footed on day one.

• Sequence the roadmap. Group automations logically, by risk reduction, by legacy licensing cost, or by compliance exposure. Department order is rarely the right organizing principle.
• Design the testing strategy, then check your access. Teams assume that because an automation is already in production, the code, environments, and test data are all available. Sometimes the original developers have moved on and the test data is gone. Treat that access as table stakes and verify it early, because it may reshape your sequencing.
• Set guardrails and templates. New capabilities need a governance layer, including the AI and agentic guardrails that keep you inside regulatory and compliance requirements.
• Plan enablement and upskilling. Launch training with a timeline and a time box around it, so the team is ready when their part of the roadmap arrives.

What AI Can Accelerate in a Migration Right Now

As of mid-2026, four uses have shown consistent return. The operative word throughout is assist. These are force multipliers on human effort rather than replacements for it.

1. Reviewing and explaining existing code. Somebody has to read the current artifacts. Models are strong at analyzing existing automation code and generating documentation, technical specifications, and architecture diagrams from it. This gets especially valuable across platforms with different syntax and languages, where the translation work is the bottleneck. It also beats relying on a developer's memory of what they built eighteen months ago.

2. Analyzing SOPs and process artifacts. Process diagrams, standard operating procedures, and other non-code documentation can be run through models to fill the gaps in what the code alone explains.

3. Drafting initial code. In both high-code and low-code environments, models draft solid initial automations and code frameworks. Feed them the outputs of the first two uses and the starting point improves considerably. Developers still review, customize, update, and test to get to a final build.

4. Generating test scenarios. Given the procedures and the automation requirements, models produce exhaustive initial test scenario lists. Those scenarios can then become mock test data, assuming your target applications will accept it and the application owners are coordinated.

What AI Cannot Do

There is a mild awkwardness in an AI and automation firm publishing a list of things AI does not handle. The list is honest anyway, and it is the part that determines whether a migration sticks.

Business stakeholder engagement. AI can help draft requirements. It cannot make the migration a shared decision instead of a unilateral one. Business stakeholders confirm scope, validate the business case, and define the desired outcome, which is what "success" gets measured against later.

User acceptance testing. This one looks contradictory, given that AI generates test cases well. The distinction is what is being tested. AI validates that the code performs and operates correctly. UAT validates that the solution does what the business actually intended, which sometimes lives in a target application and sometimes is not cleanly documented anywhere. UAT is also where business confidence in the new platform gets built.

Project management. Somebody has to be accountable, call out risks, and accept trade-offs. Those decisions carry context and relationship history that no model has access to.

Change management. This is a people problem end to end. Adoption needs humans to inspire it. Confidence needs humans to build it. Communication plans and expectation setting are how a migration gets perceived as a success rather than a disruption, and treating change management as an afterthought is a reliable way to undermine good technical work.

Where to Start With 50 Automations

A common question: with 50 to 75 automations to move, six to eight developers, and a couple of delivery managers, does agile or waterfall work better?

Sequencing matters more than methodology. Which automation goes first shapes the program more than how you run stand-ups.

Two extremes to avoid. Starting with the simplest automation sets an expectation across the rest of the roadmap that the work is easy. Starting with the hardest means absorbing every painful lesson at maximum cost. Select the first batch strategically, based on the diverse capabilities you want to prove out on the new platform, avoiding both the trivial and the brutal.

On methodology itself: you are already absorbing a large change. If waterfall has consistently worked, keeping it is one fewer variable. Make incremental adjustments at checkpoints instead of switching approaches mid-migration. Put extra governance and extra eyes on the first batch, and feed those lessons forward as you go rather than saving them for a retrospective at the end.

One constraint that limits iterative rollout: the business already has a production success rate they are accustomed to. If a process owner is running at 90% today, they are unlikely to welcome a phased rollout that starts at 50% and ramps. That expectation may force a fuller cutover on certain processes regardless of what your methodology prefers.

Closing the Skill Gap

When a team trained on a legacy platform has to work on a new one, the honest framing helps: training and skills are different things, and skills and experience are different again.

A one-week or two-week training course does not replace three years of accumulated platform knowledge. Nobody's familiarity with a platform came from attending training. It came from doing the work over years.

What works:

• Translate rather than restart. Much of the fundamental knowledge transfers, and many concepts map across platforms. Meeting people in the language they already know shortens the curve.
• Use the free material as a starting point. Vendor training, forums, and community programs are widely available and are the right entry point.
• Learn by doing, with guidance. Pair people with someone who has done the migration before. Riding shotgun through the first builds compresses months of trial and error.
• Talk to peers. Other organizations have made the same move and can tell you where the pain was.
• Bring in outside help, even temporarily. If the goal is retaining your current staff through the transition, accelerating their growth curve with experienced support is usually the fastest path there.