Section 1
Read first, write much later
The safest and most valuable integrations are read-only. Pull data out of the legacy system, do the work elsewhere, and give a human the result. Nothing is written back, so the worst case is a wrong answer that somebody catches, not a corrupted record in the system of record. This sounds limiting until you count how much of the value is in reading. Reporting, reconciliation, alerting, summarizing, and preparing a decision are all read operations. Write access is what turns a manageable project into a risk that requires a change control process, a rollback plan, and someone senior signing off. Earn it later, on evidence, rather than designing for it on day one.
Section 2
Four ways in, ranked by durability
A documented API is best when it exists. It is versioned, it is supported, and it breaks loudly rather than silently. A database read replica is next. Direct, fast, and it isolates your queries from the production system, but you are now coupled to a schema nobody promised to keep stable. Scheduled file exports are third and are the workhorse of real integration projects. Unglamorous, reliable, and easy to reason about, at the cost of working with data that is hours old. Screen automation is last. It works, it demos well, and it breaks whenever the interface changes by a pixel. Use it when there is genuinely no alternative, and treat it as temporary even if it lasts three years.
Section 3
The system of record does not move
Decide explicitly which system holds the truth, and it should almost always remain the legacy one. The automation layer produces drafts, suggestions, and views. When two systems both believe they are authoritative, you have not integrated anything. You have created a reconciliation problem that will consume more time than the automation ever saved.
Section 4
Building the first connection
Pick one report or one repetitive lookup that people currently do by hand in the old system. Measure how often it happens and how long it takes, including the waiting. Build the read path first and run it in parallel with the manual process for a few weeks. This catches the thing that always exists in legacy data: the field that means something different for records created before a particular date, the status code that only three people know is deprecated, the customer who appears twice. Every legacy system has these. They are not documented and the only way to find them is to compare against what humans currently produce. Then put the output where the team already works rather than in a new interface.
Section 5
Access, credentials, and the people who left
Legacy environments make the access question urgent, and access is the part of the NIST framing that integration projects most often skip. Old systems frequently lack granular permissions, so the practical choice is between an account with far more access than the automation needs and a piece of work to create a restricted one. Do the work. An automation running under a broad service account is an incident waiting for a trigger. Beyond that: keep credentials out of scripts, log every read and every write against a record, and document the integration while you build it rather than afterwards. The knowledge risk is the real one here. A brittle integration nobody understands is worse than the manual process it replaced. The agency version of the same coordination problem is covered in [Marketing Agencies: Scaling with AI Automation](/blog/marketing-agencies-scaling-with-ai-automation).
Section 6
Measuring an integration honestly
Track the cycle time of the end-to-end process, not the runtime of the integration. Also track data freshness, failure rate of the connection, time spent maintaining it, and the number of manual reconciliations still happening downstream. Maintenance hours is the metric that decides whether this was worth doing. An integration saving five hours a week and consuming four in upkeep is a rounding error dressed as a project. Review quarterly and be willing to retire connections when the underlying system is finally replaced. The wider sequencing sits in [Building an AI Automation Roadmap for Your Startup](/blog/building-an-ai-automation-roadmap-for-your-startup), and [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation) covers how to explain the work to people who only see the old system.