Legacy System Integration: When to Connect vs. When to Replace

Most teams don't fail at the technical work. They fail at the decision before it starts.

One team wraps the legacy system in an API and builds around it. Two years later they're maintaining two systems and the integration layer has its own backlog. Another team picks replacement, spends 18 months on it, runs over budget, and the old system is still running because nobody felt safe turning it off.

Both outcomes are common. Both are avoidable. The difference isn't execution. It's whether you made the right call for that specific system before you started.

What you'll find here:

• What legacy system integration actually covers and what it doesn't
• The three integration patterns, where each fits, and where each stops working
• A four-criteria decision framework for the integrate-vs-replace call
• The signals that tell you replacement is overdue
• Why AI readiness is reshaping this decision in 2025-2026

What Is Legacy System Integration?

Legacy system integration is connecting an existing system to the rest of your architecture. The system was usually built years or decades ago, often without modern interfaces, and rarely with documentation that reflects how it actually behaves.

In practice it covers more than adding an API. An anticorruption layer, a strangler fig migration, middleware sitting between old and new — all of these count. What they share is that none require a full rebuild. The harder question isn't which pattern to use. It's where you draw the boundary between what you connect and what you eventually replace.

That boundary matters because integration isn't a permanent answer. Every legacy software system integration project needs a view of the exit — the point where connecting stops being viable and replacing becomes the only option left.

Why Companies Integrate Rather Than Replace

When integration preserves irreplaceable business logic

Legacy systems carry knowledge that was never written down. The billing edge case someone spent months getting right. The compliance workflow nobody fully understands but everyone is afraid to touch. The data model that reflects how your business actually operates — not how anyone remembers it.

Replacing that system requires understanding it first. Understanding it takes time, domain expertise, and access to people who may no longer work at the company. Integration sidesteps that problem. You keep the system running, expose what you need through a controlled interface, and let the rest of the architecture modernize around it.

That's not a compromise. For many systems, it's the right answer.

The hidden cost of doing nothing

Integration also gets chosen because the alternative looks expensive. A full replacement might cost $2-5 million and take 18 months. Integration looks cheaper upfront.

But "it still works" is not a legacy system integration strategy. It's a deferral. And deferral compounds. McKinsey's analysis puts tech debt at 40-50% of total IT investment spend for large enterprises. For a European bank in their research, 70% of IT capacity went to maintaining legacy infrastructure, not building anything new. The cost of inaction doesn't appear on any single invoice. It shows up in slipping release cycles, failed integration projects, and the growing gap between what the business needs the system to do and what the system can actually do.

Legacy System Integration Challenges

Missing APIs, undocumented dependencies, and data silos

The first thing most teams discover when they start a legacy system application integration project is that the system doesn't have an API. Or it has one: partial, undocumented, and understood by one engineer who is leaving next quarter.

Undocumented dependencies are the most common reason integration projects run over schedule. A team discovers mid-project that a critical billing function depends on an FTP server nobody knew existed. Or that the system writes directly to a shared database that three other systems also read from, with no clear ownership. These aren't edge cases. They're the norm with systems older than 10 years.

Data silos compound this. Legacy systems were built to own their data, not share it. Getting clean, consistent data out in a format that a modern system can consume often requires more transformation work than the integration itself.

The parallel-systems trap: when integration creates a second legacy problem

This is the failure mode nobody talks about when selling integration as a solution.

You build an integration layer. It works. The legacy system keeps running. Two years later, the integration layer has its own complexity, its own undocumented behaviour, and its own bus factor. You now have two systems to maintain instead of one. New features require changes in both. When something breaks, no one is sure which side is at fault.

This is the parallel-systems trap. It doesn't mean integration was wrong. It means integration without a decommission plan is a choice you'll pay for later. Every effective legacy-system integration project needs an answer to the question: what does the exit look like?

Legacy System Integration Strategies

The three main effective approaches to legacy system integration each serve a different situation. Choosing the wrong one for your context is where most projects go wrong.

API wrapper and anticorruption layer

An API wrapper sits in front of the legacy system and exposes its functionality through a modern interface: REST, GraphQL, or event streams, without changing the system itself. An anticorruption layer, a concept from Domain-Driven Design, goes further. It translates between the legacy system's data model and the domain model the rest of your architecture uses.

This approach works well when the legacy system is stable, has some documented behaviour, and isn't changing frequently. A 15-year-old ERP holding inventory and order data is a good candidate. You wrap it, expose what you need, and let modern services consume it. The ERP keeps running. Everything else gets built around it.

The ceiling: once you need the legacy system to change, to support new business logic or new data structures, the wrapper breaks down. You're back to touching a system nobody fully understands.

Strangler fig pattern and where it stops working

