Migrating An RPA Estate

Migrating an RPA estate

Nothing else here addresses the automation you already have.

---

The estate nobody audits

Most organisations arriving at agents already run a fleet of robotic process automation, built over years, by people who have mostly moved on.

Before you can move forward you need an honest audit of where you are, and the honest audit usually finds three categories in very different proportions than expected.

	What it is	What to do
Workhorses	High value, high reliability, still doing their job	Keep and maintain. Do not migrate something that works to prove a point
Zombies	Running but unused, or technically fine and producing no measurable value	Retire. They cost money, hold credentials, and inflate the estate's apparent size
Upgrade candidates	High-value processes where the automation's limits are creating a ceiling	These are your migration targets

The zombie count is the surprise. An automation nobody uses does not announce itself; it succeeds silently, forever, at nothing. Finding them is usually the fastest cost saving available and it needs no agent at all.

The five upgrade triggers

Any one of these makes an existing bot a strong candidate. They are testable statements you can check against your own estate today, which is what makes them useful.

1 · It breaks whenever the source system's interface changes, and maintenance has grown to a substantial fraction of what it cost to build. (The source puts that fraction around forty percent. Calibrate it: the real signal is maintenance cost trending up while volume is flat.)

2 · It handles only the happy path. A human still handles every exception by hand, and exceptions are a meaningful share of total volume. (The source uses one fifth as the line.)

3 · The process requires reading and interpreting unstructured content that text extraction alone cannot handle accurately.

4 · One end-to-end process needs three or more separate bots with manual handoffs between them.

5 · Users have stopped trusting the output and are checking it manually anyway. (This one costs you the entire benefit and appears in no dashboard.)

Trigger 5 is the one to look for first, because it means the automation is already failing and the organisation has silently absorbed the cost rather than reporting it.

The four migration patterns

1 · Augment

When: the bot works but has hit a ceiling.

What changes: the bot keeps the structured steps; a model layer handles unstructured inputs and drafts the exceptions.

Cheapest pattern and the most under-used. Nothing is retired and the existing reliability is kept.

Example: an existing eligibility-check bot, plus a layer that interprets free-text conditions it previously routed to a human.

2 · Replace

When: the bot is fragile, expensive to maintain, and the process actually needs judgement.

What changes: retire it; build an agent with proper state management.

The most expensive pattern. Justified by the maintenance line, not by the ambition.

Example: a brittle status-checking bot replaced by an agent that holds conversation state across systems.

3 · Orchestrate

When: several bots handle fragments of one workflow with poor handoffs.

What changes: an orchestration agent coordinates the existing bots as tools. The bots stay.

The highest ratio of benefit to risk in the whole table, and the one most often skipped because it does not feel like building something new.

Example: three bots covering one intake-to-fulfilment flow, coordinated by an agent that holds the shared context they never had.

4 · Elevate

When: there is no existing bot. A new capability.

What changes: net-new, designed agentic from day one, through the full proof gate model.

Example: a document-heavy approval process nobody automated because rule-based tooling could never read the documents.

Read that table as a preference order, not a menu. Augment and Orchestrate keep what works and are cheaper than they look. Replace is a real answer and it is the one people reach for first for reasons that are usually aesthetic.

Before retiring any production bot

A bot in production is load-bearing in ways nobody documented. This checklist exists because the failure is always the undocumented dependency.

• Document every step it currently handles, including the undocumented workarounds. These are the ones that break
• Identify the exception rate and who handles those exceptions today. That person is your best source and often nobody has asked them
• Map the downstream dependencies. What consumes this bot's output, including the report somebody built on top of it
• Confirm the replacement has passed all three proof gates before the bot is retired, not concurrently
• Run both in parallel for a real period before cutover
• Communicate before cutover, not after
• Keep the bot dormant but deployable for a rollback window after migration

The last item is the one that gets cut for tidiness and is the cheapest insurance on the list. A deleted bot is a rollback you cannot perform.

_{Adapted from the AI CoE and Agent Factory Playbook, based on The Augmented Enterprise framework. The preference ordering of the four patterns is the author's own.}

_{Back to Home · The three proof gates · The deployment ladder}