Legacy system modernization: why the strangler approach beats the big rewrite

Legacy systems frustrate everyone, and the temptation is to start again. The trouble is that the old system contains years of business rules, edge cases and fixes that nobody fully remembers, and a rewrite has to rediscover all of them while the business keeps moving.

Why big-bang rewrites go wrong

• They take longer than planned, and during that time the old system still needs changes, so the target keeps moving.
• Hidden behaviour is lost. Undocumented rules that mattered in production are missed.
• Value arrives only at the end, so there is nothing to show, learn from or course-correct on for a long period.
• The cutover is a single high-risk event, with a hard-to-test migration of live data.

Some systems truly do need replacing wholesale, such as ones on unsupported platforms nobody can run. But many more benefit from a gradual approach.

The strangler approach

Named after a vine that grows around a tree, the idea is to build new functionality around the old system and route more and more traffic to it, until the old system can be switched off.

1. Put a facade in front. Introduce a routing layer — an API gateway, reverse proxy or application-level router — so requests can be directed either to the legacy system or to new components, without clients noticing.

2. Find the seams. Identify parts of the system with clear boundaries: a distinct business capability, a report, a customer-facing screen. Good candidates are valuable, reasonably self-contained and not tangled with everything else.

3. Replace one slice at a time. Build the new version of a slice, run it alongside the old, compare results, then route traffic over — gradually, with the ability to switch back.

4. Handle the data deliberately. This is usually the hardest part. Options include having the new component read from the legacy database at first, synchronising data in both directions during transition, or migrating ownership of a data set once its logic has moved. Avoid two systems writing the same data without a clear owner.

5. Retire what is replaced. Remove the old code once its traffic is gone, so the legacy surface genuinely shrinks.

Before you start

• Document what exists. Interview the people who use and maintain it, read the code, and capture behaviour with characterisation tests — tests that record what the system currently does, so you know when a replacement differs.
• Define the goal. Faster delivery, lower running cost, an unsupported platform, better security, new capabilities? The goal decides which slices come first.
• Prioritise by value and risk. Start with a slice that is useful and modest in size, to build momentum and learn the technique before tackling the hardest areas.
• Agree what "done" means for each slice, including performance and parity expectations.

Keep the business in the loop

Incremental delivery only works if each slice ships. Involve the people who run the process every day, because they know the edge cases. Plan for training and communication, and avoid changing too much for users at once.

Watch for common traps

• Never finishing. A permanent hybrid that doubles the maintenance burden is the failure mode of this approach. Keep a retirement plan and track it.
• Rebuilding bad design faithfully. Replacing code is a chance to drop obsolete rules, not copy every quirk. Decide consciously which behaviours to keep.
• Underestimating integration. Other systems depend on the legacy one in ways the documentation does not show.
• Skipping observability. You need to see traffic, errors and differences between old and new to move confidently.

What to take away

Modernise by replacing the legacy system one slice at a time behind a routing layer, with tests that capture current behaviour and a firm plan to retire what is replaced. It is slower to announce and much safer to deliver.