The legacy system eats more time each quarter, the team complains about the codebase, and someone proposes a rewrite from zero. The temptation fades when you open the estimate history from the last two rewrites you followed: both closed between three and five times the first number.
Four inputs before you call the meeting
- Test coverage. With reliable tests, refactoring is a controlled change. Without them every edit is a bet, and a bet does not ship to a payment system.
- External coupling. A system with many integrations, databases, and third-party services costs a lot to rewrite: each integration is an error surface you must reimplement and validate.
- The people who built it. If nobody who created the system still works there, the tacit knowledge left with them. A rewrite without it produces the same system with the same mistakes written differently.
- Business pressure. A rewrite enters the budget when architecture blocks a change the business needs. When the block is missing people, hiring solves it sooner.
When a rewrite pays off
The base technology lost its community or its support. The architecture contradicts the product you sell today: a 2014 monolith against the event queue the operation needs. Or the cost of running the current system passed the cost of building a new one.
In those cases, rewrite from inside with Martin Fowler's Strangler Fig pattern ("StranglerFigApplication", martinfowler.com, 2004): wrap the old system in a new layer, move one function at a time, and keep the system running through the switch.
The team rediscovers what nobody documented
You spend weeks in three places: a design decision with no record, an edge case kept in one person's memory, an integration that changed while the team built the replacement. Each of those is a week of work that surfaces halfway through.
Martin Fowler published Refactoring (Addison-Wesley, 2nd ed., 2018) on changing structure without changing behavior, the lower-risk path. Joel Spolsky opened the Netscape case in "Things You Should Never Do, Part I" (2000) and showed what a full rewrite cost that company.
Start from this week's constraint
Write down what blocks the business this week and the smallest change that fixes it. Expect a module refactor, one dependency swap, or a feature the system supports with nobody enabling it. The rewrite enters later, if the four inputs still point there.
Calling the team together to debate refactor versus rewrite without those four inputs produces opinions. With them the conversation lasts twenty minutes and has an owner.
