When to Rewrite vs. Refactor: A Framework for Legacy Systems

Every engineer who inherits a legacy system has the same instinct within the first week: burn it down and start clean. It's usually the wrong instinct, and it's usually wrong for a boring reason — the existing system, whatever its problems, encodes years of edge cases that nobody wrote down anywhere else. Rewriting it means relearning all of them, in production, on your timeline instead of the business's.

Three questions before you touch anything

• Is the pain architectural or organizational? A slow codebase caused by unclear ownership won't be fixed by a rewrite — it'll just be a faster codebase with the same ownership problem.
• Can you strangle it instead of replacing it? Routing new functionality to a new service while the old system keeps running is almost always cheaper and safer than a big-bang cutover.
• What's the real cost of running two systems during the transition — in on-call load, in data consistency, in the team's attention — and does the business have the patience for that cost?

When a rewrite is actually right

It happens, just less often than the instinct suggests. The clearest cases: the underlying platform or language is genuinely end-of-life and no longer receives security patches, or the domain model has changed so fundamentally that the old architecture actively fights the business you're now running — a single-tenant system trying to become multi-tenant, for instance. In both cases, the tell is that refactoring would mean rebuilding the foundation anyway, just slower and with more compatibility shims along the way.

The honest version of this advice is that a rewrite is a bet, and most engineering teams are bad at pricing that bet accurately — timelines slip, the old system doesn't get maintenance during the rewrite and rots further, and the new system inherits new bugs to replace the old, well-understood ones. Default to refactor. Reach for a rewrite only when you can name the specific constraint that refactoring can't solve.