How do you connect two systems that were never designed to talk to each other?

The four routes, best first

1. A documented API. If both systems publish one, this is the answer. It is versioned, it is supported, and when the vendor changes something they usually tell you. Ask for the docs before anything else: a vendor who cannot produce them has effectively answered the question.

2. A scheduled export and import. One system writes a file, the other reads it, on a timer. Unglamorous and extremely durable. Most vendors that lack an API will still let you schedule a CSV export, and most will let you import one.

3. A shared database or file drop. Where you control both ends, or where a system will read from a folder. Fine, but you are now responsible for the contract between them, because nobody else is.

4. Screen-level automation. Software driving the user interface as a person would. It works, and it is the most fragile thing on this list: a layout change breaks it silently. Legitimate as a last resort for a system with no other way in, never as a first choice.

Real-time is usually the wrong default

Ask what actually happens if the data arrives four hours later. For a claim, an invoice or a booking, the honest answer is very often nothing at all — the work is picked up in batches by a person anyway.

Real-time costs more to build, more to host, and far more to debug, because a failure at 2am is a failure nobody sees. A nightly job that emails you when it does not run is simpler, cheaper and easier to trust.

Insist on real-time only where a human is genuinely waiting on the other end of it.

What actually breaks

Integrations rarely fail loudly on day one. They fail quietly in month seven.

• Credentials expire. A token with a 90-day life will stop the whole thing on a random Tuesday.
• The schema drifts. Someone adds a mandatory field at one end and the other end has never heard of it.
• Volume changes shape. A job that handled 200 records fine times out at 2,000.
• It fails silently. The worst case by a distance: everything looks fine and nothing has moved for a fortnight.

The fix for all four is the same and it is boring: log every run, count what moved, and alert when the count is zero. On a rebuild we did for a property platform, structured logging is what exposed that over half the daily work was being silently abandoned — nobody had noticed, because nothing had ever errored. The case study covers what else it turned up.

Questions to ask before anyone starts

• Does either system have an API, and can I see the documentation?
• What is the real tolerance for delay — minutes, hours, or overnight?
• Which system is authoritative when the two disagree?
• What happens to a record that fails to transfer? Retried, queued, or dropped?
• Who is told when it stops, and how?

That third question causes more grief than the rest combined. Two systems holding the same customer with different addresses is not an integration problem, it is a decision nobody made.

When the answer is not to integrate

If the data moves ten times a month, a person moving it is cheaper than any system, and the honest recommendation is to leave it alone. If both systems are being replaced next year, integrating them now is work you are paying to throw away.

Worth pricing the manual version before deciding — the costing method takes about twenty minutes and sometimes ends the conversation in your favour.