Why your rewrite will fail (and what to do instead)
The two-year rewrite gets cancelled in month fourteen. Incremental replacement is slower on paper and faster in practice.
Every legacy system eventually produces the same meeting. The code is unmaintainable, nobody understands the edge cases, and someone proposes starting clean.
It is an appealing plan and it usually ends badly.
What actually goes wrong
A rewrite has to reach feature parity before it delivers any value at all. Meanwhile the old system cannot be frozen — the business keeps needing changes, so you now maintain two systems and your team is split.
Worse, the old system's ugliest code is often the most valuable part of it. Those strange conditionals encode years of hard-won edge cases: the customer with the unusual tax status, the integration that sends malformed dates every December. A clean rewrite discards that knowledge and rediscovers it through outages.
Month fourteen arrives, the new system is at 70% parity, the budget is spent, and the project is quietly cancelled.
Strangle it instead
The alternative is to replace the system in slices, each shipped and delivering value on its own:
- Put a routing layer in front of the legacy system
- Build one well-bounded capability in the new stack
- Route that traffic to the new implementation
- Retire the old code path once it is genuinely unused
- Repeat
Every step is independently valuable and independently reversible. If priorities shift after three slices, you keep the three — you have not bet the year on a single cutover.
Characterise before you change
Before touching legacy behaviour, write tests that capture what it currently does — including the parts that look like bugs. These are characterisation tests, and their purpose is not to assert correctness but to detect change.
Once you can tell precisely what your edit altered, refactoring stops being frightening.
Pick the first slice carefully
The best first slice is well-bounded, genuinely painful, and low-risk if it fails. Resist starting with the hardest part to "prove it works." Start where you will actually finish, then use that credibility to fund the harder slices.
The honest trade-off
Incremental replacement means living with an ugly seam between old and new for a while. That is a real cost, and it is much smaller than the cost of a cancelled rewrite and a legacy system that is now two years more tangled than when you started.
