Every engineer has a rewrite they want to do. Some rewrites are necessary. Most aren't. The bias toward rewriting is strong because rewriting feels like progress, while refactoring is unglamorous and slow. But the failure rate of rewrites is high enough that the question deserves a real framework rather than a gut call.
The strong default: refactor
Most of the time, the right answer is refactor. The system works. The team understands it. The codebase has flaws, but the flaws are localized — a confusing module here, an awkward abstraction there. Refactoring is almost always cheaper and lower-risk than rewriting, for three reasons:
- The business doesn't pause during a refactor. You ship customer features the whole time. A rewrite usually means a 6-12 month feature freeze, and your roadmap doesn't survive that.
- You preserve institutional knowledge. The current code encodes a thousand small decisions about edge cases, customer-specific behaviors, and "the reason we did it this way." Rewrites lose that and rediscover it expensively.
- You keep shipping during the work. Continuous refactoring becomes part of how the team operates, not a special project that has to deliver before customers see anything.
When rewrite is justified
A real rewrite case usually requires one of three conditions:
1. The architecture itself is wrong
Not "messy" — wrong. The current architecture blocks the company from doing things that need to be done. A monolith that prevents parallel team work. A data model so misaligned with the actual domain that every new feature requires fighting it. A synchronous design that needs to be event-driven. These are cases where you can't refactor your way to the right system because the right system has fundamentally different shapes.
2. The technology is unsupported and can't be migrated
The framework hasn't been updated in five years. Security patches stopped two years ago. The version of the runtime is past end-of-life. Migration paths exist for most things, but occasionally the migration is itself a rewrite — at which point you're rewriting whether you call it that or not.
3. The team that built it is gone
When the institutional knowledge is no longer in the building, every change to the existing system is high-risk. At some volume of unknown-state, rewriting becomes cheaper than continuing to operate code nobody understands. This is rare, but real.
Common rewrite traps
- The codebase is "ugly." Subjective, usually fixable with refactoring, never sufficient justification on its own.
- There's a new framework everyone is excited about. Almost never justifies a rewrite. The new framework will be old in three years.
- A single bad bug. The bug isn't the architecture; the bug is a bug. Fix the bug.
- The new senior hire prefers a different stack. This is a hiring problem, not a system problem.
- "We could move faster on a clean codebase." You move slower than you think on the new codebase, because everything that was working starts not working again.
The most dangerous middle ground
"We'll rewrite while keeping the old one running." Nine times out of ten, the rewrite ships late, the team can't operate two systems, customers are split between the old and new with bugs in both, and eventually the company cancels the rewrite — or worse, cancels the old system before the new one is ready and limps for a year.
If you do choose this path, the discipline is clear: every customer-facing feature is shipped twice (in both systems) until the migration is complete. Most teams quietly stop doing this around month three, and then the systems diverge in customer-visible ways.
How to decide
Three questions, asked honestly. Can the work be done incrementally without a feature freeze? If yes, refactor. Is the architecture itself blocking what the company needs to do, not just inconveniencing the team? If no, refactor. Are we choosing rewrite because we have a clear technical case, or because the existing code is unpleasant to work in? If the answer is the second, refactor.
If you're in the middle of this debate and want a vendor-neutral perspective from someone who has both done and avoided rewrites, reach out. The pattern recognition matters more than the framework.