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.

Who looks after it afterwards

An integration is never finished the day it goes live. The other vendor changes a field, retires an old version of its API, or expires an access key, and the sync stops. Nothing in your system is broken. The thing it depends on moved.

Settle three things before launch. The access keys and accounts belong to your business, not to whoever built the connection, and someone on your side knows where they are. There is a named person who gets the alert when a sync fails, and it is not a shared inbox. And there is a one-page note saying what the integration does, what it touches and how to switch it off. That last item matters more than it sounds: being able to pause it safely at 6pm on a Friday is worth more than any feature.

If nobody on your side will own that, say so at the start. It changes whether the integration should be a small custom build or a native connector that its vendor keeps working.

When you should not build the integration

Check whether the two tools already connect. Many accounting, CRM and e-commerce products ship a native connector, or one through a marketplace. If it covers your case, use it. It is maintained by someone else, and that is worth more than a better fit you have to maintain yourself.

If the volume is a few records a day, a person doing it is also an answer. Ten minutes of copying is cheaper than a system that needs monitoring, and the manual version never silently fails. Build it when the copying has become a task someone dreads or gets wrong, not before.

We would rather tell you that on a call than quote you the plumbing.

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.