Legacy applications: what makes one, and what to ask

A school bursar sits in a meeting with a new IT contractor. The contractor calls the parent payment system "legacy" three times in ten minutes, each time as a reason to replace it. The system is six years old. The timetabling system next to it is fifteen years old, and nobody has called it anything.

The bursar suspects the word is being used to mean "something I would rather not work on". That suspicion is often right. The word does have a useful meaning, though, and it has little to do with age.

What makes an application legacy

A legacy application is one the organisation still depends on and can no longer change with confidence. Both halves matter. An old system nobody needs is a candidate for switching off. An old system that is supported, understood and easy to change is simply a system that has lasted.

What turns a working application into a legacy one is usually a loss around it, not a fault inside it:

• Support is lost. The platform, the language version or a component it relies on no longer receives fixes.
• Knowledge is lost. The people who built it have gone, and what they knew was never written down.
• Fit is lost. The business has changed and the application still does what it was asked to do years ago.

Three Thoughtworks authors who collected the patterns they had seen in replacement projects put it this way: "technology is at most only 50% of the legacy problem". The rest is how the organisation works around the system, funds it and decides about it. That is why swapping the technology alone so often produces a new system with the old problems.

Four kinds, and why the difference matters

Sorting an application into one of four kinds tells you what sort of answer it needs.

1. Out of support. It works, but what it stands on does not get security fixes any more. There is a date attached, known or not.
2. Orphaned. Nobody available understands it. Changes are possible in principle and frightening in practice.
3. Outgrown. It is healthy but built for a smaller or different business: one branch, one language, desks and not phones.
4. Entangled. Everything else connects to it, so nothing around it can change without touching it.

The kinds call for different work. An out-of-support application may need only an upgrade. An orphaned one needs its behaviour written down before anything else, which is cheap. An outgrown one is a question of what the business needs now. An entangled one has to be separated a connection at a time. Most of the slow, costly change that people call technical debt collects in the second and fourth kinds.

The choices that follow, from leaving a system alone to rebuilding it, are laid out in legacy system modernization approaches.

What to ask about yours

You do not need to read code to place an application. Six questions do it, and the people who use and maintain it can answer them in an afternoon.

1. Who can change it today? Names, not roles. If the answer is one person or one supplier, note it.
2. Is everything under it still supported? Platform, language version, hosting, and each outside service it calls.
3. What stops if it stops? Follow one working day through it. This is the measure of how much care it deserves.
4. What does it hold that exists nowhere else? Records, rules, and for a public site the addresses that other sites link to.
5. What does the business need that it cannot do? Specific requests that were turned down or quoted at a price nobody would pay.
6. What connects to it? Every system that sends it data or reads from it, including the spreadsheet somebody exports every Friday.

The answers do two things. They place the application among the four kinds. They also show whether "legacy" is a description or only a complaint: if the first three answers are comfortable, the system is old and fine.

The bursar's six questions about two systems

Return to the school from the opening, which is invented. The bursar asks the six questions about both systems.

The payment system, the one called legacy, can be changed by its supplier, who is still trading. Its platform is supported. It cannot take payments in instalments, which parents have asked for. It is outgrown in one respect and healthy in the rest, and the supplier can quote for the missing feature.

The timetabling system gives different answers. One retired teacher wrote it and still fixes it as a favour. It runs on a database version that stopped receiving fixes years ago. Registers, room bookings and the exam schedule all read from it. It is orphaned, out of support and entangled at once, and it was never on the contractor's list because it never complains.

The spending decision turns over. The system that was to be replaced needs a feature. The one nobody mentioned needs its rules written down this term and a plan for moving off it, one connection at a time, of the kind described in replacing a legacy system without losing what it does.

Sorting the applications you depend on

• List the applications the organisation would notice within a day if they stopped.
• Ask the six questions of each. Rough answers are enough.
• Mark each one: fine, out of support, orphaned, outgrown or entangled.
• For anything orphaned, start writing down what it does now, while someone can still be asked.

When the application in question is a website or web application that has to move to a current platform, the list of what it holds is the start of the work. Our website modernization assessment begins with that inventory.

Sources

• Ian Cartwright, Rob Horn and James Lewis, Patterns of Legacy Displacement, 2024.