In short
Legacy software refers to legacy systems that are in productive use but can only be maintained, extended or secured with difficulty. What matters is not the age of the code but the state of everything around it: missing automated tests, lost knowledge of the business logic, discontinued frameworks or platforms without vendor support.
A five-year-old system without tests and documentation can be legacy, whereas a twenty-year-old one with clean test coverage and an active team is not.
For managing directors and IT managers at mid-sized companies, legacy software is rarely an academic problem. It shows up as a release that nobody wants to touch any more, as a security vulnerability that can no longer be patched, or as an app that the store suddenly no longer accepts. This entry explains how to recognise legacy software, what risks it carries, what options there are for dealing with it and how to distinguish the term from technical debt, off-the-shelf software and custom software.
What makes legacy software: a definition without an age limit
The word "legacy" means inheritance or bequest. It refers to software that a company has taken over from earlier decisions, teams or service providers and that keeps running because operations depend on it. The problem is not that it is old but that nobody can say for sure what will happen at the next intervention.
The best-known technical definition comes from Michael Feathers. In his book "Working Effectively with Legacy Code" (Prentice Hall, 2004), he defines legacy code simply as code without tests. His reasoning: without tests, there is no way to check a change quickly and reliably. Every intervention becomes a blind flight, regardless of whether the code was written yesterday or fifteen years ago. This view is deliberately narrow but hits the core: legacy is a state of missing safeguards, not a date in the calendar.
In business practice, two further dimensions come into play. First, knowledge: if the original developer has left the company and the documentation consists of a folder of screenshots, the business logic is locked up in the code. Second, support: if the framework, runtime environment or operating system has been discontinued by the vendor, the system no longer receives security updates, even if your own code is clean. Legacy software is therefore software without tests, without knowledge or without support, usually in combination.
Why legacy is not the same as bad
A legacy system usually has years of productive operation behind it. It handles special cases that nobody has on their radar any more: the customer with the different invoice address, the discount logic from the 2019 trade fair promotion, the export for that one wholesaler. These cases are not documented anywhere, but the code handles them correctly. That is precisely why legacy software is both valuable and dangerous. Valuable, because it works. Dangerous, because nobody knows why.
Signs: how to recognise legacy software
There are hard and soft signals. You hear the soft ones in meetings: "We'd rather not touch that", "only our colleague can do that", "we never deploy on Fridays". The hard signals can be checked, and they often have a date.
Discontinued frameworks and platforms
The clearest sign is an end of support by the vendor. An example from app development: Microsoft ended support for Xamarin on 1 May 2024, as Microsoft's official Xamarin page confirms. Since then there have been no more updates, not even security fixes. Every Xamarin app still in the store today runs on a framework without a vendor. There are comparable cases in every technology family: PHP versions without security support, Java runtimes without updates, shop systems whose vendor has discontinued the product line.
Store deadlines for mobile apps
For mobile apps, the app stores set their own deadlines that apply independently of the framework. According to the official target API requirement, since 31 August 2026 Google Play has required new apps and app updates to target at least Android 16 (API level 36). Existing apps must reach at least API level 35 to remain visible to new users on newer devices. An extension until 1 November 2026 is possible on request.
Apple is tightening things in a similar way: according to the "Upcoming Requirements" page in the Apple Developer portal, since 28 April 2026 apps have had to be built with Xcode 26 and the iOS 26 SDK in order to be uploaded to App Store Connect. Anyone running an app on a discontinued framework often can no longer meet these requirements. A technical topic then becomes a business one: the app can no longer be updated, and at some point it disappears from the store.
Missing tests, missing knowledge, missing environment
The other signs are less tied to dates but just as verifiable. Are there automated tests, and do they run through in a CI pipeline? Is there a development environment that a new colleague can set up in a day? Is it known which libraries are in use in which version, ideally as a software bill of materials? Can a release be rolled out without manually copying files to the server? If any of these questions is answered with no, the system has legacy elements, even if it is only three years old.
Risks: what legacy software costs a company
The costs of legacy software are rarely an item on the balance sheet. They hide in maintenance budgets, in postponed projects and in risks that only become visible when they materialise. Four areas are particularly relevant.
Security. A system without vendor support receives no patches. Known vulnerabilities remain open, and attackers specifically look for exactly such installations. The US Government Accountability Office (GAO) documented this in its report GAO-19-471 (2019) on ten critical legacy systems of US federal agencies: the systems were between 8 and 51 years old; one of them had a total of 168 high or critical risk vulnerabilities as of September 2018, and another ran on hardware that the manufacturer no longer supported.
Compliance. Data protection, accessibility, product safety and sector-specific requirements continue to evolve. A system that can no longer be changed cannot map new requirements. This applies to the GDPR just as much as to store guidelines or auditors' requirements for traceability.
Staff. For discontinued technologies, the labour market becomes thin. The GAO report cites a COBOL system at the US Department of Education as an example and notes that the number of available specialists with the necessary knowledge is shrinking. The same pattern can be seen at mid-sized companies with old PHP frameworks or proprietary shop solutions: the few developers who know the system become a bottleneck and a concentration risk.
Vendor lock-in. Legacy systems often depend on a single service provider or vendor who is the only one who knows the code or holds the licence. This vendor lock-in weakens your negotiating position and makes any switch expensive. There is also an indirect effect: if 80 per cent of the IT budget flows into running the existing estate, as the GAO report puts it for the US federal administration (around 72 of more than 90 billion US dollars in fiscal year 2019), there is hardly any room left for anything new.
Options: four ways of dealing with legacy software
There is no standard answer. The right option depends on how business-critical the system is, how great the need for change is and how much knowledge is still in-house. In principle, four routes are open, and a combination often makes sense.
| Option | What happens | Suitable if | Typical risk |
|---|---|---|---|
| Continued operation | The system remains unchanged, is isolated and monitored | Little need for change, foreseeable end, small attack surface | Security vulnerabilities without a patch, creeping loss of knowledge |
| Refactoring | The code is gradually put under test and cleaned up; the functionality stays the same | The business logic is valuable, the technology is still viable, a team is available | Effort hard to estimate, visible benefit comes late |
| Gradual replacement | Functions are moved into a new system one after another; old and new run in parallel | Large system, high need for change, no downtime possible | Double operation, interfaces between old and new |
| Rewrite | Complete new development; the legacy system is switched off on a cut-over date | Small, clearly delimited system or a platform with no future | Loss of unknown business logic, long phase without releases |
The rewrite is the riskiest option
A complete new development sounds tempting because it gets rid of the ballast. In practice, it is the option with the highest failure rate. The best-known publicly documented example is provided by Joel Spolsky in his essay "Things You Should Never Do, Part I" (2000). Netscape decided to rewrite the browser code for version 6.0 from scratch. Three years without any significant release passed between version 4.0 and the 6.0 beta; there was never a version 5.0. During this time, Netscape lost the browser market to Microsoft. Spolsky calls the rewrite the "single worst strategic mistake" that a software company can make.
His argument is still valid today: what looks like disorder in the old code is usually bug fixes from years of real operation. Anyone who rewrites throws away this knowledge and builds the bugs in again. A rewrite is therefore only justifiable if the platform itself has no future (as with Xamarin) or the system is small enough to be understood completely.
Gradual replacement as the middle way
For most mid-sized company systems, gradual replacement is the most realistic route. Here the legacy system is not switched off but hollowed out piece by piece: a new component first takes over one function, such as the product export or the price calculation, and the legacy system calls it via an interface. With each step, more logic moves into the new world, until the old system is just a shell. This approach is known as the "strangler fig" pattern and has the advantage that each step can be rolled out and rolled back individually.
Legacy in mobile apps and in the back end: two different kinds
Legacy software follows different rules in the back end and in mobile apps, and that changes the decision.
In the back end, you control the runtime environment yourself. An old service on a well-maintained server can continue to run for years if it is isolated and only has defined interfaces to the outside. Here, continued operation with monitoring is a legitimate option, and refactoring can be done in small steps, because nobody outside your own team has to approve a release. The danger lies in invisibility: nobody notices a back end until it fails.
With mobile apps, third parties decide on the runtime. Apple and Google set deadlines for SDK versions, operating system updates change permission models, and a discontinued framework such as Xamarin cannot simply be "isolated". The app runs on customers' devices, not on your own server. Continued operation without updates is therefore only a matter of time until the app is thrown out of the store or crashes on new devices. For apps, the question is therefore rarely whether but when and where to migrate, for example to .NET MAUI, Flutter or React Native. The decision should be made before the next store deadline, not after it.
Legacy software at mid-sized companies: typical constellations
At mid-sized companies, legacy software appears in recurring patterns. The merchandise management system that a service provider custom-built twelve years ago and that has only been "maintained" since then. The online shop on a platform version whose vendor has discontinued support. The field sales app that nobody can rebuild since the framework reached its end. The collection of Excel macros that now controls half of production planning.
What these cases have in common is that the system is too important to switch off and too uncertain to touch. The first sensible step is therefore never the technology decision but an inventory: which business processes depend on the system? Which interfaces exist? Who knows the code? Which deadlines (end of support, store requirements, licence expiry) are coming up? Only with this picture can you decide whether refactoring, replacement or a rewrite is the economically best option. Our position: anyone who skips this analysis and starts straight away with the rewrite repeats Netscape's mistake on a small scale.
Distinction: legacy software, technical debt, off-the-shelf and custom software
Technical debt describes conscious or unconscious shortcuts in software development that later cost interest in the form of additional effort. Every piece of legacy software carries technical debt, but not all technical debt turns a system into legacy. A young project can have high debt and still be easy to test and well understood. Legacy software is the state in which the debt is so high that changes are no longer safely possible.
Off-the-shelf software is a product that a vendor develops and maintains for many customers. It becomes legacy when the vendor discontinues the version or the product, as with Xamarin. The customer can then usually repair nothing themselves because they do not own the source code. The only option is to upgrade to the successor version or to switch to another product.
Custom software is developed specifically for one company. It becomes legacy when knowledge, tests or the development team are lost, or when the underlying technology reaches its end of support. Unlike off-the-shelf software, the source code belongs to the company, so refactoring and gradual replacement are possible. That is the main advantage, but only if the company actually takes on the responsibility.
Frequently asked questions about legacy software
When does software count as legacy?
There is no age limit. Software counts as legacy if it is in productive use but can no longer be changed safely: because tests are missing, because knowledge of the business logic has been lost or because the framework or platform has been discontinued by the vendor. According to Michael Feathers, the absence of tests alone is enough for code to count as legacy.
Should legacy software always be replaced?
No. A system that runs stably, needs few changes and can be operated in isolation may continue to run. You should replace or phase it out if security updates stop coming, new requirements can no longer be implemented or only one person still knows the system. A complete rewrite is the riskiest option; gradual replacement is usually the safer route.
What is the difference between legacy software and technical debt?
Technical debt is the sum of the shortcuts in the code that cost additional effort later. Legacy software is a state: the debt is so high, or the environment so outdated, that changes are no longer safely possible. Technical debt can be reduced before a system becomes legacy; with legacy software, the reduction itself has become a risk.