How to modernize a legacy system without stopping the business

Every company that has been running software for more than a decade eventually reaches the same conversation. The system works. It has worked for years. But it runs on a version of the framework that no longer receives security updates, the person who wrote it left in 2017, and every new feature takes three times longer than it should.

The instinct is to rewrite it from scratch. That instinct is usually wrong.

Why full rewrites fail so often

A rewrite promises a clean system built with current tools. What it delivers, most of the time, is eighteen months during which two systems must be maintained, the old one keeps changing because the business keeps moving, and the new one is always three months from being ready.

The deeper problem is that the old system contains years of accumulated business rules that nobody documented. They are not in the specification. They are in the code, discovered one production incident at a time.

The strangler approach, in plain terms

Instead of replacing the system, you put a layer in front of it and move one piece at a time. Each piece works in production before you start the next one.

1. Put a boundary in front. Traffic goes through something you control, which decides whether the old or the new code handles each request.
2. Pick the piece that hurts most. Not the easiest one. The one causing the most support calls or blocking the most new work.
3. Rebuild only that piece, reading the old code as the specification it really is.
4. Route that traffic to the new code and keep the old path available for a while.
5. Delete the old piece once it has been unused for a full business cycle.

Repeat until there is nothing left of the old system, or until what remains is stable enough that replacing it stops being worth the effort. Both are acceptable endings.

What this costs you

It is slower in total than a rewrite that goes perfectly. A rewrite that goes perfectly is also rare.

What you get in exchange is that the business never stops, every step is reversible, and you can pause the whole thing for two months when a busier priority appears. A half-finished rewrite has no such property.

The database question

The hardest part is rarely the application code. It is the database that both systems need to read and write while the migration is in progress.

The pragmatic answer is usually to leave the schema alone for as long as possible, even when it is ugly, and modernize it only after the application layer has been moved. Changing both at once means that when something breaks, you cannot tell which change caused it.

A reasonable first step

Before deciding anything, spend two weeks measuring: which parts of the system change most often, which generate the most incidents, and which block the features the business is asking for. Modernize those. Leave the parts that quietly work alone.

The goal is not a beautiful system. It is a system that stops costing you opportunities.