Before you connect two systems, decide which one is right

Two systems disagree about the same number, and everyone in the building has already learned which one to distrust. That’s usually the actual starting point for an integration project, not a hypothetical risk to plan around. The decision a business owner faces before connecting an ERP, a shop and a warehouse system is not “which tool do we use to sync them” — it is “which system is allowed to be right about each fact, and what happens when two writes race for the same field.”

The problem isn’t the connection, it’s the disagreement

Most of the time nobody decided that the ERP owns stock and the shop owns orders. It accumulated, one integration at a time, until a nightly sync job resolves conflicts by whichever process happened to finish last. Nobody signed off on that rule; it’s just what the code does. A mis-picked order or a customer who buys something that was already sold out is how the disagreement eventually surfaces, usually to the customer first and the team second.

Integration work, done properly, is mostly not code. It’s a set of explicit decisions about ownership that get written down and agreed before a single API call is made.

Draw the ownership map first

For every entity that more than one system touches — product, price, stock, customer, order, invoice — write down which system is the source of truth, which systems are allowed to write to it, and what happens when two writes arrive for the same field at close to the same time. This is a spreadsheet or a page of notes, not a technical artefact, and it should be something a non-technical stakeholder can read and sign off on, because the answers are business decisions, not engineering ones. Does the warehouse’s physical count override the ERP’s, or does the ERP’s figure stand until someone corrects it by hand? Who decides, and does everyone building against these systems know the answer today?

Skipping this step doesn’t make the decision go away. It just means the decision gets made implicitly, field by field, by whichever script happens to run last — which is exactly the situation the project was meant to fix.

A bridge, not a mesh of point-to-point scripts

Once ownership is agreed, the shape of the integration follows. Every system should talk to one integration layer with a documented schema, rather than each pair of systems getting its own script that only the person who wrote it understands. A mesh grows one urgent fix at a time and becomes unmaintainable roughly in proportion to how many systems are in it; a bridge keeps the ownership map enforceable in one place, because incoming events are queued and handled idempotently — the same message arriving twice should never double a stock movement or duplicate an invoice. We go into this in more detail, including how to handle a legacy system with no usable change feed, in the ERP bridge write-up.

Make disagreement visible instead of silently resolved

Even with an ownership map and a proper bridge, systems will drift — a manual edit in one place, a batch job that skipped a record, a connector that silently failed overnight. The fix is not to pretend this won’t happen. It’s a scheduled job that compares both sides and reports the differences as a list a person can work through, instead of one system quietly overwriting the other. Drift becomes a number someone watches on a dashboard, rather than a customer complaint that triggers a investigation three weeks later. A reconciliation job that never finds anything is doing its job; one you’ve switched off because it was noisy has stopped doing it.

Rehearse the migration before you run it for real

The highest-risk moment in any integration project is cutover: the point where data actually moves from the old arrangement to the new one. That move should happen as a dry run against a copy of the real data first, with a diff report showing exactly what changed and a rollback path that’s been tested, not assumed. The real cutover should be the third time the migration has run, not the first — rehearsed enough that surprises show up on a Tuesday afternoon against a copy, not during the live cutover window when a mistake is a customer-facing outage.

A checklist before you start

• For each shared entity — product, price, stock, customer, order — has someone actually written down which system owns it, or is the answer still “whichever one is right most of the time”?
• What happens today when two systems disagree: does a person find out, or does a batch job silently pick a winner?
• Does every system talk to one integration layer, or does a point-to-point script exist that only one person can explain?
• If a message or event arrives twice, does anything break — a duplicated stock movement, a second invoice?
• Has the migration been rehearsed against a copy of real data, with a diff and a tested rollback, or is the live run the first attempt?
• Who is actually looking at the reconciliation report, and what do they do when it finds something?