The integration debt you’re probably not budgeting for

Every digital project has a budget line for the software. Almost none has a budget line for the connections.

Integration debt is the accumulated cost of connections your company depends on and does not manage. It does not show up in any budget, and it comes due at the worst possible moment, usually when a supplier changes an API version on a Tuesday.

This piece is for leaders who approve digital investments and want to know what they are actually committing to. We will cover why connections multiply faster than systems, why this particular debt stays invisible, what AI connectors have changed about the maths. You’ll end up with a practical audit you can run on your own estate.

Key Takeaways

• Companies budget for systems and assume the connections between them. The connections are where the value, costs, and fragility all live.
• Each new system adds more than one connection, so complexity grows faster than the application count.
• MCP and similar standards have collapsed the cost of creating a connection. The cost of owning stayed the same, though.
• The audit is three questions per connection: What is it, who owns it, and what breaks when it stops.

Connections multiply faster than systems

Adding a system adds a connection to every system it needs to talk to. 

The sixth application in a tech stack can plausibly touch five others. The tenth can touch nine. Complexity grows with the number of relationships rather than the number of tools.

The scale is now considerable. MuleSoft’s 2026 Connectivity Benchmark Report, based on a survey of 1,050 IT leaders globally, found that the average organisation manages 957 applications and has only 27% of them connected.

So, most companies have a large number of systems and have connected a quarter of them. The unconnected majority produces the manual re-keying, the exported spreadsheets, and the “let me check that number”. Leaders experience this as slowness without ever tracing it to an architecture decision.

The connected minority produces something else. The same report found that 71% of IT leaders agree that their infrastructure makes systems overly dependent on one another.

It’s obvious that dependency was never designed, but it feels accumulated.

Why integration debt stays invisible

Three things keep this off the leadership agenda.

1. The cost is already being paid, just not where you’re looking 

The MuleSoft research found IT teams spend an average of 36% of their time designing, building, and testing custom integrations. More than a third of your technical capacity is going into plumbing. 

Because that time sits inside salaries and project overruns rather than in a line item called integration, it never gets discussed as an investment decision.

2. Failure is delayed and displaced

A connection built in March breaks in November, when a vendor deprecates an endpoint. The cost lands on a team that had nothing to do with the original project, long after the budget closed. 

This is the same pattern we described in the hidden cost of small changes. In a connected system, the visible change is the tip, and the rework is the iceberg.

3. Nobody can see the whole picture. 

This is the deepest problem, and computer science named it a long time ago. Leslie Lamport, who won the Turing Award for his work on distributed systems, wrote in a 1987 message that has been quoted ever since:

“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”

Every company running an application estate is now operating a distributed system. 

What MCP changed, and what it did not

Until recently, building an integration was hard enough to function as an accidental governance mechanism. Someone had to scope it and get it approved. The friction was annoying.

Model Context Protocol (MCP) connectors and similar standards have largely removed that friction. Connecting an AI assistant to a CRM is now closer to a configuration step than a project. In fact, the same MuleSoft research found 39% of organisations using MCP and 40% using agent-to-agent protocols.

This is useful, of course, and we use these tools ourselves. The point worth making to leaders is narrower.

The cost of creating a connection has collapsed. The cost of owning one has not moved at all. 

Someone still has to know it exists. Removing the friction removed the conversation that used to assign those duties.

So the number of connections in your organisation is about to grow a lot. The report is consistent on this: 27% of APIs remain ungoverned, and only 54% of organisations have a central governance framework for their agentic capabilities.

Two further consequences deserve your attention. 

First, each connector is a standing grant of access. The question of what an integration can reach becomes a security question rather than an architecture one, which is where NIS2 supply chain expectations start to apply. 

Second, an AI agent wired into weak data does not improve the data, a point we made in AI is a cost-saver right until it is not.

The integration debt audit

You do not need a full architecture review to find out where you stand. We blit down to three questions.

Ask your teams to write down every connection between systems, including the scheduled exports, the scripts someone wrote years ago, and the AI connectors added in the last six months. 

Then answer these for each one.

1. What is it? Source system, destination system, what data moves, in which direction, how often, and who built it.
2. Who owns it? A named person, not a department. Ideally, a name on both sides, because most connections fail at the boundary between two teams who each assumed the other was watching. This is the same ownership question that sits at the centre of an operating model.
3. What breaks when it stops? Which business process degrades, which customer or colleague notices, and how long before anyone finds out? Add the version dependency: what happens when the system on either end is upgraded.

Three rules of thumb make the results useful.

The debt is the count of connections you cannot answer question three for.

Not the total number of integrations. Plenty of connections are well understood and cheap to run. The dangerous ones are the connections whose failure consequences nobody can describe.

Sort by silence, not by importance. A connection that fails loudly gets fixed the same morning. A connection that fails in secret, where a sync stops and stale records keep flowing, corrupts data for weeks before anyone questions the report. 

Anything with no name attached is already a problem. 

An unowned connection is not a low-priority item on a list. It is a live dependency with nobody watching it.

What to do with the answer

Most organisations running this exercise for the first time find three things: 

• More connections than expected
• Several that nobody can fully explain
• At least one where the person who built it has left.

No worries, that is a normal starting position.

• Give every connection that survives the audit a named owner
• Retire the ones that turn out to serve nothing, which is usually more than you would guess
• Add monitoring to the silent ones so failure becomes loud
• Make the three questions part of what gets answered before a new integration is approved, which is far cheaper than answering them afterwards 

The Net Group view: the value is in the connections

Companies buy systems because systems are easy to describe. They have names, prices, vendors, and demos. Connections have none of that.

The uncomfortable truth is that almost all the value your systems produce is created at the moments they hand something to each other. 

Those handovers are the product. The systems are just the endpoints.

Count your connections. Name an owner for each. Find out what breaks when one stops.

If that exercise takes longer than a week, the debt is bigger than you thought.