The Hidden Cost of Legacy Integration (and Where the Budget Really Goes)

Transformation programmes rarely fail on strategy. The board approves a sound plan, the platform is well chosen, the architecture diagram holds together. Then the timeline slips and the budget moves, and when we are brought in to find out why, the money has almost never gone where the slide said it would. It drained into integration — the unglamorous work of connecting systems that were never designed to talk to each other.

This is the line item nobody scopes honestly, because it does not demo. It is also, in most programmes we have audited, the silent majority of the spend.

Where the money actually goes

When a transformation stalls, the new platform is usually fine. The overrun lives in the connective tissue around it: extracting data from a system whose owner left years ago, reconciling two definitions of the same customer, mapping fields that almost match, and handling the dozen ways a flow can fail between the new application and the legacy estate it depends on.

None of this appears in the headline business case. The plan funds the platform. It assumes the platform will simply receive clean data from everything around it. In a regulated enterprise with thirty years of accumulated systems, that assumption is where the budget quietly goes to die.

The platform gets the attention; the integration layer decides the outcome

Procurement evaluates platforms. There are feature comparisons, reference calls, and proof-of-concepts. But a platform is one node. Whether the programme succeeds is decided in the layer between the nodes — how reliably the ERP, the identity provider, the partner network, the document store, and the new system exchange data under real load.

We have watched well-chosen platforms fail because that layer was treated as an afterthought, and we have watched modest platforms succeed because it was engineered first. The integration layer is not where the excitement is. It is where the outcome is.

How point-to-point becomes the most expensive line nobody owns

The first integration is cheap. So is the second. The trouble is the shape they take. Each one is built point-to-point, directly wiring one system to another with its own authentication, its own error handling, and its own undocumented assumptions. By the twentieth, the estate is a web of bespoke connections, many written under deadline by people who have since moved on.

Now every change ripples. A schema update in one system breaks three integrations whose owners cannot be found. A partner rotates a credential and a batch silently fails over a weekend. Nobody owns the web, because it was never built as a thing — it accreted as a side effect of projects that each considered their own connection finished.

Why it stays hidden

This cost is invisible precisely because it is distributed. It never shows up as "integration: $X." It is smeared across every project as a few extra weeks here, an unplanned fix there, a support rota that grows without anyone deciding it should. It is technical debt that compounds with interest, and it compounds in the one layer no single budget owner is accountable for.

The shift: integration as governed, reusable infrastructure

The alternative is to stop treating integration as a one-off connection and start treating it as infrastructure with an owner. That means API-led connectivity and event-driven patterns instead of direct wiring — reusable services that are versioned, documented, monitored, and governed centrally, with retry logic and observability designed before the happy path rather than bolted on after the first outage.

This is where platform depth earns its place. Across webMethods and modern iPaaS estates — Integration Server, Trading Networks, API gateways, and event streaming — the discipline is the same: build a backbone that absorbs the next system instead of negotiating it from scratch. When integration is a governed asset, the cost curve bends the right way. The second integration reuses the first. The tenth is routine. Partner onboarding stops being a project. Strong enterprise integration turns a recurring, unowned cost into infrastructure that pays back every time it is reused, and governed API management is what keeps that reuse safe as the estate grows.

What an integration audit actually surfaces

When we are asked to find the overrun, the pattern repeats across sectors. There are usually two or three definitions of the same core entity — a customer, an asset, a regulated party — each authoritative in a different system and reconciled by a nightly job that someone wrote years ago and no one fully understands. There is a batch window that everything depends on and nobody is allowed to touch. There are point-to-point feeds that exist only because a project needed them once, still running, still consuming support effort, long after that project closed.

The common thread is that none of it was designed as a whole. Each piece was a reasonable local decision. Together they form an estate where the true cost of any change is unknowable until you make it and something three systems away breaks. That unpredictability is itself a cost. It is why estimates in these environments carry such large contingencies, and why the contingencies still get consumed.

The integration tax on every new project

There is a tax that never appears on an invoice. Every new initiative in a poorly integrated estate pays it: weeks spent understanding undocumented connections, careful work to avoid disturbing flows no one can fully explain, and defensive testing against ripple effects that should not exist in the first place. Multiply that across a portfolio and it dwarfs the cost of any single platform. Reducing that tax — making the next project cheaper than the last rather than more expensive — is the real return on treating integration as infrastructure.

Event-driven, not just request-response

Part of the shift is architectural. Point-to-point and batch reconciliation assume systems must ask each other for state on a schedule. An event-driven backbone lets systems publish what changed and lets interested consumers react, which removes whole categories of nightly job, stale-data bug, and tightly coupled dependency. It is not the right answer everywhere, but where it fits, it turns a fragile chain of scheduled extracts into a stream that is observable and replayable by design.

Close

Most of the real work of transformation is this shift — from connecting things once to building a layer that does not have to be rebuilt every time something new arrives. The platform gets the headline. The integration layer decides whether the headline was true. If your last programme cost more than it should have, this is almost certainly where it went, and it is the first place we would look.