A legacy system is software, sometimes together with the hardware it runs on, that an organisation still depends on but that has become hard to change, support or connect to anything else. That usually happens because the technology it was built with, or the people who built it, have moved on. Age alone does not make a system legacy: a fifteen-year-old system that fits the business and can be changed safely is simply an established one.
“Legacy system”, “legacy software” and “legacy application” are used to mean the same thing. Where people do draw a line, “system” takes in the servers, databases and connections around the program as well as the program itself.
What makes a system legacy
Three tests are more useful than the year it was written.
It is hard to change. Small requests take weeks, fixes cause new faults, and the people asked to work on it are wary of certain parts.
It is hard to support. The vendor has stopped issuing security fixes for the database, framework or operating system underneath it, or the skills needed to look after it have become scarce.
It is hard to connect. It cannot exchange data with the accounting package, the website or the other systems the business now uses, so people type the same information in twice.
A system that passes all three tests is not legacy, however old it is. A system that fails one of them is, even if it was built five years ago.
Examples of legacy systems in ordinary businesses
The term is often associated with banks and mainframes, but it applies just as well to much smaller systems. These are illustrations of the kind found in small and mid-sized organisations.
An Access database running stock
A member of staff built it years ago and it sits on a shared drive. It does the job, but everything is in one file that every user’s PC reads and writes directly, and nothing records who changed what. The version of Access it was built for may also be out of support: Access 2016 and Access 2019 both reached the end of support on 14 October 2025.
A VB6 desktop application
The program still runs, because Microsoft has kept the Visual Basic 6 runtime in Windows. Changing it is the difficulty. Support for the VB6 development tools ended in April 2008, and few developers now work in the language.
A .NET Framework web application on an old Windows Server
The application itself may be sound. The trouble is underneath it. Windows Server 2012 and 2012 R2, for example, stopped receiving free security fixes on 10 October 2023. The software has not changed, but the platform it stands on is no longer being repaired.
A spreadsheet with macros that prices every quote
Nothing about the technology is out of date, since Excel is a current product. The workbook is legacy because one person wrote the macros, nobody else will touch them and the business cannot issue a quote without it.
Why organisations keep legacy systems
Usually for good reasons.
- They work. The system does its job every day and staff know how to use it.
- They hold years of business rules. Pricing exceptions, approval steps and the special arrangement for one large customer are all in the code, and often nowhere else.
- Replacement is expensive and risky. A new system has to reproduce everything the old one does, including behaviour nobody remembers asking for, while the old one carries on running.
Keeping a legacy system is often the right decision. The mistake is keeping it without knowing which risks come with it.
The real risks
No security fixes. Once a vendor ends support for a platform, weaknesses discovered after that date are not repaired. Our end-of-support dates show where the platforms we are most often asked about stand.
Dependence on one person. If a single employee or contractor is the only one who understands the system, their holiday, illness or resignation becomes a risk to the business.
Slow and risky changes. Each change takes longer than the last, because shortcuts have built up in the code and there are no automated tests to show when something has broken. This is technical debt, and it is why changes to a legacy system tend to cost more than they should.
Integration limits. A system that cannot share data forces people to re-key it elsewhere, and the mistakes that follow are hard to trace.
What you can do about a legacy system
There are three options, and the right one depends on which of the problems above you have.
Maintain it. This suits a system that still fits the business, runs on a supported platform and has people who can look after it. The work is steady upkeep: security updates, fixes and small changes.
Modernise it in stages. This suits a system that is worth keeping but has parts holding it back, such as an out-of-support database, an old user interface or code with no tests. Those parts are replaced one at a time while the system stays in use, which preserves the business rules and spreads the cost.
Replace it. This suits a system that no longer matches how the business works, or one whose job a packaged product now does well. It is the most expensive and the riskiest route, because the old system has to be kept going until the new one is complete.
We go through how to choose between them in when to replace legacy software and when to keep it.
How to assess a legacy system
You can find out a good deal before involving a developer. Work through these questions.
- What does it run on? List the operating system, database, framework and other components with their versions, then check each against its vendor’s support dates.
- Do you have the source code? Ask whether anyone has recently built a working copy from it. Without source code that builds, the system cannot be changed.
- Who can change it? Name the people. If the list has one name on it, or none, that is the first risk to deal with.
- How did the last few changes go? Note how long each took, what it cost and whether anything else broke.
- What do people do outside it? Spreadsheets and side systems kept alongside show where it no longer fits.
- Has a backup ever been restored? A backup that has never been tested is an assumption.
- What should it connect to? List the systems it exchanges data with today and the ones you wish it did.
The answers will point towards one of the three options. Our ten-question check asks similar questions and gives a recommendation.
How we can help
CodeFirst is a UK company, founded in 2012, that maintains and modernises business software, including systems built by other people. We work mainly with Microsoft technology such as .NET and SQL Server. If you would like an independent view of a system you depend on, our code audit gives you a written assessment at a fixed price.