How to migrate off RPA: from bot inventory to PoC

A few years after adopting RPA, the number of bots has grown, and so has the work of fixing them every time they stop. The people who built them are gone. The license renewal date is approaching. This is when more companies start asking how to migrate off RPA.

However, there is no need to replace every bot at once. The approach least likely to fail is to keep the tasks RPA handles well and move tasks in order, starting with those that stop often and offer the largest gains. This article walks through how to review bots built with RPA products such as WinActor, UiPath, and BizRobo!, in order from inventory through PoC to cutover.

For why bots stop when screens change, see Why RPA bots break when screens change.

What prompts a migration

• Bots stop more often, and fixing them takes longer
• The people who built the bots have transferred or left, and no one knows how the bots work
• The license renewal date is approaching
• Business procedures have changed, and the bots no longer match how the work is actually done
• Audits or internal controls now require you to explain how bots are managed

If even one of these applies, start by getting a clear picture of your current bots.

Step 1: Take inventory of your bots

List the bots in operation and collect the following for each one.

Item	What to check
Task	Which task is automated, and for what purpose
Owner	The department responsible for the task, and who can fix the bot
Frequency and volume	How often it runs (daily, monthly, and so on) and how many items per run
Systems operated	Internal or external, web or desktop app
Stops	How many times it stopped in the last six months, and how long fixes took
Official integrations	Whether an API, CSV download, or data integration is available
Judgment	Whether any point involves, or should involve, human judgment
Impact of a stop	Whether it delays work or affects business partners or customers

An inventory often turns up bots that are no longer used, or bots still running for tasks that no longer exist.

Step 2: Sort bots into four groups

Based on the inventory, sort the bots into four groups.

Group	Bots that fit
Retire	Not used, the task no longer exists, or the volume is small enough to handle by hand
Replace with an official integration	The other system provides an API, CSV download, or data integration
Keep on RPA	Operates desktop apps or Excel, or performs high-volume routine operations on internal systems whose screens rarely change
Move to AI screen operation	Operates external web systems, screens change often, many exceptions or judgment calls

Screen automation is a last resort for tasks with no other option. If an official integration exists, it is more resilient to changes, faster, and more reliable. On the other hand, web portals that differ for each business partner, and external systems whose screens change without notice, are well suited to writing the procedure as text and having AI read and operate the screen.

Step 3: Choose one to three PoC targets

Choose PoC (proof of concept) targets from the bots in the “Move to AI screen operation” group. Good candidates meet these conditions:

• The work is completed entirely in a web browser
• It stops often, or fixing it takes effort
• The volume or work hours are high, so the gains are easy to compare in numbers
• The terms of use permit automated operation
• The people responsible for the task can take part in the PoC

There is no need to start with your most important task. Starting with a task where a stop would not cause too much damage and the gains are easy to see makes the results easier to explain internally.

Set success criteria first

Before starting the PoC, decide what counts as success. Without criteria, you cannot judge afterward whether it worked.

• Processing time per item, and staff work time
• Share of items processed, and number of stops
• Time from identifying the cause to resuming after a stop
• Share of items routed to human review or approval
• Number of incorrectly processed items

Measuring your current bots or manual work on the same items makes comparison easier.

Step 4: What to verify in the PoC

• Works with real screens and data: run it on the same screens as production, with data close to production data, not on a demo environment
• Resilience to changes and exceptions: how it stops, and how it can resume, when a pop-up or unexpected data appears
• Cost and time: AI screen operation incurs AI model usage fees and takes time for every operation. Measure the actual cost and processing time per item
• Security: confirm with the IT department how credentials are handled, what information is sent to the AI model, and which model is used
• Fixable by the team: whether people other than the builder can read the procedure and modify it

Step 5: Run in parallel, then switch over

Once the PoC confirms the gains, do not switch over all at once. Run the new automation in parallel with the existing bot or manual work for a set period, and compare the results. After switching over, keep the old bot for a while so you can switch back quickly if a problem occurs.

If a license renewal date applies, work backward from it to set aside time for the inventory, the PoC, and the parallel run.

Step 6: Build the ability to fix automation in-house

The goal of migration is not to swap out bots but to reach a state where your own team can fix automation when it stops.

• Assign an owner to each workflow, and someone to review its changes
• Review changes before applying them, and keep a history
• Decide where notifications of failures and pending approvals go
• Make the run status of all workflows visible in one place

Common mistakes

• Trying to replace everything at once: with too many targets, the PoC never finishes, and time passes with no visible gains
• Starting without success criteria: with no yardstick for comparing results, you cannot decide whether to adopt
• Putting off the terms-of-use check: if you target a service that prohibits automated operation, the PoC results cannot be used in production
• Leaving it to the builders alone: without the people responsible for the task and the people who will operate and fix the automation, it will not take hold

How to proceed with Kitewell

Descarty’s Kitewell is business automation software in which you write procedures in everyday language, leave web operations to AI, and have people approve decisions. When a workflow stops, it can resume from the step where it stopped, and you can investigate and fix the cause by talking with an AI assistant. Kitewell does not support operating desktop app screens, so we recommend keeping those tasks on RPA.

For companies, engagements start with a paid PoC that takes one to three of your actual tasks and verifies the gains on the same screens and data as production. The typical duration is four to six weeks in total. If you proceed to a full contract after the PoC, the PoC fee is credited toward the first year’s contract amount. For details, see Pricing & PoC. For how Kitewell differs from RPA, see Moving from RPA.