How to switch from RPA to AI RPA, step by step

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 switch the bots that keep stopping to AI RPA.

The most important rule of switching is not to replace everything at once. Keep the work RPA does well, and move bots in order, starting with those that stop often and hurt most when they do. This article walks through moving bots built with WinActor, UiPath, Power Automate, BizRobo!, and similar tools to AI RPA, in which AI reads and operates the screen, from inventory to cleaning up after cutover.

For why bots stop when screens change, see Why RPA bots break when screens change. For each product’s situation, see the guides by product on RPA problems.

Signs it is time to migrate

Bots stop more often, and fixing them takes longer
The people who built the bots have moved on, and nobody knows what is inside
A license renewal or price revision is coming up
Business procedures have changed, and the bots no longer match the work
Audits or internal controls require you to explain how bots are managed

The overall flow

Step	What to do	Output
1. Inventory	List running bots and collect how often they stop	A list of bots (the ledger)
2. Sort	Retire, integrate officially, keep in RPA, or move to AI	The sorted list
3. Prioritize	Order the moves by how often bots stop and the impact	The order of moves
4. Rewrite	Rewrite scenarios as steps in the language of the work	New workflows
5. PoC	Try one to three on real screens and data	Results against success criteria
6. Parallel run	Run old and new side by side and compare results	A log of differences
7. Cutover	Switch to the new workflow and clean up the old bot	An updated ledger
8. Embed	Set up the team to fix it in-house, then expand	Operating rules

If you have a license renewal date, work backward from it to leave time for the PoC and the parallel run. To be safe, the parallel run should include at least one busy period, such as a month-end close.

Step 1: Take inventory of your bots

List the running bots and collect the following:

Item	What to check
The work	Which work is automated, and for what purpose
Owners	The business team, and who can fix the bot
Frequency and volume	How often it runs, and how many items per run
Systems operated	Internal or external, web or desktop application
Stops	How many times it stopped in the last six months, and how long fixes took
Official integration	Whether an API, CSV download, or data integration exists
Judgment	Whether a person makes, or should make, decisions along the way
Impact of a stop	Whether work is delayed, or partners and customers are affected

If there are no records of stops and fix times, the owners’ memory is enough. Being able to compare bots matters more than precision. This list is the basis of a robot ledger. The columns and how to fill them in are in How to build a robot ledger for RPA, and an Excel template is available.

For bots whose builders are gone, see Taking over an RPA bot whose builder has left.

Step 2: Sort bots into four groups

Group	Suits bots that
Retire	Go unused, serve work that no longer exists, or handle so few items that doing them by hand is enough
Replace with an official integration	Operate a system that offers an API, CSV download, or data integration
Keep in RPA	Repeat fixed operations at high volume and speed on internal systems whose screens rarely change
Move to AI screen operation	Operate external web systems, face frequent screen changes, or deal with many exceptions and judgment calls

Screen automation is the last resort for work with no other option. If an official integration exists, it is more resilient to change, faster, and more reliable.

Step 3: Set the order by fragility and impact

Score each bot sorted into “Move to AI screen operation” from 1 to 3 on three aspects, multiply the scores, and move bots in order from the highest.

Aspect	1 point	2 points	3 points
How often it stops	Every six months or less	Every two or three months	Almost every month
Impact of a stop	Can be done later	Delays internal work	Affects payments, customers, or partners
Effort to fix	Fixed in-house right away	Few people can fix it	Nobody can, or an outside vendor does

For example, a bot that stops every month (3), affects payments (3), and is maintained by an outside vendor (3) scores 27 and is a first candidate. A bot that stops twice a year (1), can be caught up later (1), and is fixed in-house right away (1) scores 1, and there is no rush.

A high score does not matter if the bot operates a service whose terms prohibit automated access; it cannot be moved. Check first, as described in Check the terms before you automate a website.

Step 4: Rewrite scenarios in the language of the work

You do not need to copy an RPA scenario one operation at a time. In fact, it works better if you do not. A scenario is full of details tied to the screen as it was: coordinates, wait times, and element references.

Instead, sit down with the business owner and write the flow of the work in words:

State the goal and boundaries: “Enter the invoices suppliers send into the accounting system”
Write steps as units of work, not screens: “Read the invoice PDFs”, “Check the amounts and registration numbers”, “Enter each invoice in the accounting system”
Write where a person decides: “An accountant checks the entries before they are saved”
Write what to check: “After entering, check that a voucher number appears”
Write the exceptions: “Send invoices without a registration number to the accountant”

The elements of an RPA scenario translate roughly as follows:

