The rewrite conversation starts the same way almost every time: a developer opens a PR, finds something horrifying in the legacy code, and says "we should really just rewrite this." Six months later, the team is halfway through a rewrite that's simultaneously broken the old system and hasn't shipped the new one.
Joel Spolsky called this "the single worst strategic mistake that any software company can make." He wasn't wrong. But sometimes a rewrite is genuinely the right call. The challenge is knowing which situation you're in.
The Case Against Rewrites
The existing system, however ugly, encodes years of business logic, edge cases, and hard-won bug fixes. Most of that knowledge is not in the code — it's in the heads of people who've since left, in support tickets, in the subtle way the system handles exceptions that nobody remembers the reason for.
A rewrite discards all of that. You'll rediscover the same edge cases through production incidents. This is why rewrites reliably take 3–5x longer than estimated.
The Case For Rewrites
Sometimes the codebase is genuinely unmaintainable — not just unfamiliar. Signs include:
- Cascading failures: Changing one thing reliably breaks three others. Tests (if they exist) don't catch it because the coupling is in runtime behaviour.
- Deployment takes days: Release processes that require manual steps, human judgment, and a specific person present are a tax on every sprint.
- No-one understands the data model: If the schema hasn't been documented and existing engineers can't explain why tables are shaped the way they are, you're flying blind.
- The tech is genuinely end-of-life: Not just old — unsupported. Framework versions with unpatched CVEs. Dependencies that can no longer be updated because everything downstream breaks.
The Decision Framework
We use four questions with clients:
1. Can you change the system safely? If you can't make a change with confidence that you haven't broken something else, refactoring is almost impossible. You can't safely refactor code you can't safely change. This is the strongest signal for a rewrite.
2. Is the business logic understood? If yes, a refactor is feasible — you can move logic while preserving semantics. If no, a rewrite will rediscover the same logic the hard way, and you'll miss things.
3. Is the performance problem architectural or implementation? Slow queries, inefficient loops, and poor caching are implementation problems — fixable without a rewrite. Fundamental data model design that makes certain queries impossible to optimise is architectural. Only the latter justifies a rewrite on performance grounds.
4. What's the cost of the status quo? How much developer time per sprint is consumed by working around the legacy system? If it's more than 20–25%, the compounding cost of not rewriting may exceed the cost of the rewrite over a 2-year horizon.
The Strangler Fig Pattern
In most cases, the right answer is neither a full rewrite nor a keep-everything-the-same refactor. It's a strangler fig: build new components alongside the old system, gradually route traffic to the new components, and decommission old pieces incrementally.
This approach: - Keeps the old system in production throughout (no big-bang cutover risk) - Lets you rediscover business logic incrementally rather than all at once - Gives you measurable progress that a full rewrite doesn't
The downside: it requires discipline. Teams that start a strangler fig without a decommission plan end up with two systems indefinitely.
The Question to Ask Before You Decide
"If we do nothing, what happens in 12 months?"
If the answer is "we ship slower and have more incidents but the business continues," a refactor programme is probably sufficient.
If the answer is "we can't hire anyone who can work on this, we can't deploy without fear, and it's actively blocking roadmap items," a rewrite may be the only viable path.
The key is honest diagnosis — not the frustration of the engineer who just spent three days on something that should have taken three hours.