Rebuilding a legacy system without stopping the business

Every engineering team eventually inherits a system that’s harder to change than it should be. The instinct, when this happens, is usually to propose a rewrite — a clean slate, built the right way this time. It’s rarely the right first move.

Why a full rewrite usually fails

A rewrite asks a business to freeze feature work on the old system for months (often longer) while a new one is built in parallel, then to cut over in one high-risk event. Three things tend to go wrong:

• The old system keeps needing changes anyway, because the business doesn’t pause just because the engineering plan says it should.
• The new system takes longer than estimated, because the old one encoded years of edge cases that only become visible once you try to reproduce its behavior.
• The cutover itself becomes the highest-risk day the business has had in years.

What we do instead

We sequence modernization as a series of narrow, reversible changes to the system that’s already running, rather than a parallel build-and-swap.

1. Audit before proposing anything. We read the code, the incident history, and the deployment process before recommending a plan — not after.
2. Isolate the highest-risk component first. Usually this is whatever has caused the most incidents or blocked the most feature work — not necessarily the oldest or ugliest code.
3. Introduce a seam, not a rewrite. We wrap the risky component behind an interface, then replace what’s behind that interface without touching the callers. This is the same pattern we use for the content layer on this website — isolate the volatile part behind a stable interface.
4. Ship the replacement behind a flag. The new implementation runs alongside the old one, verified against real traffic, before it becomes the only path.

The result

The business never freezes. Each step is small enough to review, reversible if it goes wrong, and delivers value on its own — instead of a single high-stakes cutover six months from now that either works or doesn’t.

This is slower to plan than “we’ll rewrite it,” and considerably faster in practice, because nothing has to wait for a big-bang release that risks the whole system at once.