Why integration projects overrun, and what discovery should actually produce
Nine out of ten overruns we are asked to rescue trace back to field mapping that was never written down.
The overrun is almost always in the mapping
When we are called in to rescue a late integration, the code is rarely the problem. The problem is that nobody wrote down what “customer” means in each system, so the build keeps discovering new edge cases — a second address type, a tax exemption flag, a currency that rounds differently.
What a discovery document contains
A system-by-system inventory, a direction for every flow, a field-level mapping table with one owner per field, the awkward cases named explicitly (tax, discounts, multi-currency, partial states), and acceptance criteria written as testable statements.
Why it is worth paying for separately
Charging discovery as its own fixed fee forces it to be finished before the build is quoted. That is the whole point: the specification is the deliverable that makes the build predictable, and you keep it whether or not you proceed.
Planning an integration?
Send us the two systems and the record types involved. We will come back with an outline scope and the approach we would recommend, within one working day.