Legacy Modernisation: Rewrite, Replace or Improve Incrementally?_

A legacy system is not simply an old system. It becomes a business problem when it prevents necessary change, creates unacceptable operational risk or costs more to maintain than the value it supports.

The difficult question is not whether the system should be modernised. It is how. The most common options are a complete rewrite, replacement with an existing product, or incremental improvement and replacement.

Each can be correct. Each can also fail badly when chosen for the wrong reason.

Begin with the Business Constraint

Technology teams often describe legacy problems in technical language: obsolete frameworks, unsupported databases, monoliths or missing tests. These may be real risks, but a modernisation decision needs a business statement.

Examples include:

• launching a new product takes months because every change touches the core system;
• a critical process depends on one retired or overloaded specialist;
• outages create material revenue or compliance risk;
• the system cannot support a new market or operating model;
• infrastructure and licensing costs are increasing without improving capability;
• security requirements can no longer be met safely;
• manual work around the system has become a second hidden product.

This statement gives the programme a measurable reason to exist.

Option 1: Complete Rewrite

A rewrite replaces the current system with a newly designed implementation, usually while attempting to preserve or improve the existing business capability.

A rewrite is attractive because it promises a clean start. It may be justified when:

• the existing architecture cannot support the required operating model;
• most of the technology is unsupported or unsafe;
• business rules are understood and stable enough to rebuild;
• the organisation can fund parallel operation and migration;
• the new system can be delivered in useful increments rather than one final switch.

The main danger is underestimating hidden behaviour. Legacy systems contain years of exceptions, workarounds and implicit rules that users may no longer be able to describe. A team rebuilding from documentation often discovers those rules only when production behaviour differs.

A "big bang" rewrite also postpones real feedback. The old system continues changing while the new one tries to catch up, turning the target into a moving object.

Option 2: Replace with an Existing Product

Buying a product can be effective when the process is not strategically unique and the organisation is willing to adapt to standard workflows.

Replacement is attractive when:

• the required capability is common and mature;
• vendors provide credible long-term support;
• configuration covers most important needs;
• integrations and data migration are manageable;
• the organisation is prepared to change its processes;
• the commercial model remains acceptable at future scale.

The mistake is to compare licence cost only with development cost. Total replacement cost includes process change, configuration, integrations, migration, training, data cleanup, vendor dependency and future customisation.

A product that covers 80 per cent of requirements may still be the best choice if the remaining 20 per cent can be changed in the business process. It may be the worst choice if that 20 per cent is the organisation's competitive advantage.

Option 3: Improve and Replace Incrementally

Incremental modernisation changes the system in controlled steps. The team may isolate a capability, add tests, improve observability, replace one component or move a process behind a new interface.

This approach is often suitable when:

• the current system still delivers substantial value;
• uninterrupted operation is essential;
• business rules are not fully understood;
• risk must be reduced before major replacement;
• the organisation needs benefits earlier than a full programme can deliver;
• different areas have different levels of urgency.

Incremental work creates earlier evidence and spreads migration risk. It also requires strong architectural discipline. Without a target direction, a series of local improvements can preserve the old structure indefinitely.

Use a Decision Matrix, Not a Technology Preference

Evaluate the options across several dimensions.

Business differentiation

Is the process a source of competitive advantage, or should the company adopt a standard way of working?

Operational continuity

Can the organisation tolerate a long parallel programme or a high-risk cutover?

Domain knowledge

Are current rules documented and understood, or are they embedded in code and user habits?

Change pressure

How soon must the business support new products, markets, volumes or regulation?

Data and integrations

How difficult is it to migrate historical data and coordinate dependent systems?

Organisational capacity

Can business experts, operations and technical teams support the transition in addition to daily work?

Exit and reversibility

Can the organisation change course if assumptions prove wrong?

No single score decides the answer, but the matrix makes trade-offs visible.

Modernise Around Capabilities

Large legacy programmes become more manageable when organised around business capabilities rather than technology layers. Instead of "replace the database" or "move to microservices", define a useful capability such as customer onboarding, pricing, reporting or order fulfilment.

A capability-focused increment can include everything necessary to deliver value: data, user interface, integrations, rules, operations and migration. This reduces the risk of producing a modern technical layer that still depends on the old system for every real outcome.

Protect Knowledge During the Transition

Legacy modernisation is also knowledge modernisation. The programme should capture:

• why important rules exist;
• which exceptions are still valid;
• who uses unofficial workarounds;
• what external systems assume;
• which operational checks prevent failure;
• what data quality problems are hidden by manual work.

Pairing domain experts with engineers, testing real scenarios and observing users often reveal more than old documentation.

Avoid Recreating the Legacy System in New Technology

A common failure is to copy every existing behaviour into a new stack without asking whether it is still needed. The result is a more modern implementation of the same complexity.

For each capability, distinguish between:

• behaviour required by law or contract;
• behaviour that creates business value;
• behaviour needed only because of the old system;
• behaviour nobody can explain;
• future capability that should not be forced into the first release.

Modernisation should remove accidental complexity, not preserve it automatically.

Define Success in Business Terms

A successful programme is not measured by the percentage of code rewritten. Better measures include:

• shorter lead time for business changes;
• fewer critical incidents;
• lower dependency on individual specialists;
• faster onboarding;
• reduced manual work;
• ability to enter a new market;
• simpler compliance evidence;
• predictable infrastructure and licensing cost;
• retirement of specific high-risk components.

The right strategy may combine all three options: buy a standard capability, rewrite a differentiating one and improve the remaining system incrementally. The goal is not a fashionable architecture. It is a controlled reduction of business constraint and operational risk.