Modernisation without a big bang: How to renew critical systems step by step

A large building wrapped in scaffolding during renovation
Photo: Karen Barrett / Unsplash

Almost every organisation that has been around for a while has at least one system everyone knows must be replaced. It is slow to change, few people understand it fully, and those who built it have long since moved on. The temptation is to start over: rewrite everything with modern technology and switch over on a given date. It sounds tidy. In practice it is one of the riskiest decisions a technology organisation can make.

Why the big rewrite goes wrong

The first problem is that old systems contain more than anyone thinks. Over the years the code has accumulated business rules, exceptions and fixes that were never documented – a special rule for one type of customer, a rounding that has to be done exactly so, an ordering in a nightly batch that something else depends on. Rewrite from a specification and those details disappear, often until they resurface in production.

The second problem is that the target keeps moving. While the new system is being built, the business keeps changing, and the old system still has to be maintained. Either you freeze changes for a long time, or everything is done twice. Both are expensive.

The third is that a big rewrite delivers little or no value until the very end. Patience runs out long before the project does, and in the worst case you are left with two half-finished systems.

Strangle the old system gradually

The alternative is often called the strangler fig pattern, after a plant that slowly grows around its host tree. The principle is simple: you put a seam in front of the old system – an API, an integration layer or a routing component – so that traffic passes through a point you control. Then you move functionality to the new solution, one piece at a time. Each piece goes into production on its own, and the old system shrinks until it can be switched off.

You deliver value along the way, the risk is split into manageable steps, and you can adjust course as you learn.

Understand what the system actually does

Before you move anything, you need to know what you are moving. That means mapping how the system behaves today, not how the documentation says it should behave. Tests that pin down existing behaviour – including the behaviour that looks odd – are among the most valuable tools here. They make hidden logic visible and give you a safety net.

The data tells you a lot too. Which fields are actually used, and which combinations exist that nobody remembers were possible? Especially in finance, where calculations and reporting have to reconcile to the last digit, this work is not optional.

Where to begin

Start where change or pain is greatest. Areas that change constantly are where a modern foundation pays off fastest. Areas with frequent errors or heavy manual work give visible gains early and build confidence for the rest of the journey. Integrations are often a good starting point, because they form natural seams in the system.

Run old and new side by side

When a piece has moved, run old and new in parallel for a while and compare the results. Same input, two answers – and every discrepancy is either a bug in the new solution or a rule you did not know about. Either way, you want to find it before your customers do. Only when the discrepancies are explained do you switch over for good.

Data migration is a workstream of its own

Data is often left until the end. That is a mistake. Migrating data needs its own planning, its own tests and its own reconciliations, and it tends to uncover quality issues that have lain hidden for years. Treat it as a separate workstream from the start, with clear ownership.

When a rewrite actually is right

Incremental modernisation is not always the answer. If the system is small and well understood, if the technology is so outdated it can no longer be run safely, or if the business has changed so much that the system solves the wrong problem, a fresh start may be the right call. The point is not that rewriting is always wrong, but that it should be a deliberate choice – not the default.

How we can help

We help organisations map existing systems, find the right places to begin and carry out modernisation step by step – taking ownership of the whole journey from analysis to operations. If you are facing a system that needs renewing, we are happy to talk about where it makes sense to start.

← Back to insights

Have a project we can help with?