Legacy system integration is the work of connecting an older system to modern applications so they can share data and functions without the old system being rewritten first. The common routes are reading its database, exchanging files, adding a message queue, wrapping it in an API, translating through an anti-corruption layer, or capturing its data changes.
Integration is one of the options in legacy system modernization: the one that keeps the old system and builds around it. This post covers what the terms mean, seven patterns side by side, and the challenges that break integrations once they're live.
- Legacy system integration connects an old system to modern applications so they can share data and functions, without rewriting the old system first.
- A legacy API is an older interface: a SOAP service described by WSDL, a remote procedure call, a scheduled file exchange, or a superseded API version.
- There are seven common integration patterns, from reading the database directly to automating the screens. Each fits a different system and carries a different risk.
- Most integration failures trace back to what nobody wrote down: what the data means, when batches run, and which side owns each business rule.
What is legacy system integration?
Legacy system integration means getting a system you can't easily change to exchange data and functions with systems you can. The old system usually stays the system of record for something important, such as accounts or orders, and newer applications need to read from it, write to it, or react when it changes.
It isn't migration. A migration moves the system or its data somewhere else; an integration leaves it in place and connects to it. The two often meet, because an integration layer is frequently the first step of a gradual replacement.
What is a legacy API?
A legacy API is an older interface a system offers to other software, built on a technology or version that newer applications no longer use by default. It usually takes one of four forms:
- SOAP web services, described by a WSDL file and exchanging XML messages.
- Remote procedure calls in an older framework, where the caller runs a function on the server as if it were local. If yours is a WCF service, see our post on WCF in .NET Core.
- File exchange: fixed-width or CSV files dropped in a folder or sent by FTP on a schedule. It's an interface even if nobody calls it one.
- A superseded version of a current API, such as a v1 endpoint some callers still depend on.
Age isn't the problem. A legacy API becomes one when nobody can describe its contract, or when the technology under it is past vendor support.
Legacy system integration patterns, compared
Screen automation comes last because it's the last resort.
| Pattern | How it works | When it fits | Risk |
|---|---|---|---|
| Direct database access | The new application reads, and sometimes writes, the legacy tables | Read-only reporting on a stable, understood schema | Schema changes break it, and writes skip the rules in the application code |
| File and batch exchange | One side writes a file on a schedule; the other loads it | The old system already produces files, and hours of delay are fine | Late, partial or duplicate files nobody notices until a report is wrong |
| Message queue | Systems send messages through a broker instead of calling each other | Either side may be down or slow, and work can wait a moment | Messages processed twice or out of order unless both sides allow for it |
| API facade or wrapper | A new service exposes a modern API and calls the old system behind it | New applications need the old system's functions, not just its data | The wrapper inherits every quirk underneath |
| Anti-corruption layer | A layer translates between the old system's model and the new one's | The two describe the same things differently, often during a staged migration | Business rules creep into the layer, and every call gains a hop |
| Change data capture | Changes are read from the legacy database's transaction log and published | Other systems need to react to changes without touching the old code | Events show what changed in a table, not why |
| Screen automation | A script drives the old user interface as a person would | No API, no database access and no source code | Breaks when a screen changes, and is hard to monitor |
What Microsoft's pattern pages add
Microsoft's Azure Architecture Center describes the anti-corruption layer pattern as a way to "implement a facade or adapter layer between different subsystems that don't share the same semantics," and credits Eric Evans's Domain-Driven Design with first describing it. It notes that legacy systems "often have quality problems like convoluted data schemas or obsolete APIs," and says to "avoid placing business rules or orchestration in the layer." Take that warning seriously: a translation layer is the easiest place to patch a rule nobody wants to fix in the old system.
The strangler fig pattern uses integration as a way out. It says to "incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services," with a façade that "intercepts requests that go to the back-end legacy system" and routes each one to old or new code. For calls that cross between the two, the page recommends an anti-corruption layer, and for database-centric systems it mentions change data capture.
Legacy system integration challenges, and how to reduce each
These six problems break integrations after the demo.
| Challenge | What goes wrong | How to reduce it |
|---|---|---|
| No API at all | Every integration has to touch the database, the files or the screens | Pick the least invasive route, and put a facade in front so callers never depend on it |
| Undocumented data model | Columns mean something other than their names, and codes are decoded in the application | Read the code that writes each table before anything reads from it, and write down what each field means |
| Batch timing | The new application expects data now; the old one updates overnight | Agree in writing how stale each piece of data may be, and show its age to users |
| Authentication | The old system knows only its own accounts, or one shared service login | Give each integration its own account with the least access it needs, and log every call |
| Transactions across systems | A change succeeds on one side and fails on the other, with no shared rollback | Make each step safe to retry, record what was sent, and reconcile both sides on a schedule |
| Rules duplicated on both sides | The new application recalculates what the old one decides, and the two drift apart | Decide which system owns each rule, and have the other ask instead of recomputing |
The last two fail quietly, and surface weeks later as numbers that don't reconcile.
Every row comes back to one gap: someone has to know what the old system actually does before anything connects to it. Before you rewrite a legacy system explains why the code is the only reliable specification, and our software architecture review checklist shows how to find the connections nobody documented.
What the 30-day assessment settles before you connect anything
Choosing a pattern depends on facts: what the old tables mean, where the rules run, and what already connects to the system, including what nobody listed. The 30-day assessment establishes those facts for one system. It's fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map every connection in and out, trace where the business rules sit, find the hidden architectural debt, and flag the security and compliance gaps.
The report says in plain language what is broken and what it would take to fix it, including which integration patterns the system can support safely. Your own team can build from it, or we can do the work as a separate project with its own scope and price. The report stands on its own.
To find out whether it fits, send one sentence about the system and what needs to connect to it to spaudel@aicoservices.com. If a narrower check would answer the question, we'll say so.