The Great Rewrite: When Companies Should (And Definitely Shouldn't) Rebuild from Scratch

Your engineering lead says: "The codebase is unmaintainable. We should rewrite it."

The CEO hears: "We'll be faster after."

The CEO is usually wrong. The engineer is usually half-right.

Rewrites fail 75% of the time. Not because of bad execution. Because it was the wrong decision to begin with.

When Rewrites Make Sense (The 25%)

There are exactly three situations where a rewrite is the answer:

1. The Problem Changed Faster Than the Code

You built a monolith for 10 users. Now you have 10M users and you need to scale to zero response time. The architecture is fundamentally wrong for the new problem.

Example: Instagram. They built on Burrito, realized they needed something that could scale to 50M concurrent users, and rebuilt with a distributed architecture.

Key sign: The current code can't physically do what you need. Not "it's messy." Physically can't.

2. The Tech Stack Became Unmaintainable

You built in Rails in 2010. Your team is 0.5 developers who know Rails. Every hire takes 6 months to onboard. The ecosystem is frozen. New team members struggle.

Rebuilding in Node (which everyone knows) might be worth it.

Key sign: You can't hire for it anymore. The ecosystem is dead. Not "I prefer Go." Dead.

3. You Have a Clean Break Point

You're making a product change that gives you a natural boundary. Split the old system and the new. Rewrite the new part.

Example: A payment processor splits into "legacy payments" and "new payment products." The new one is a rewrite. The old handles the cash cow. Everyone's happy.

Key sign: You can run both in parallel for 12+ months. If you can't, you'll get stuck halfway.

When Rewrites DON'T Work (The 75%)

Reason #1: You Haven't Actually Fixed the Real Problem

The real problem is usually: "Our team is slow" or "Engineers hate the codebase."

Rewriting doesn't fix that. You'll build the same mess in the new language, just slower and later.

I watched a company spend 18 months rebuilding from Python to Go. They emerged slower. Why? Because the real problem was the architecture, not Python. They rebuilt the same bad architecture in a different language.

The fix: Before you rewrite, fix the architecture in the existing code. If you can't or won't, you'll rebuild the same problems.

Reason #2: You Underestimated the Edge Cases

The old code is 200K lines. It looks messy. But it's packed with edge cases, workarounds, and hard-earned fixes.

When you rewrite, you think you'll be 10x smarter. You'll be elegant. You'll avoid the mess.

You'll rebuild 80% of it, then hit edge cases you didn't account for. You'll spend the next 2 years in "just one more fix" mode.

The new code will be prettier but not simpler.

The fix: Before you rewrite, do an archeological dig. Why is it messy? What's hiding in that mess? Most of it is there for reasons—many of them good.

Reason #3: You Stop Shipping During the Rewrite

The old code is alive. Users depend on it. Bugs happen. You fix them.

But you're halfway through the rewrite. Now you have to backport the fix to two codebases. Or you ignore the old codebase and let bugs rot.

Velocity doesn't go up during a rewrite. It goes to zero. You ship nothing for 12 months. Then you ship slowly for 6 more months as you find all the things you missed.

The fix: Can you run old and new in parallel? If not, the rewrite will kill your shipping.

Reason #4: You've Underestimated the Timeline and Cost

"We'll rewrite in 6 months."

No you won't. Every team says this. Every team takes 18 months. Some take 3 years. A few get abandoned halfway.

Why?

You underestimated complexity by 3-4x
You find bugs in the new code you didn't plan for
You discover missing features
You've slowed down shipping other things

The reality: A rewrite takes 2-3x as long as you think and 1.5-2x the cost.

Can your business survive 18 months of no new features? If not, you can't rewrite.

The Real Decision Tree

Before you rewrite, answer these honestly:

Can the current code physically do what we need? If yes, stop here. Don't rewrite.
Can we fix it in place faster than we can rewrite? If yes, do that instead.
Do we have a clean boundary? Can we split the codebase and rewrite one part while keeping the other alive? If no, don't rewrite.
Can we survive 18 months of shipping? Will the business be okay if we ship 70% fewer features for a year and a half? If no, don't rewrite.
Do we actually know what the new design should be? Or are we just hoping that "fresh code" will be better? If you don't know, don't rewrite.

If you answered YES to all five, you might have a rewrite worth doing.

If you answered NO to any of them, you have a refactor, not a rewrite.

What Actually Works (The Alternative)

Instead of rewriting, try this:

Pick one subsystem (not the whole app)
Redesign that subsystem in the new tech
Run it in parallel with the old one for 3-6 months
Migrate carefully (not a big bang)
Repeat for the next subsystem

This is slower than a rewrite. It takes 2-3x longer.

But you're shipping the whole time. You're learning incrementally. When you hit problems, they're small.

And if it goes wrong, you rollback that subsystem. Not the whole company.

The Tell-Tale Sign You Shouldn't Rewrite

You're in a meeting and someone says: "If we rewrite, we can add all the features we've been delaying."

Stop. That's not a rewrite. That's a feature backlog with a rewrite on top.

A rewrite should be: "If we rewrite, we can ship at the same pace in a better codebase."

If you need new features and a rewrite, you're doing two massive projects at once. That's how you ship nothing for two years.

One More Thing

If you're considering a rewrite because engineers are unhappy, that is not a reason to rewrite.

Unhappy engineers need:

Better architecture (fix in place)
Better systems thinking (teaching, not rewriting)
Better autonomy (org change, not code change)
Sometimes, different roles (hiring, not rewriting)

A rewrite won't fix any of that. It'll just add pressure.

The Bottom Line

Rewrites feel like the answer because they're the easiest answer to explain. "We start over" is simpler than "we refactor subsystem X, parallel-run Y, and incrementally migrate Z."

But easy answers are usually wrong.

Before you commit 18 months and millions to a rewrite, ask yourself:

"If I had to keep the old system alive and ship new features on top of it, what would I do?"

That answer is usually more valuable than "rebuild from scratch."