When should you rewrite software — and when should you leave it alone?

A rewrite can remove years of constraints. It can also spend a year rebuilding bugs your existing system already learned to avoid. The decision needs evidence, not framework envy.

Every old codebase eventually annoys someone

New engineers notice inconsistent patterns. Product teams notice slow delivery. Security teams notice unsupported dependencies. Then somebody says the dangerous sentence: ‘It would be faster to rewrite it.’

Sometimes they are right. Often they are comparing the difficulty of a known system with the imagined simplicity of a system that does not exist yet.

Rewrite when the system blocks the business

The strong signals are concrete. The platform it runs on is no longer supported, so security holes stay open. The architecture makes important product changes wildly expensive. Releases cannot be made reliably. Or the data model cannot describe where the business is going.

The key is measurable constraint. ‘The code is ugly’ is not enough. ‘Adding a new country requires six weeks because tax logic is duplicated across 40 files’ is useful evidence.

Diagram: a five-item rewrite checklist — expired security support, a blocked roadmap, unreliable releases, a cracked data model and lost knowledge — with one box ticked in red — Rewrite because the business is constrained, not because the code offended you.

Do not rewrite because the framework is unfashionable

Technology ages. That does not mean software stops being valuable. A stable application on a boring stack can be healthier than a rewrite on the newest stack with twelve months of missing edge cases.

If the system is secure, maintainable and still lets the team ship, fashion is not a business case.

Do not compare a real legacy system with an imaginary rewrite that has no bugs yet.

Consider strangler-style modernization

Rewrite decisions are rarely all or nothing. The strangler pattern replaces a system piece by piece: new code grows around the old one until the last old part can be switched off. Isolate one troublesome module, put a new API in front of it, migrate a single workflow, upgrade the platform in stages, or move data behind a new service.

Going step by step gives the team feedback from real use while reducing the size of each bet.

Diagram: three stages — a single dark legacy block, then a ring of new services growing around it, then the old block faded away — Reduce the size of each bet.

Inventory the knowledge hidden in production

Old systems contain undocumented business rules encoded through years of bug fixes. The invoice date that shifts around a holiday. The permission exception for one enterprise customer. The strange file format a partner still sends every Tuesday.

A rewrite plan must discover these rules before deleting the code that currently remembers them.

Diagram: an archaeologist brushing away soil to uncover buried business rules — a circled calendar date, an old key and a floppy disk — Old code remembers things the documentation forgot.

Set a migration finish line

A partial rewrite can quietly settle into two permanent systems. Define what finished means: traffic moved, the old database read-only, the legacy app switched off, or named modules deleted.

Without a finish line, ‘temporary compatibility layer’ is how software earns a ten-year career.

The decision rule

Rewrite when the cost of staying is clearly higher than the cost and risk of moving. Modernize one piece at a time when the boundaries allow it. Leave the system alone when it is doing its job and the case against it is mostly about taste.

Software does not need to be young. It needs to be useful, safe and changeable enough for the business.