How do you decide when to refactor versus rewrite a system from scratch?

Question

Accepted Answer

Default to **refactoring**. A rewrite is justified only when the existing system can no longer evolve to meet requirements at an acceptable cost, and you can keep delivering value while you do it. Most "we need a rewrite" instincts are really an unmanaged tech-debt problem that incremental refactoring solves with far less risk.

## How I reason about it

- **Is the core architecture still viable?** If the data model, boundaries, and runtime can stretch to the new requirements, refactor. If the foundational assumptions are wrong (wrong storage paradigm, no way to scale, language/platform end-of-life), a rewrite becomes a real candidate.
- **What is the change frequency?** Code that rarely changes doesn't need to be pretty. Concentrate effort where the team works daily.
- **Do we understand the current behavior?** A rewrite throws away years of encoded edge-case knowledge. If there are no tests and no spec, a rewrite will reintroduce old bugs.

## A decision framework

| Signal | Lean refactor | Lean rewrite |
| --- | --- | --- |
| Architecture fits requirements | Yes | No |
| Test/spec coverage | Low or high | High enough to verify parity |
| Can ship incrementally | Yes | Hard, big-bang |
| Team understands the code | Yes | No, and original authors gone |

## Trade-offs

- **Refactor:** lower risk, continuous delivery, but slow on a truly rotten foundation.
- **Rewrite:** clean slate, but you pay a **feature-freeze tax**, carry **dual-maintenance cost**, and risk the classic second-system over-engineering trap.
- Prefer the **strangler-fig** middle path: stand up the new system alongside the old, route traffic incrementally, delete the old piece by piece. It gives rewrite benefits with refactor-level risk.

## Pitfalls

- Rewriting for **aesthetics or resume-driven** reasons, not business cost.
- Underestimating hidden behavior; always characterize current behavior with tests first.
- A multi-quarter big-bang rewrite that ships nothing — momentum and trust both collapse.

## Why it matters

The refactor-vs-rewrite call is one of the highest-leverage decisions a Tech Lead makes. Get it wrong toward rewrite and you can freeze delivery for a year and still fail; get it wrong toward refactor and you bleed velocity slowly. Framing it as a cost-and-risk decision, not a taste decision, is what separates senior judgment from preference.

Signal	Lean refactor	Lean rewrite
Architecture fits requirements	Yes	No
Test/spec coverage	Low or high	High enough to verify parity
Can ship incrementally	Yes	Hard, big-bang
Team understands the code	Yes	No, and original authors gone