When to modernise a legacy system, and when to leave it alone

Most organisations have at least one system that people would like to replace. Changes take too long, nobody enjoys working on it, and the people who built it have moved on. On their own, none of these are good reasons for a rewrite.

Rewrites are risky, and when they go wrong it is rarely because of the technology. Over the years the old system has picked up business rules that nobody wrote down. A replacement has to rediscover each of them, often through problems in production.

What is the system costing you?

Age is a poor measure. A better question is what the current system costs the business that a new one wouldn’t. That cost tends to show up in four places.

Change cost

How long does a routine change take, from request to release? If adding one field takes six weeks, every business decision that depends on the system is slowed down with it.

Incident cost

How often does it fail, how long does recovery take, and what does an hour of downtime cost? Record this for three months before deciding anything.

Opportunity cost

What has the business decided not to do because the system couldn’t support it? In many organisations this is the largest of the four costs, and the one nobody writes down.

Risk cost

Runtimes that are no longer supported, dependencies that can’t be patched, a vendor that has left the market, or a single person who is the only one who understands how it works.

If all four are small, you have an old system rather than a problem. Old and stable is a perfectly acceptable state for software to be in.

When modernising makes sense

Modernise when these costs are large and the business still expects the system to change. Modernising a system that nobody will ask anything new of means spending money to end up where you started.

There is more than one way to modernise

The first instinct is usually to rewrite, which is rarely the best first step. From lowest to highest risk, the main options are:

• Re-host. Move the system to new infrastructure without changing it. This only deals with infrastructure risk, but it is quick, reversible, and often buys time to plan the next step properly.
• Re-platform. Upgrade the runtime, the database or the way it is deployed, without touching the application logic. This keeps the system supportable and makes automation possible.
• Wrap it in an API. Leave the system as it is and put a well-designed API in front of it. New features are built against the API, and the old system can be replaced behind it later, piece by piece.
• Replace it gradually. Move one function at a time to new code, with old and new running side by side, until the old system has nothing left to do. It looks slower than a rewrite on paper, but it is far more likely to finish.
• Rewrite. Worth it when the business itself has changed and no longer works the way the system assumes. Poor code quality on its own is rarely enough.

Write down what the system does first

Before choosing any of these, document what the system really does. Base it on what the code does rather than on old documentation or memory: what the system does, what other systems expect from it, and which unusual cases exist because a real situation once required them.

This step is often skipped, even though it is the cheapest part of the whole project. Without it, a modernisation becomes an expensive way of rediscovering your own business rules.

A sensible order of work

1. Measure the four costs for one quarter.
2. If they are small, stop and look again in a year.
3. If they are large, document the system’s behaviour and connections before choosing an approach.
4. Choose the lowest-risk option that removes the biggest cost, even if it isn’t the most complete one.
5. Deliver in stages that are each useful on their own, so the work still pays off if priorities change halfway through.

If you are weighing up a decision like this for one of your own systems, we are happy to look at it with you before anything is decided.