In an RPA scenario	In steps AI operates
Clicks on coordinates or element references	Name the target in words, such as “Press the Save button”
Waits of a fixed number of seconds	Write the condition to wait for, such as “Check that the list is shown”
Finding a target by image	Name the target by its heading or role on screen
Finding the last Excel row and looping	Write “For each row of the list” and process row by row
Branches (if…)	Write the condition in words, and send hard calls to a person
Retries and alerts on error	Continue from the failed step and notify the owner

Check the rewritten steps by whether someone other than the builder can read them and follow. If they can, the steps double as handover material.

Step 5: Prove it with a PoC

You do not need to start with your most critical work. Start with one to three tasks whose stops do not hurt too much and whose results are easy to see; the results will be easier to explain internally.

Set success criteria first

Without criteria, you cannot tell afterward whether it worked. Measure the current bot or manual work on the same items:

Processing time per item, and the owner’s working time
The share of items processed, how many times it stopped, and why
Time from a stop to finding the cause and resuming
The share of items routed to a person for checking or approval
The number of items processed wrongly
AI model fees, separately for the first run and later runs

What to check in the PoC

It runs on real screens and data: not a demo environment, but the same screens as production and data close to production
Cost and time: if operations that worked are remembered and repeated, AI is used only to learn a new operation, relearn one after a screen change, or read information from the screen. Measure first runs and later runs separately
Security: confirm with IT how credentials are handled, what is sent to the AI model, and which model is used
The team can fix it: someone other than the builder can read and change the steps

Step 6: Run in parallel and compare results

Even after a successful PoC, do not switch over at once. Run the old bot (or the manual work) and the new workflow side by side for a while and compare the results:

Duration: include at least one period with high volume and frequent exceptions, such as a month-end or closing date
How to compare: compare item counts, total amounts, registration numbers, and so on, one by one, and log any differences
When results differ: the business owner decides which is right, and the steps are fixed. Sometimes the old bot turns out to be wrong
Agree on cutover criteria in advance: for example, “switch over after two closes, including a busy one, with no differences”

During the parallel run, avoid entering the same data twice in the target system: stop the new workflow just before the check, or use a test destination.

Step 7: Cut over and clean up

Do not delete the old bot right away: keep it stopped for a while so you can switch back if something goes wrong
Update the ledger: register the new workflow and mark the old bot as retired
Tidy accounts and licenses: remove bot accounts, stored passwords, and licenses you no longer need, in step with renewals
Archive the scenario and documents: keep the old scenario and records for audits and later reference

Step 8: Build a team that can fix it in-house

The goal of a migration is not to swap bots; it is to reach a state where your team can fix the automation in-house when it stops.

Assign an owner to each workflow, and someone to review changes
Review changes before applying them, and keep a history
Send failure and pending-approval alerts to a team, not to one person
Make the status of every workflow visible in one place

Once the first one to three are running with that team in place, expand to the next work in order of the step 3 scores.

Common mistakes

Trying to replace everything at once: too many targets, so the PoC never ends and time passes without visible results
Copying the scenario operation by operation: the old screen’s assumptions come along, and the new automation stops just as easily
Starting without success criteria: with nothing to measure against, you cannot decide whether to adopt it
Skipping the parallel run: an exception that appears only in a busy period stops the work, and it goes back to being done by hand
Leaving the terms-of-use check for later: if automated access is prohibited, the PoC results cannot be used in production
Leaving it to the builders alone: without the business owners and the people who will run and fix it, it does not take root

How it works in Kitewell

Descarty’s Kitewell is business automation software in which you write steps in the language of the work, AI operates the screens, and people approve decisions. Clicks and entries that worked once are remembered and repeated the same way, and the AI relearns an operation only when the screen changes. Where the content itself must be judged, such as reading invoices, AI is used every time. When a run stops, it continues from the step that stopped, and you can find and fix the cause by talking with the AI assistant. Besides web browsers, it operates desktop applications on macOS and Windows.

For companies, you can start with a PoC that replaces one robot that keeps stopping with Kitewell in two weeks (¥300,000, excluding tax). If the agreed success criteria are not met, you pay nothing. A PoC covering several tasks is also available. See Pricing & PoC for details.

Summary

Do not replace everything at once. Move the bots that stop often and hurt most first
Set the order by how often a bot stops, the impact of a stop, and the effort to fix it
Do not copy scenarios operation by operation. Rewrite them in the language of the work, with the decisions and checks spelled out
Set success criteria before starting the PoC
Run in parallel through a busy period, switch over when the agreed criteria are met, then tidy the ledger and accounts