How do we modernise a core business system without stopping the business?

Replace it a piece at a time

The approach that keeps a system in service is usually called the strangler pattern. In plain words: new pieces are built beside the old system, each one takes over a single capability, and the old code for that capability is switched off once the new piece has proved itself. The system as a whole never stops, because at any moment most of it is the version everyone already uses.

Four rules make it work.

One capability at a time. A capability is something the business would recognise: the order screen, the overnight invoicing run, the stock report. Each stage replaces one of them, end to end, and goes live on its own.

The data stays in one place. Old and new pieces read and write the same database for as long as both exist. Keeping two databases in step is where these programmes most often go wrong, so it is avoided until the old side has nothing left to do.

Every step is reversible. A new piece goes live behind a switch, or for a small group of users first. If it misbehaves, the switch goes back and the old piece carries on. A step that cannot be reversed, such as a change to the database structure, is rehearsed on a copy and run at a quiet time.

Nothing is retired until it has been replaced. The old code for a capability is removed only after the new piece has carried the full load without incident.

What to do before the first stage

Three things need to be true before any capability is replaced, and in a 15-year-old system they often are not.

The system has been assessed. Someone has read the code and the database and written down what the system does, what it depends on, which parts are used and which parts are the source of the slowness and the risk. That record decides the order of the stages. Without it the first stage is chosen on impressions.

A release can be made safely. If nobody has built the system from its source code recently, or releases are done by copying files onto the server by hand, that is the first job. A build that runs the same way every time, and a set of automated checks around the behaviour the business relies on, is what makes each later stage safe to put live and safe to reverse.

The backups have been proven. Not that backups exist, but that a restore has been done, timed, and found to produce a working system. Every stage changes the database in some way, and the restore is the last line of defence.

How long the stages take

Each stage is typically a matter of weeks to a few months, depending on how much of the system the capability touches. The groundwork above can take as long as a stage by itself when the system arrives without a working build. The whole programme is not fixed at the start: it is planned and priced one stage at a time, and it can be paused between stages with everything done so far still in use. For a large system a programme can run for a year or more, and parts that work well and rarely change are often left alone for good.

Pick the first stage for its value: whatever carries the most risk, such as a database out of vendor support; whatever hurts users most, usually the slow screen; or whatever blocks everything else, often the lack of a reliable build.

What the business notices

Users notice a new screen where an old one was, usually one section at a time, and a system that is faster where the slow parts have been replaced. Managers notice that changes start arriving in days rather than months once a release process exists.

They do not notice most of the programme. Moving the database to a supported version, replacing a framework, automating the build and moving a slow report onto its own copy of the data are invisible from the outside apart from the improvement. There is no switch-over weekend, no retraining of a whole department at once and no period when the system is unavailable while a new one is finished.

The business does have to give time from the people who know the processes: each stage needs them to describe what the capability really does, including the special cases, and to check the new piece before it goes live.

When replacement is the honest answer

Staged modernisation assumes the system still fits the business and can be changed. Four findings point the other way.

• Most of the real work now happens outside it, in spreadsheets and workarounds, so updating its technology would modernise the wrong process.
• There is no source code, or the code cannot be built, so there is nothing to modernise.
• Every change breaks something else, and adding checks around the behaviour has not helped, so each stage costs more than it returns.
• A packaged product now does the job well, and the process is not specific enough to justify bespoke software.

Replacement is still done in stages: keep the old system stable, choose the replacement, and move the business onto it one group or one capability at a time. Our answer on whether to rewrite or modernise covers the choice in more detail, and the ten-question check gives a first view.

Where to start

The assessment is the cheapest and most useful first step. CodeFirst, a UK software company that modernises business systems in stages, offers it as a fixed-price code audit: a written report on the system’s condition, where the risk sits and what order the stages should run in. If the report points to modernisation, the stages are planned and priced one at a time under our legacy software modernisation service.