Integrating with legacy enterprise systems without rewriting them

Integrating with a legacy enterprise system means connecting new products to an older system that still runs critical processes, usually without the option to change it much. Rewrites are tempting and frequently fail; well-designed integration lets an organisation modernise around the legacy core, then retire it piece by piece.

Respect what the legacy system does

Legacy systems are often old because they work. They encode years of business rules, exceptions and regulatory requirements — many undocumented. Before integrating, map what the system actually does: which processes depend on it, which data it owns, its batch schedules, and who knows how it behaves.

Pattern 1: an anti-corruption layer

Never let the legacy model leak into new code. Place a translation layer between them that:

• converts legacy codes, formats and structures into the new domain model,
• hides protocols such as SOAP, fixed-width files or proprietary interfaces,
• normalises errors into a clear vocabulary,
• isolates legacy quirks in one place.

This is the same principle as supplier adapters in a travel booking engine: translation at the edge, a clean model inside.

Pattern 2: the strangler fig

Instead of replacing everything at once, place a routing layer in front of the legacy system and move capabilities to new implementations one at a time:

1. Choose one capability with clear boundaries.
2. Build it in the new platform, behind the routing layer.
3. Route a small share of traffic to it, compare results, then switch fully.
4. Retire the legacy code path once nothing uses it.

Each step delivers value and can be rolled back, unlike a big-bang cutover.

Pattern 3: change data capture

When the legacy system cannot publish events, read its changes from the database transaction log. Change data capture (CDC) tools turn inserts and updates into event streams that new systems consume, without modifying the legacy application. It is the least intrusive way to keep a modern system in sync.

Pattern 4: batch bridges

Many legacy systems speak in files on schedules. That is acceptable if handled carefully:

• validate files completely before processing,
• make imports idempotent, so reprocessing a file is safe — see idempotency,
• reconcile record counts and totals,
• alert on late or missing files.

Protect the legacy system

Older systems often cannot absorb modern traffic patterns. Shield them with caching, queues that smooth bursts, rate limits and read replicas. A sudden spike from a new mobile app should never take down the system of record.

Data ownership during transition

During migration, decide explicitly which system owns each piece of data. Dual writes from application code are fragile; prefer one owner and synchronisation through events or CDC. Document ownership changes as capabilities move.

Testing integration with confidence

• Capture real legacy responses and replay them in tests.
• Run new and legacy implementations in parallel and compare outputs before switching.
• Keep a reconciliation report running throughout the migration.

The organisational side

Integration projects fail as often from people as from technology. Involve the engineers and operators who know the legacy system, document what they know, and plan migrations around business calendars — no cutovers during peak season.

The takeaway

Legacy systems are best modernised by surrounding them, not by attacking them: translate at the boundary, capture changes without intrusion, protect the core from load, and move capabilities one at a time. The result is steady progress with reversible steps — a far safer path than a rewrite. Related decisions are discussed in build vs buy for technology platforms.