Legacy Integration

Definition

Legacy integration is the work of exposing a system's capability without modifying it, usually because modification is impossible, prohibitively expensive, or forbidden by a support contract.

The recurring constraints

• Batch cycles. The system updates overnight, so "current" means "as of last night". Any design assuming real-time state is wrong, and the correct response is to make the staleness explicit in the API rather than hide it.
• No API. Integration is via file drops, database reads, screen scraping, or a message queue from a previous decade.
• Limited capacity. The system was sized for a fixed internal load. A new consumer generating ten times the query volume can degrade the system of record for the whole business — which makes rate limiting on your side a protection for them.
• Peculiar data semantics. Fixed-width fields, packed decimals, codes whose meaning is documented in nobody's lifetime, dates that are sometimes zero.
• Change windows. Even a configuration change may require a monthly release slot.

The architecture that works

An integration service that owns the legacy relationship, presenting a modern interface and absorbing every peculiarity. Three properties matter:

1. It is the only thing that speaks to the legacy system. No other service holds a connection or knows the format. This is an anti-corruption layer, and enforcing it in the build is what makes eventual replacement possible.
2. It shields the legacy system from load — caching aggressively where staleness permits, batching requests, and rate limiting.
3. It translates the failure model. A batch window, a locked file, a session limit and a truncated field must become domain-meaningful errors, not raw ones.

Industry example

Large retail estates keep decades-old order management and inventory systems as the system of record while modern commerce runs in front of them. Walmart-scale organisations do this because the legacy system encodes years of accumulated commercial rules that exist in no document, and because stores cannot stop transacting for a migration.

Two design consequences follow. Reads are served from a projection, not from the legacy system — changes are captured (via change data capture, batch extract, or a message feed) into a store shaped for the modern access pattern. And writes are queued and applied on the legacy system's terms, with the modern system tracking the pending state so the user sees something honest while the write is in flight.

That queued-write shape is the general answer to integrating with a system whose availability and throughput you do not control.

Failure scenarios

• Synchronous calls to a system with a batch window, so requests hang for hours.
• A new consumer overwhelming the system of record and degrading the business.
• The legacy model leaking into modern services, so replacement means touching everything.
• Dual writes without reconciliation, so the two systems silently diverge.
• No handling for the batch boundary, so behaviour differs unpredictably around it.

Interview question

"The system of record updates nightly and cannot be changed. Design an API that gives your product teams something honest to build against."