Legacy systems don't get replaced in one move. If they're running a business, you can't stop the business to replace the engine. We've modernised several production systems using a consistent pattern — one that keeps the old system running the entire time, never requires a maintenance window, and lets us roll back any individual step.

The Strangler Fig Pattern

We don't rewrite. We strangle. We build new functionality alongside the old system, reroute traffic to the new path one function at a time, and retire old functions as they're replaced. The old system runs the entire time. It never goes down for a migration weekend.

The name comes from a vine that grows around a tree and gradually takes over its structure. The tree is still there — until it isn't. The business never experiences a gap.

The API Adapter Layer

The first thing we build is an adapter layer over the legacy system's data store. New code talks to the adapter. The adapter translates into whatever the legacy system expects. This decouples the new interfaces from the legacy data format. When we migrate the underlying data, the adapter changes — but nothing above it does. This layer also lets us observe how the legacy system is actually being used before we replace it.

Feature Flags for the Cutover

Every new path lives behind a feature flag, gated first by environment, then by tenant, then by percentage rollout. We don't flip the switch for all users at once. One internal test user first, then a handful of real users who've agreed to beta-test, then 5%, then 25%, then 100%.

This sounds slow. It's fast compared to a rollback from a bad full cutover, which in our experience takes 3 to 8 hours and affects all users simultaneously.

Dual-Write During Migration

During the transition, we write to both the old and new data store. Reads come from the new store. If something is wrong with the new data, we flip reads back to the old store without losing any writes. Dual-write ends when we've had 30 days of clean reads from the new store with no fallbacks triggered and no discrepancies in reconciliation checks.

Smoke Tests After Every Step

Every time we retire a function from the old system, a smoke test verifies the new path produces identical output for the same input. These tests run in production monitoring, not just in CI. They page us if output diverges. The test suite grows with each step until it covers the full system — at which point it becomes the regression suite for the modernised platform.