"Our systems are too old for this" is the most common reason teams give for not starting. It is almost never true. Nearly every legacy platform leaks data somewhere: a nightly export, a report emailed to a manager, a database a report writer already queries, a screen a person reads all day.
Four ways in, cheapest first
- 01Files and exports. If the system can produce a CSV on a schedule, you have an integration. Pick it up, process it, write results back through whatever import path already exists.
- 02Email. Documents and notifications already flow through inboxes. Parsing an inbox is unglamorous and remarkably effective, especially for invoices, orders and referrals.
- 03The database. Many legacy applications sit on a database you can read directly. Read-only access to a replica gets you most of the value with none of the risk of writing.
- 04An API wrapper. Put a thin service in front of the legacy platform exposing the handful of operations you actually need. This buys time and limits change inside the old system.
Only when all four fail does browser automation become the answer: a script driving the actual interface the way a person would. It works, and it is fragile. A UI change breaks it, and it needs monitoring in a way an API integration does not. Use it deliberately, not by default.
Keep the legacy system as the source of truth
The pattern that consistently works is additive: AI reads from the legacy system, does its work in a separate service, and writes back through a controlled path. The old platform stays the system of record. Nothing about the migration you have been postponing needs to happen first.
This is why integration projects fail slowly rather than fast: teams try to modernise the platform and add AI in one programme. Split them. The AI layer can pay for the modernisation later.
Write paths need more care than read paths
Reading is reversible; writing is not. Start read-only and generate drafts for a person to apply. Once the output is trusted, automate the write for the safe subset of cases and keep human approval for the rest. Every write path should be idempotent, meaning the same instruction applied twice leaves the system in the same state as applying it once, so a retry after a timeout cannot double-post an invoice.
Budget for the boring parts
- Character encoding and date formats from systems built before anyone agreed on either
- Duplicate records that two departments both consider canonical
- Scanned documents where quality varies by which office sent them
- The one supplier whose reference numbers do not match the documented format
None of this is AI work, and all of it is the project. Teams that plan for it ship; teams that discover it in week six do not.