Think about all those point-to-point connections, or nightly CSV exports, and those “temporary” workarounds that have survived three CTOs. You pay for it in hours of manual reconciliation or decisions made against stale data. Today it’s paid in AI initiatives that stall as soon as they start. No shaky system survives first contact with real data.
If you do nothing, the balance sheet continues to grow. Literally, how interest works.
On a typical Tuesday that might look like this: the sales team closes a six-figure deal at 10 a.m. Finance finds out on Thursday when someone runs the weekly export. Operations learns about this when the order hits the floor and nobody planned capacity for it. Multiple systems all having their own version of the truth and a handful of good people whose job title has (against their will) been renamed to: Human Middleware.
Try and find the person or team who chose this architecture and you’ll come up empty handed. It accreted. Acquisitions, departmental SaaS purchases, teams that rushed the job for the deadline and never came back to fix the leaks, private workarounds, and the dreaded “Shadow IT”. These all contribute to the wrong side of that balance sheet.
Recognizing the Problem
Expensive diagnostic tools will tell you what your team already feels. Symptoms show up every single day in the texture of how work gets done:
- The export-to-Excel reflex. Any question that spans two systems gets answered with a download, a VLOOKUP, and kinda ruins someone’s day.
- The lag. A thing happens in the business and leadership learns about it days later. Well after the information was relevant.
- The month-end marathon. Closing the books means re-deriving numbers the systems already have, by hand, under deadline, and copious caffeine.
- Competing versions of the truth. Sales, finance, and ops each bring their own numbers to the same meeting, and every one of them is “technically” right inside its own system.
- The "ask So-and-so” dependency. Those individuals who become the only working connection between these systems.
That last one is a real kicker. I wrote about breaking down data silos back in 2023, and the pattern hasn't changed much since. Except, the stakes may be a bit higher 3 years on.
If any of these feel familiar, you’re not alone. Integration debt, like its cousin technical debt, are par for the course in many enterprises. And usually we just carry on living with it.
How does compounding integration debt work, you ask?
Point-to-point connections have brutal math. Two systems need one connection. Five systems can need ten. Then add a warehouse management tool, a new CRM, a marketing automation platform, and the ERP that last year’s acquisition brought to the table. Now you have a web of one-off links or sneaker nets that nobody fully maps or owns.
Each new connection gets built in a different way. Different architectures, maybe different tooling, possibly by separate teams that don’t really talk. And in most organizations they get built as fast as possible. Because integration doesn’t always feel like it’s customer facing and is therefore just “plumbing”. The result is brittle and headache inducing.
Layer on top of this the big “digital transformation” initiative that doesn’t really tell teams how, maybe not even why, and the whole thing becomes a house of cards.
Now extrapolate over the course of years of this behavior and there’s your compound interest.
The Cost in Real Terms
The first visible line item is people. Count the hours your team spends each month moving data between systems that were supposed to talk. Exports, re-keying, reconciliation, and the inability to answer ad hoc questions without playing 4D-chess (a little topical humor there).
Run that same math across finance, operations, sales, service, and whatever other departments you’ve got. Use your own loaded costs; the number gets very uncomfortable very fast.
Decision quality is one of the quieter expenses. When reporting lags reality by days you price against last month's costs and plan capacity against last week's orders. The decisions still get made, nobody is slowing down, they're just made on stale and messy data. Nobody write’s that future note to themselves: "we chose wrong because the numbers were old, let’s not do that again.”
Then there’s the boardroom signals: questions that can’t reliably be answered, stalled initiatives, eroded trust between the technical team and management.
Perhaps even an AI initiative or two you’ve been trying to get off the ground for the last year with mediocre success. The AI model probably isn’t the issue. It’s the fragmented, inconsistent, and untimely data; integration debt with a fine point on it.
A Framework for Measuring Integration Debt
You can't pay down a debt you haven't sized. We created the Integration Maturity Index (IMI) as a diagnostic for just such a problem. It scores your organization across four dimensions:
- Data quality: whether the numbers can be trusted where they sit, and whether two systems even agree on what a "customer" or an "order" is.
- Integration architecture: how systems connect today (point-to-point patches versus a deliberate data layer) and what breaks when one of them changes.
- Governance: who owns each data domain, who fixes it when it breaks, and whether that's a person or a prayer.
- AI readiness: whether your data could feed a production AI system tomorrow: connected, current, and clean enough to act on.
Low scores on the first two dimensions cause every downstream ambition to run aground.
It’s a quick assessment, takes maybe 5 minutes, but it can tell you a lot about where your organization is on this journey.
Paying Integration Debt Down Without a Big-bang Project
Once the debt is visible the instinct is the big fix: a two-year replatforming, new ERP, consolidate everything, implement enforcement on your engineering teams. Resist all of that. A big-bang project concentrates all its risk on a single cutover while the daily pain keeps running for the life of the project. The beatings shall continue until morale improves.
Pay down integration debt the same way you'd pay down your own debt: highest interest first. Find the one connection that’s burning the most manual hours or corrupting the most decisions and fix it properly. A real integration is one that’s owned, monitored, and documented. Those three descriptors are essential and cannot be skipped or you’ll just add more debt.
I've written before about when to pay down tech debt, and the same logic holds between systems, not just inside them. It also holds for legacy systems and technical debt generally: the interest rate decides the order. Resist the urge to supplant that with “shouldn’t we fix the oldest code first.”
For most mid-market companies the destination is a shared data layer above the operational systems. ERP, CRM, WMS, the core systems; and the rest keep doing their jobs for now. The layer gives everyone a single source for the current version of the truth. This is the heart of our systems integration and data engineering work, and it's an old principle for us.
Here's an exercise worth an hour of your next leadership meeting: estimate your monthly integration-debt bill. Whatever figure you land on will initially be wrong but directional. It will also be big enough to change your roadmap. When you want the sized-and-sequenced version instead of the guess, that's what our Data Readiness Assessment is for; it's also why we rebuilt the company around senior engineers (Conductors) who own this kind of work end to end.
FAQ: integration debt
Is integration debt the same as technical debt?
No. Technical debt lives inside a single system: shortcuts in the code, outdated frameworks, or tests that never got written. Integration debt lives between your systems, in the brittle connections and manual workarounds that move data from one to another. A company can have five well-built systems and still drown in the gaps between them.
What are the warning signs of integration debt?
Routine exporting to Excel to answer cross-system questions, long lags between business events and reporting, a slow month-end close, conflicting numbers between departments, and processes that depend on one person who knows how the pieces connect.
Can you fix integration debt without replacing our systems?
Yes, and you usually should. Keep the systems that work as systems of record and build a shared data layer above them, fixing the highest-cost integrations first. Incremental paydown delivers value in weeks to months (instead of months to years) and avoids betting the company on a single cutover date.
How does integration debt block AI?
AI systems need connected, current, trustworthy data, and integration debt is the absence of exactly those three things. It's one of the most common reasons AI pilots die before they hit production: the model performs, maybe even fine-tuned, but the data feeding it is fragmented and stale so nobody can trust the output enough to act on it.