When to Refactor Software and When to Rebuild It

An application may look dated while supporting important work reliably. Another may have a modern interface but be difficult to change without causing failures. Appearance and age are incomplete guides to the investment it needs.

Begin with the business changes that cannot be delivered safely or economically. A new pricing rule may require edits in several places. A customer portal may depend on data the application cannot expose reliably. Routine updates may take too long because nobody understands the affected behaviour.

Collect concrete examples. Which requested changes were delayed or abandoned? Which incidents recur? Which components are unsupported? What work depends on a person’s private knowledge? Distinguish observed constraints from general dislike of the technology.

The Software Engineering Institute’s technical-debt assessment material considers business, architecture and organisational concerns together. That broader view is useful when a technical complaint needs to become an investment decision.

Also record what works. Existing business rules, stable integrations and familiar operating routines have value. A replacement must either preserve that value or deliberately change it. Treating the old system as nothing but a problem can make its useful behaviour visible only after it has been lost.

The assessment should produce a short set of constraints and the business consequences they create. “The framework is old” needs further explanation. “The unsupported component prevents a required security update” describes a reason to act.

Targeted repair is appropriate when the difficult area can be isolated and the rest of the system remains supportable. The work may improve tests, simplify a component, replace a dependency or correct a recurring failure.

Gradual replacement can suit a larger renewal where useful boundaries exist. A new capability takes over part of the work while the existing system continues serving the rest. Martin Fowler’s Strangler Fig description explains this incremental approach to modernisation.

A full rebuild may be justified when constraints are pervasive, requirements have materially changed or maintaining the existing foundation is no longer viable. It also carries the challenge of reconstructing behaviour, moving data and switching operations.

Compare the options against the same needs:

An incremental approach is not automatically simple. Running old and new components together creates temporary interfaces, data ownership questions and operating overhead. AWS’s Strangler Fig guidance describes prerequisites and trade-offs around that pattern.

Choose the approach that addresses the constraints with a manageable transition. A preference for a new technology stack is not enough to settle the decision.

Where the choice remains uncertain, commission a bounded technical investigation. Select a representative change in the difficult area and examine how it could be implemented, tested and released under each plausible approach. The result may show that a component is easier to isolate than expected, or that hidden data dependencies make an incremental plan more complex. Record what the investigation established and what remains unknown. This is especially useful when a rebuild proposal rests on broad statements about maintainability rather than examples from the application itself.

A replacement is incomplete while the business still depends on the old system for essential information or unfinished tasks. Plan the transition alongside the new features.

Start with data. Identify which records must move, which can remain in an accessible archive and which should be retired under the relevant retention requirements. Check quality before migration. Duplicate customers, inconsistent statuses and missing relationships will not become reliable merely because they enter a new database.

Define how the old and new systems coexist during the transition. Which system owns a record at each stage? Can users change it in both? How are corrections propagated? How will the team recognise a transaction that has crossed the boundary incompletely?

For an illustrative service company, moving completed jobs may be straightforward while active jobs need careful sequencing. A job could have an appointment, a pending supplier order and an unissued invoice. Migrating only its headline record would omit the work that makes it operational.

Rehearse the migration with representative data and record the reconciliation checks. Counts alone are insufficient if important relationships or values are wrong. The business owner should be able to validate meaningful tasks in the new system.

Plan cutover and fallback. State when new activity stops entering the old system, how unfinished work is handled and who can decide to reverse or pause the change. Consider the consequences of actions taken in the new system before a rollback.

A modernisation project earns its value when the business can complete the required work after the transition, with fewer constraints than before.

That outcome includes training, support and access arrangements. A technically successful migration can still leave staff unable to perform the new routine without repeated assistance.

A rebuild can become a replica of accumulated habits unless the business decides what no longer needs to exist. Review unused reports, obsolete approval paths, duplicate fields and workarounds for problems the new design removes.

Create a short retirement list with the relevant owners. Confirm why each item can disappear and whether any legal, contractual or operational need remains. This reduces the chance of spending the new budget reproducing low-value behaviour.

Define the first useful release around a business capability. It should have a clear user, authoritative information and acceptance criteria. Avoid replacing isolated screens while leaving their underlying process split ambiguously between systems.

Sequence the work around dependencies and risk. A peripheral capability may provide a useful first migration, but it should teach something relevant to the harder parts. Conversely, moving the most critical function first may create unnecessary exposure if the team has not tested the transition approach.

Make retirement a tracked deliverable. Old accounts, infrastructure and integrations can remain active long after users move, creating cost and security responsibilities. Decommission them only after necessary information, access and recovery requirements are resolved.

Keep the investment review connected to the original constraints. Are changes easier to deliver? Has the recurring failure disappeared? Can the business support the system without the previous dependency? These questions provide a better measure of success than the proportion of code rewritten.

Software modernisation should start with this comparison of viable paths. The right proposal explains what will be repaired or replaced, how the business will move through the transition and what will finally be retired.