Why teams migrate
RPA was built to automate work through the same screens people use. That made it possible to automate systems with no API, and it still is the right tool for that. The trouble starts when bots are used on systems that do have APIs, or on work that needs judgment.
Brittleness. A bot finds fields with selectors. When a vendor moves a button, adds a login step or renames a field, the bot stops. Maintaining a large bot portfolio becomes a job in itself.
Unstructured input. Many processes start with an email, a PDF or a scanned form. Template OCR handles a few fixed layouts. A language model reading into a fixed schema handles many layouts, as described in our document data extraction guide.
Exception volume. Rule-only bots push every case that does not fit the rules to a person. An AI step can classify and resolve many of those, leaving people the truly unusual ones. For the broader trade-offs, see RPA vs AI agents.
The migration plan
- Inventory. List every bot with its process, applications touched, run volume, exception rate, maintenance hours over the last year and whether each application has an API.
- Prioritize. Score each bot on exception rate, breakage frequency and API availability. Move the high scorers. Leave stable bots on legacy screens alone.
- Redesign the process. Do not copy the click path. Map what the process needs to read, decide and write. Use API calls for reads and writes, deterministic rules for policy, and a model only for judgment steps.
- Rebuild. Build the workflow in n8n or code, wrap each API as a tool with a narrow purpose, validate model outputs against a JSON schema, and send low-confidence or high-value cases to a review queue.
- Run in parallel. Let the bot keep doing the work while the new workflow runs in shadow mode, writing its decisions to a log. Compare decisions case by case for at least two to four weeks.
- Cut over. Switch by segment, such as one vendor group or one region at a time, keeping the review queue on for all cases at first and narrowing it as accuracy is proven.
- Decommission. Retire the bot, its machine, its service account and its license. Keep its documentation for audit.
What to watch for
- Credentials and access. Bots often log in with a person-like account. APIs need proper service credentials, OAuth apps or API keys, and some systems require a partner program or vendor approval before API access is granted. Start those requests early.
- In-flight queue items. Let the RPA queue drain, or mark items so the new workflow does not pick up work the bot already started.
- Duplicates. During the overlap, make sure only one system writes. Check a unique key, such as an invoice number, before every create.
- Webhook and trigger changes. If the bot ran on a schedule, the new workflow may run on events instead. Update upstream systems to call the new webhook URL, and confirm timing assumptions downstream.
- Error handling. Define what happens on API failure, model timeout, schema validation failure and low confidence. Every path should end in a retry, a review queue or an alert, never silence.
- Model cost and drift. Track cost per case and accuracy weekly. Re-run your test set whenever you change the model or prompt.
Timeline and cost
Replacing a portfolio of bots with 5–15 API workflows is an automation program, typically $15,000–$50,000 over 4–10 weeks. A single process that needs a true agent, with several tools, document reading and a review interface, fits our custom AI agent band of $15,000–$60,000 over 3–8 weeks. Our cross-vertical automation case study shows automation spread across several business functions, and the custom AI agent cost guide explains the drivers.
What we recommend
Keep RPA where it is the only way in. Replace it where APIs exist or where judgment drives the exception rate. Move one process at a time, run it in shadow mode, and keep a person in the loop until the numbers say otherwise.