The strangler fig pattern, coined by Martin Fowler, is the standard approach for incremental replacement. You route traffic through a facade in front of the legacy system, then rebuild individual functions as modern services and redirect traffic to them one at a time. The legacy system gradually loses scope until it can be decommissioned.

It works well when business boundaries, code boundaries, and team boundaries roughly align. When they don't, the migration becomes a long chain of coordination overhead pretending to be architecture.

The ceiling: it requires keeping both systems in sync during the transition. If that transition drags on, which it often does, you end up in the parallel-systems trap anyway.

Middleware and integration platforms

Enterprise service bus, MuleSoft, Boomi, Apache Camel: these sit between systems and handle translation, routing, and orchestration. They're particularly useful when you're connecting multiple legacy systems to multiple modern targets and don't want point-to-point integrations multiplying across your architecture.

The practical limit is governance. Middleware that isn't maintained with the same rigor as production code becomes undocumented technical debt with a different name.

To automate legacy system integration at scale, these platforms offer workflow orchestration and event-driven triggers that reduce manual data handling. But automation built on top of an undocumented foundation inherits the same fragility.

Legacy system integration strategies

When to Connect vs. When to Replace: A Decision Framework

The right legacy system integration strategy is per-system, not per-portfolio. Two systems in the same organization may need opposite answers. Here are the four criteria that drive the decision.

Four criteria that drive the decision

1. Business value. Does this system encode logic that your business can't afford to lose or recreate? If yes, integration protects this logic while modernisation happens around it. If the system is principally a data store with limited business logic, replacement becomes more viable.

2. Technical health. Can the system accept change without destabilizing? A practical proxy: how long does a routine feature take in this system compared to a modern one? If the answer is a sprint vs. a quarter, the integration cost is already being built.

3. Integration complexity. Does the system have an accessible API, a readable database, or neither? No API and a shared, undocumented database are strong signals to plan for replacement rather than long-term integration.

4. AI readiness. Can this system serve real-time, structured data to an AI layer? Not eventually. Now, or in the near term. This criterion has become a de facto requirement in 2025. Systems that can't support data contracts for AI workloads are blocking capability, not just slowing delivery.

Signals that integration is the right call

Signals that integration is the right call

• The system holds business logic that would take 12+ months to reconstruct
• It's stable — low change rate, low defect rate
• It has an accessible interface (API, readable DB, documented schema)
• Replacement would require a full freeze on adjacent product work
• The team has a clear decommission plan, even if it's 2–3 years out

Signals that replacement is the right call

• The architecture can't support your next product move — not won't, can't
• The people who understand the system are near retirement and knowledge transfer has failed
• Regulatory or AI requirements the system structurally cannot meet
• Integration complexity has already exceeded replacement complexity
• The integration layer itself has become a legacy problem

When replacement is the right call, incremental still beats big bang. The TSB Bank migration in 2018, a big-bang replacement of core banking for 5.2 million customers, cost roughly £400 million, locked out 1.9 million users, took eight months to resolve, and ended with the CEO's resignation. The failure wasn't the decision to replace. It was the decision to do it all at once.

Integrate vs. replace: four-criteria assessment

How AI Readiness Is Reshaping This Decision in 2025-2026

Legacy systems aren't just a maintenance cost anymore. They're blocking AI adoption.

According to Kyndryl's 2025 State of Mainframe Modernization Survey, 500 senior IT and business leaders globally, 88% of enterprises are deploying or planning to deploy generative AI on or near legacy infrastructure. That's not a future consideration. It's a current architectural constraint.

The question has shifted. It's no longer "does this system work?" Most legacy systems work. The new question: can this system serve the data contracts an AI layer needs? Real-time access, clean structured output, low-latency response. If the answer is no, the system isn't just slowing delivery. It's blocking capability your competitors are already building.

McKinsey's analysis adds a cost dimension that changes the calculus. Generative AI is reducing modernisation costs by up to 40% and accelerating timelines by 40-50%. A replacement project that was financially out of reach two years ago may now be viable. That changes which systems belong in the integrate-and-defer column and which belong in the replace-incrementally column.

The organisations getting this right aren't treating AI readiness as a separate initiative. They're using it as one of the four criteria in every integrate-vs-replace decision, and weighting it more heavily than they did two years ago.

Closing

The integrate-vs-replace decision doesn't have a universal answer. Every system in your portfolio has a different combination of business value, technical health, and strategic relevance. That's why portfolio-wide mandates produce the wrong outcome for at least half the systems involved.

The four criteria in this article do not give you a formula. They give you a structured way to look at each system on its own terms with candid input from engineering, product and finance. That conversation, done early, is what separates projects that finish from those that stall.

Don't know where a specific system lands? Start with a dependency and cost audit before committing to anything. Two weeks looking at the right things beats six months building the wrong ones.