Modernise legacy software without a big bang.

In brief

Modernise a legacy system by first stabilising what exists, then creating boundaries that allow capabilities to change independently. Move the highest-value or highest-risk capability through those boundaries, validate it in production and retire the corresponding legacy responsibility only after data and behaviour are reconciled.

A modernisation succeeds when the organisation can change the system more safely—not when every component uses a newer technology.

Why big-bang rewrites fail

Legacy systems contain more than code. They contain business rules that were never documented, exception handling learned through years of operation, integrations that behave differently from their specifications and data whose meaning depends on history. A rewrite often discovers this knowledge late, when the new system must already be complete.

The old platform also keeps changing while the replacement is built. The target moves, the delivery horizon lengthens and users receive no value until migration. Pressure then compresses testing and cutover into the most consequential point of the programme.

This does not mean a full replacement is never appropriate. It means the programme should still seek smaller verification points, explicit parity decisions and a migration path that limits the amount of unproven change introduced at once.

A four-stage modernisation path

1. See and stabilise the current system

Map business capabilities, users, data and integrations. Then the release process, the operational history, and where knowledge sits with too few people. Add observability where failure is currently opaque. Make builds repeatable and establish tests around the most consequential behaviours. Fix immediate instability that would undermine the modernisation.

The output is not a complete archaeological record. It is enough evidence to identify the risks, seams and first valuable move.

2. Create safe boundaries

Introduce an interface around a capability before replacing its internals. That might be an API, event, adapter or controlled data view. Define the contract, source of truth, ownership, failure behaviour and reconciliation. This creates a seam where old and new can coexist.

Boundaries should follow business responsibilities where practical. A technical layer that cuts across every capability may move code without improving the organisation's ability to change independently.

3. Move one complete slice of value

Select a capability that matters to the business and is bounded enough to prove the approach. Move the user experience, logic and data path for that slice—along with its deployment and support responsibility. A thin technical layer that no user can exercise provides weak evidence.

Use real operational traffic or controlled cohorts. Compare outcomes. Measure failure and support load. Learn how migration works while the exposure is still containable.

4. Retire responsibility, not only code

A legacy component can be retired only once its users, data, integrations and reports have transferred. So have its controls, its support procedures and every downstream assumption. Reconcile data, close access paths, update runbooks and remove the operational fallback deliberately.

Until then, the organisation owns two systems. Parallel operation can reduce cutover risk, but indefinite duplication increases cost and inconsistency. Define the exit criteria before migration starts.

What should move first?

Do not start with the easiest component merely to demonstrate activity, or the hardest component merely to prove ambition. A good first slice combines useful business value, clear boundaries, manageable migration and enough technical challenge to test the target approach.

• High-change capability: a part of the system repeatedly blocking product or policy change.
• High-risk dependency: unsupported technology or a fragile component with material operational consequence.
• Experience constraint: a customer or staff journey whose improvement cannot wait for full replacement.
• Integration seam: a boundary that unlocks several later moves once made explicit.
• Knowledge risk: a capability understood by too few people, while that knowledge can still be recovered.

Measure the outcome of modernisation

Technology metrics are useful only when connected to operating and delivery outcomes. Establish a baseline and track the measures that justify the investment:

• Lead time from an approved change to production.
• Deployment frequency, change failure rate and recovery time.
• Time to diagnose an operational problem.
• Manual work, reconciliation and support effort.
• Time required for a new engineer to make a safe change.
• Infrastructure and licence cost for the capability delivered.
• User or product outcomes unlocked by the modernised slice.

Keep the roadmap adaptive

Each delivered slice changes what the organisation knows. The target architecture should provide direction, not become a promise to implement every diagram. Reassess the next move using production evidence, business priorities and the remaining risk. Modernisation becomes safer when each stage creates more options than it removes.