Rewrite vs refactor: what to do with aging software

What rewriting and refactoring mean

Refactoring means improving the code you already have without changing what it does for users. Developers clean up confusing parts, split large pieces into smaller ones, add tests, update libraries and fix the structure so future changes are quicker and safer. The software keeps running the whole time.

Rewriting means building a new version from scratch, usually in a newer language or framework, and switching over once it is ready. You get a clean start, but you also have to rebuild every feature and every rule the old system handled, including the ones nobody remembers.

Signs refactoring is enough

• The software does its job and users mostly like it, but changes take longer than they should.
• Bugs cluster in a few areas rather than appearing everywhere.
• The language and framework are still supported and developers can still be found for them.
• Developers can explain how most of it works, even if they do not like how it is written.
• Performance problems come from a few slow screens or queries, not the whole design.
• The business needs are roughly the same as when the software was built.

Signs a rewrite is justified

• The platform is no longer supported, such as VB6, old versions of Microsoft Access or a framework that stopped receiving security updates.
• You cannot hire or find anyone who can work on it.
• The business has changed so much that the core design no longer fits, for example a single-location tool that now has to serve many locations or outside customers.
• Every change breaks something else, and there are no tests to catch it.
• Security or compliance requirements cannot be met on the current foundation.
• It only runs on one aging computer or server that nobody wants to touch.

Why full rewrites go wrong

A rewrite almost always takes longer than planned. Old software is full of small rules added over years to handle real situations: a discount for one customer type, a rounding fix, a special case for a state’s tax rule. Those rules are rarely documented, so the new version misses them until users notice.

While the rewrite is underway, the old system still needs fixes and the business still wants new features. Teams either freeze the old system, which frustrates users, or build everything twice. The new version also tends to grow, because a fresh start invites everyone to add the features they always wanted. Each of these is manageable, but together they are why big-bang rewrites have a reputation for running late and over budget.

The middle path: replace it piece by piece

Developers often call this the strangler approach. Instead of switching everything at once, you build new parts alongside the old system and move one area at a time: first reporting, then customer records, then billing, and so on. Each piece goes live, gets checked against the old one, and the old part is switched off.

You get the benefits of a rewrite without betting the business on a single launch day. It does require the old and new systems to share data for a while, which adds some work, but it keeps risk small and gives you working improvements every few weeks instead of waiting a year.

Rewrite vs refactor: how to decide

1. Get an honest code reviewHave an independent developer look at the code, the platform and the hosting, and write down what is sound and what is not.
2. List what the business needs nextWrite down the features and changes you need in the next two years, and ask whether the current foundation can support them.
3. Document the hidden rulesSit with the people who use it and record every calculation, exception and workaround before deciding anything.
4. Find the worst partIdentify the single area causing the most pain. Often fixing or replacing that one area solves most of the problem.
5. Estimate both pathsPrice a refactor, a piece-by-piece replacement and a full rewrite, including the cost of running the old system in the meantime.
6. Start small either wayPick one contained piece, improve or replace it, and use what you learn to plan the rest.