The hardest part of integration is rarely technical. It is changing a wheel while the car is moving: the legacy system still has to serve customers every day while you wire the new one in.
Four ways to connect, in the order you should try them
The principle: always choose the least invasive option that still solves the problem. Each step down this list adds risk.
1. The legacy system has an API — use it
The easiest case, and the rarest. Check three things before celebrating: whether the API has rate limits, whether it returns all the data you need, and whether anyone guarantees it will not change without notice.
2. No API, but the database is reachable
Read directly from the legacy database. Use a read-only account, without exception. The main risk is that when the legacy system is upgraded and its table structure changes, your integration breaks silently until someone complains. Build automated daily checks so you find out first.
3. File exchange
Old-fashioned and surprisingly effective. The legacy system exports CSV on a schedule, the new system ingests it. The advantages: nothing inside the legacy system is touched, discrepancies are easy to inspect, and everyone can understand what is happening. The drawback is that data is not real time. If the business can tolerate 15 minutes or an hour of delay, this often gives the best ratio of benefit to risk.
4. Wrap the legacy system in an API layer
Build a service that sits in front of the legacy system, exposes a modern API to everything new, and internally talks to the old system by whatever means works. The most effort, but worth it when several systems will need to connect, or when you plan to replace the legacy system gradually over the next few years.
Three questions that determine the architecture
| Question | If the answer is... | Then choose |
|---|---|---|
| How fresh does the data need to be | Real time | API or wrapper layer |
| Minutes to hours | Files or scheduled database reads | |
| One-way or two-way | One-way | Simple; any approach works |
| Two-way | You must define the source of truth per field | |
| How much longer will the legacy system live | Under 2 years | Do the cheapest thing; do not over-invest |
| Over 5 years | A proper wrapper layer pays for itself |
Two-way sync: where things fall apart
When both systems can edit the same data, sooner or later both will edit it at the same time with different values. This is not an edge case. It will happen.
The only durable solution is to decide in advance, field by field, which system is authoritative. Customer address follows the CRM; outstanding balance follows the accounting system. When a conflict occurs, the non-authoritative side is overwritten and the system logs it for someone to review.
A rule not worth breaking
Never let two systems freely edit the same field without deciding who wins. If you cannot decide which is authoritative, that is a sign the business process is unclear, and no technical architecture can fix that.
Deploying without disruption
- Run in parallel before cutting over. Let the new system run alongside the old for at least two weeks, comparing output daily. Every discrepancy must be explained before you switch the old one off.
- Migrate one group at a time. Start with a single department or a small group willing to accept some risk. Learn, then expand.
- Prepare the way back. Before every cutover, be able to answer: if this fails, how long does it take to return to the previous state, and who decides to roll back.
- Do not cut over on a Friday. It sounds trivial, but it is hard-won industry experience. Cut over on a Tuesday and leave three working days to handle what surfaces.
The thing people forget: dirty data
A system that has run for ten years accumulates inconsistency: the same customer under three records, phone numbers in every conceivable format, dates left blank. New systems usually have stricter constraints and will reject this data.
Survey data quality at the start of the project, not when migration day arrives. In many integration projects, cleaning the data takes longer than writing the code.
Written from the team's hands-on experience delivering infrastructure and software. No sponsorship, no product placement.