Where integration projects go wrong

Integrations are quoted as plumbing. Take the data from here, put it there, done — a week, maybe two.

Then they take two months. Not because the connection was hard, but because halfway through, somebody asks a question nobody had asked before: when these two systems disagree about a customer's address, which one is right?

That question has no technical answer. It is a decision about how the business runs, and it is the reason integration estimates are wrong so consistently.

The four questions that decide the timeline

Answer these before anyone writes code and the estimate becomes reliable. Skip them and the project will stop while they get answered anyway, usually in week five.

Which system is the source of truth? For each field, not in general. The CRM may own the phone number while accounting owns the billing address. If both can edit both, you have not integrated two systems — you have built a way for them to overwrite each other.

What happens when they disagree? They will, within days. Newest wins? One always wins? A human decides? "That should not happen" is not an answer; it is a bug waiting for a customer to find.

What happens when one is down? Queue and retry, or fail and alert? Silent failure is the worst outcome and the default one — data stops flowing and nobody notices until a month-end report is wrong.

What about the history? The records that already exist, in two shapes, with duplicates and typos. Migrating them is frequently larger than the integration itself and is almost never in the quote.

Connecting two systems takes days. Agreeing what they mean takes weeks, and that work does not disappear because nobody scheduled it.

What makes one genuinely hard

No real API. Screen-scraping or file drops. It works and it breaks every time the other side changes something, with no warning.

Rate limits. Fine in testing with fifty records, a wall at fifty thousand.

Different models of the same thing. One system thinks an order has one address; the other allows several. There is no correct mapping, only a decision with consequences.

Anything involving money. A double-charged customer is not a bug report, it is a refund and a lost relationship. Payment integrations deserve their own timeline.

How to scope one properly

Start with one direction. Two-way sync is more than twice the work, because every conflict case doubles. Most businesses that ask for two-way need one-way and a link.

Start with one record type. Customers, then orders, then invoices. Three small integrations that each work beat one large one that half works.

Make failure visible. A screen showing what synced, what did not, and why. This is the part cut when budgets tighten, and it is the part you will need at 6pm on a Friday.

Run both in parallel first. For a week, do it the old way and the new way, and compare. Every integration we have seen reveals something in that week.

The question worth asking first

Does this need to be automatic, or does it need to be *visible*?

A surprising number of integration requests are really reporting requests. Someone wants to know the state of things across two systems — and a read-only view that pulls from both is a fraction of the cost of syncing them, with none of the conflict problems.

The same test applies as with any automation: can you describe the rule completely, including the exceptions? If writing it down starts an argument, the problem is not integration. It is that nobody has agreed what the process is.