Rebuild or refactor? Six questions to ask before rewriting your software

One of the toughest questions a CTO or technology leader will face is whether to rebuild an existing piece of software or continue improving what’s already there.

Old code is not automatically bad code. Sometimes it’s just evidence that the system has survived long enough to become important. That hardened aspect of it could be the reason to hang on to it.

And don’t get me wrong. Rewrites can be the right thing. They can replace obsolete architecture, remove compromises and allow a business to do things the current application cannot support.

But a rewrite removes visible complexity and often replaces it with unknown complexity. Business rules have to be rediscovered, data migrated, integrations maintained and users trained. You’ll fix things everyone hated about the old application while introducing new bugs.

Before committing, here are six questions I would ask.

1. Can the current behaviour be tested?

Is there a reliable test suite? Can important workflows be reproduced? Are business rules and important algorithms properly documented, or are they sitting in the code for someone to work out?

You also need to know whether changes can be released safely and whether performance problems and errors can be measured.

If the answer is no, a rewrite becomes more dangerous. You’re carrying those unknowns into the new application without knowing whether you’ve preserved its intended behaviour.

2. Is the real constraint architectural or organisational?

A developer disliking the current language is not, by itself, a good reason to rewrite an application.

Neither is weak product ownership, slow approval processes, an uncertain chain of command or a lack of domain knowledge. Those problems will carry forward into the new system.

The same applies to funding. A board might approve a large upfront investment while being reluctant to fund ongoing maintenance. But once the rewrite is done, you’ll still have that maintenance problem.

These are things to solve within the organisation before deciding that new code is the answer.

3. What knowledge exists only inside the current system?

An application can contain years of accumulated business knowledge: edge cases, algorithms, data-cleaning rules, regulatory requirements and third-party integrations that were difficult to get right.

If these things aren’t properly documented, get them documented.

Ugly code might actually encode valuable organisational memory. Don’t abandon it without understanding what it does.

4. Can the system be improved incrementally?

You may be able to improve the application without replacing the whole thing.

Add tests around critical behaviour. Extract and replace a troublesome component. Introduce an API boundary so parts of the system can change independently. Separate reporting or searching from the main application.

Sometimes, rewriting just the user interface is enough to address what users dislike while retaining a reliable backend.

Remove functionality that is no longer required, too. Do it incrementally and test every step. One area causing disproportionate difficulty doesn’t mean the entire application needs to go.

5. What has to keep operating during the transition?

For some period, you may have two systems running. How will data stay synchronised? What happens to existing integrations? How will staff be trained and customers migrated?

There needs to be reconciliation to make sure data is accurate and where it’s supposed to be. There also needs to be an ability to roll back.

A rewrite includes the whole bridge of actions required to move from one system to another. That transition needs as much attention as the new application.

6. What new capability does the rewrite unlock?

A rewrite makes sense when it enables something materially important.

That might mean entering a new market, supporting a different operating model, addressing a security limitation or meeting regulatory requirements the existing architecture cannot safely support.

“The developers don’t like the code” is a weak justification. “The existing architecture makes regulatory change unsafe and takes too long to certify” is a much stronger one.

Be specific about what the business will gain.

Making the decision

Refactor when the system is broadly viable and can be improved incrementally. Replace a component when one constrained area causes most of the difficulty. Use a strangler approach when significant change is needed but functionality can be migrated gradually.

A full rebuild may be appropriate when the existing system prevents safe progress, its necessary behaviour can be recovered and the organisation can sustain the transition.

Don’t just ask whether the code is old or unpleasant. Ask whether the current system can support the next stage of the business safely, economically and legally.