The Real Cost of a Rewrite (and the Cheaper Thing to Try First)

Every aging codebase eventually inspires the same fantasy: we should just rewrite it. The current system is slow, scary to change, and full of decisions nobody remembers making. A clean slate feels like relief.

It's almost always more expensive than it looks — and often it solves the wrong problem. Before you greenlight a rewrite, it's worth being honest about what you're actually buying.

What a rewrite really costs

The visible cost is the engineering time. The hidden costs are the ones that sink projects:

• You stop shipping features for the entire rewrite. Your competitors don't.
• You reintroduce solved bugs. The old code is ugly partly because it's absorbed years of edge cases and fixes. A clean rewrite throws that knowledge away and rediscovers it the hard way.
• You have to run two systems during the migration, which is more complex than either one alone.

The messy code you want to replace is messy because it survived contact with reality. That scar tissue is worth something.

The question that actually matters

"Is the code bad?" is the wrong question — all old code looks bad. The right question is: is the architecture wrong, or is the code just tired?

Tired code — inconsistent naming, missing tests, tangled functions — can be improved in place, incrementally, while you keep shipping. A wrong architecture — the wrong data model, an assumption baked into everything that no longer holds — sometimes genuinely can't be refactored out. That's the rewrite that pays off.

If you can't point to a specific structural assumption that's fundamentally broken, you probably want a refactor, not a rewrite.

Try the boring middle path first

Between "live with it" and "burn it down" sits the option that quietly wins most of the time: strangle it.

Wrap the old system, then replace it one piece at a time. New functionality goes into clean modules. Old paths get migrated as you touch them. The system stays alive and shippable the entire way, and if priorities change, you stop wherever you are and keep the gains.

It's slower to feel triumphant and far faster to be safe. You never bet the company on a big-bang cutover.

When a rewrite is the right call

Sometimes it genuinely is — the platform is end-of-life, the architecture can't support where the business is going, and incremental change has hit a real wall. When that's true, do it with eyes open: scope it tightly, keep the old system running, and migrate in slices you can ship and verify.

The instinct to start over is usually a signal that something's wrong — just rarely the thing you think. Diagnose before you demolish.