"Both systems have an API, so integrating should be quick." It is one of the sentences we hear most in a first conversation, and it is a reasonable one, but the existence of an API only answers the easiest question. The real cost of an integration lives in four other places.
1. Which one is the source of truth?
If a customer exists in both systems and their phone number differs, which one is right? The question sounds trivial and it is the one that delays projects the most. It needs an answer per field, not per entity: it is common for the CRM to be the source of truth for contact details and the ERP to be the source of truth for credit, within the same record.
Without that definition spelled out, the integration turns into a ping-pong where each sync overwrites the previous one. The classic symptom is data that "comes back" on its own after being corrected.
2. What happens when it fails halfway?
An integration that only works on the happy path is fine for a demo, not for production. The questions that need answers before writing code:
- If the second system is down, does the order queue up or is it rejected?
- If the same message arrives twice, does it create two records or one? (idempotency)
- If the record fails because the data is invalid, who is notified and where does it sit until it is fixed?
- After how many retries does the system give up, and how does anyone find out?
Handling that costs more than the main path. The error logic is often larger than the success logic, and it is what decides whether the integration survives its first month in production.
3. Do the two systems agree on what the fields mean?
A difference in format is easy: dates in two standards, amounts with a period or a comma. That is solved with conversion. The expensive one is a difference in meaning.
A common example: one system calls an order "invoiced" at the moment the invoice is issued; the other, at the moment payment is confirmed. Both use the same word and neither is wrong. The integration has to choose, and that choice changes reports, commissions and cash projections. No API documentation warns you about it; it only surfaces by talking to the people who run the operation.
4. Who maintains it when one side changes?
An integration can break without anyone having touched it. The vendor on the other side releases a new version, deprecates a field, changes a rate limit, and what had worked for months stops working.
That means an integration has a maintenance cost, not just a build cost. Projects that ignore this deliver the integration and find out six months later that nobody owns it.
How to genuinely reduce the cost
Three technical decisions reduce that cost more than anything else:
- Sync by event, not by sweep. Pulling everything every so often is simple to write and expensive to operate. Reacting to changes cuts volume and latency at the same time;
- Log everything that comes in and goes out. Without a log of the original message, investigating a discrepancy is guesswork. With one, it is a query;
- Isolate the integration behind a layer of its own. When the other side changes, you edit one place instead of hunting for calls scattered through the code.
When not to integrate
Sometimes the honest answer is not to integrate. If the workflow happens three times a month and takes two minutes by hand, automating it costs more than it saves and adds one more part that can break. Integration is justified by volume, by the risk of human error or by the need for real time. Without any of those reasons, the manual process is the right choice.