Most integration failures aren't dramatic. There's no outage, no error page, no alert. The job runs. The log says success. And somewhere downstream, a record is wrong, a total doesn't reconcile, or a payment sits in a queue no one is watching.
This is the pattern we see most often: integrations that passed UAT, went live on schedule, and then slowly degraded over the following weeks and months. Not because the code was bad, but because the assumptions baked into the design stopped being true.
The gap between test and production
Test environments are controlled. Vendors send you clean, consistent sample data. Your team runs the same scenarios until they pass. Everyone signs off.
Production is different. Real documents have formatting inconsistencies. Vendors update their APIs without telling you. A field that was always populated turns out to be optional. Volume spikes on month-end. And the integration, designed around the test environment you actually had, quietly starts to fail around the edges.
The integration didn't break — the world changed, and the integration had no way to handle it.
The three early warning signs
1. Totals that need manual reconciliation
If your team is running a monthly (or weekly, or daily) process to reconcile what went through the integration against what the source system sent, that's the integration telling you it isn't reliable enough to trust on its own. The manual step exists because someone, at some point, discovered the numbers didn't add up.
2. Exception queues that are always full
Most integrations have some form of exception handling — records that couldn't be processed get held for review. A small, stable exception queue is normal. An exception queue that's always growing, or that people have stopped clearing because it moves too fast, is a sign that the integration is processing less than it appears to.
3. Institutional knowledge in one person's head
If there's one person in finance or IT who "knows how it works" and everyone routes questions through them, the integration has a single point of failure that isn't technical. When that person leaves, or is on holiday, or just gets busy, the system's fragility becomes visible.
Why it happens after go-live specifically
Go-live is the moment pressure peaks and attention moves on. The implementation partner closes out the project. The internal IT team moves to the next initiative. Finance gets back to running close. And the integration — now in the wild, processing real data, exposed to real variance — is on its own.
The integrations that stay stable after go-live are the ones that were designed with production variance in mind: documented assumptions, monitoring on the data flows that matter, and someone accountable for the outcome beyond day one.
What early intervention looks like
Catching integration drift early is almost always cheaper than rescuing it after something breaks visibly. The process is straightforward: trace the data from source to destination for a representative sample of real transactions, compare what the integration thinks it processed against what actually arrived, and document where the gaps are.
In most cases, the problems cluster around a small number of failure modes — a specific vendor format, a particular transaction type, a field mapping that was wrong from the start. Fix those, add monitoring to catch recurrence, and the integration becomes stable.
The alternative is to wait until a close process fails, or a payment run errors, or an audit finds a reconciliation gap that traces back eighteen months. At that point, you're not doing maintenance — you're doing a rescue.