What an ERP integration really costs, and why the estimate is usually wrong

Integration projects have a reputation for overrunning, and it is deserved. Not because connecting two systems is technically hard, it usually is not, but because the estimate is made against the part that is visible and the cost sits in the part that is not.

The code is the small part

Writing the thing that moves data from one system to another is a few days of work. In a typical integration, that is maybe fifteen per cent of the effort. The rest is spent on four things that nobody puts in a proposal.

• Getting access. Credentials, sandbox environments, an API user with the right permissions. In a large ERP this can take weeks and it is not in your control.
• Finding out what the data actually looks like. The documentation describes the intended data. The live system contains what fifteen years of users actually typed.
• Deciding what happens when they disagree. Two systems hold the same customer with different addresses. Which wins? Somebody has to decide, and that somebody is usually in a meeting next week.
• Handling failure. What happens when the far end is down, slow, or returns half an answer. This is the part that separates an integration that runs for years from one that silently stops on a Tuesday.

The question that predicts the cost

Before anyone quotes, ask one thing: does the system on the far end have a documented, supported API that we can get access to this month?

If yes, the project is small and predictable. If the answer involves a consultant, a licence upgrade, or a middleware product you do not own, the project has just changed shape and the honest response is to re-estimate, not to absorb it.

Where there is no API at all, scheduled file exchange is still a perfectly good answer. It is unglamorous, it is how a surprising amount of serious infrastructure actually works, and it is far better than a brittle screen scraper that breaks at the next upgrade.

Rough bands

• One way sync of one object, good API: a week or two of work.
• Two way sync with conflict rules: three to five weeks, and most of it is the rules.
• Several objects across two systems with reconciliation and reporting: two to three months.
• Anything where the far end has no API: add the time it takes their vendor to respond, which is not yours to promise.

The mistakes that cost the most

Syncing everything. Most integrations only need a handful of fields to move. Ask what decisions depend on this data, then move only what those decisions need. Every extra field is an extra thing to map, test and maintain forever.

Real time when nightly would do. Real time sounds better and costs several times more. If the business reads the number once a day, sync it once a day.

No monitoring. An integration that fails loudly is an inconvenience. An integration that fails quietly is a data corruption incident you discover at quarter end. Alerting is not a nice to have on this kind of work, it is the difference between an asset and a liability.

What a good integration proposal contains

• The exact objects and fields moving, in a table, both directions
• What happens on conflict, written as rules, not as a principle
• What happens on failure, including who gets told
• Who is responsible for getting API access, and what the date slips to if it is late
• How it will be tested against real data rather than sample data

If a proposal does not contain the fourth item, the project has an unowned risk in it, and unowned risks become arguments. We put it in writing because the alternative is discovering in week three that nobody was chasing the vendor.