Two systems, one customer, two different addresses

Integration is scoped as connecting two systems. The connection is the easy part. The part that decides whether it works in a year is a question that sounds administrative and is not: which system owns each piece of information?

Both systems will eventually disagree

If your CRM and your ERP can both edit a customer address, one day they will hold different ones. Neither system is broken. A salesperson updated one and finance updated the other, and the sync applied whichever arrived last.

Then the invoice goes to the old address, and the argument that follows is about the integration, when the integration did exactly what it was told.

The fix is a decision made before anything is built: for each shared field, one system writes and the others read. Not "they sync both ways", which is not a design, it is a description of the symptom.

The three failure modes

Silent divergence. Both systems look correct in isolation and hold different values. Nobody finds out until a customer does. This is the expensive one because it damages trust in both systems at once, and it is the default outcome of two-way sync without ownership rules.

Loud coupling. One system goes down and the other stops working, because nothing was designed for the other end being unavailable. Real integrations queue, retry, and degrade. Demo integrations assume a working connection, which is why they demo well.

Quiet failure. The connection breaks, nothing errors visibly, and records simply stop flowing. Discovered a month later by someone wondering why the report looks thin. Any integration worth building tells someone when it stops.

The questions to settle before anyone writes code

• Which system owns each shared field? One page, one table.
• What is the record of truth for identity? When the same customer exists in both systems, what makes them the same customer? Email, tax number, something internal? Get this wrong and every downstream report is wrong in a way that is very hard to unpick later.
• What happens when the other end is down? Queue, retry, drop, or alert. Pick deliberately.
• How do we know it is working? Not "it errored", but "nothing has flowed in four hours and that is unusual".
• What does reconciliation look like? Every integration drifts eventually. A way to compare both sides and find the differences is worth building on day one, and it is the thing most often left out.

On systems without a real API

Some products expose a good API, some expose a file drop, some expose neither and need a scheduled export. All three can work. What differs is how gracefully each fails and how quickly you find out.

The mistake is not choosing the file-based route when that is what exists. It is presenting it as equivalent to a live integration, then being surprised by a lag that was always inherent to it. State the limits up front and the constraint is manageable.

What to do this week

Take your two most important connected systems and write the field-ownership table. One column per system, one row per shared field, and a mark against whichever one is allowed to write. If the table cannot be completed without a meeting, that meeting is overdue, and it is cheaper than the invoice going to the wrong address.

Where this goes next

Integration is one of six workstreams in what software implementation actually covers. Identity and duplicate records are where it meets migration, covered in data migration is the project. If a project is already blocked on this, what to do when an implementation stalls covers which shape of stall it is.