What is a legacy system?

A legacy system is an application or infrastructure still in production, often at the center of critical processes, that has become hard to change: the stack it runs on is no longer supported or updated, the skills needed to work on it are scarce or held by one person, and the original vendor no longer offers support. It is not a matter of age: a system written twenty years ago that still gets patches, has tests and up-to-date documentation is not legacy, while a five-year-old application written with no tests and never touched since can already be. NIST frames it as an environment that must stay secure against today's threats while often using older, less secure communication mechanisms, and that gap is exactly what defines the problem: the system keeps working, but the world around it, threats, regulation, integration expectations, has not stood still.

See also: Mainframe and COBOL modernization · The strategies to move mainframe COBOL applications toward sustainable architectures: rehosting, conversion, rewrite or APIs.

The signals that give it away

A system qualifies as legacy when several precise signals show up together. The platform or language no longer receives security updates, or the vendor has declared end of life. No external vendor still offers a support contract for that version. The people who genuinely understand the internal logic are one or two, often close to retirement, a case of tacit knowledge concentrated in a few heads rather than in documentation. Integrating it with something new, a CRM, a dashboard, an AI model, requires custom work instead of a standard API. No single signal is enough on its own to call a system legacy: together, they point to a risk that grows every year without a plan.

The options, at a glance

The available strategies sit on a spectrum of risk and cost. Keep and encapsulate: leave the internal logic untouched, but expose it through an integration layer that makes it consumable by the rest of the company, the principle behind an anti-corruption layer. Rehost: move the system as it is onto more modern infrastructure, buying time without solving the underlying problem. Progressive refactor: replace it one module at a time behind a common facade, the pattern known as strangler fig, the most cited approach for cases like AS/400 modernization or COBOL mainframe modernization. Full replacement: retire it for a new platform, typically a standard package, as in an ERP migration, accepting the risk of rewriting business logic that already worked.

A concrete example

A mechanical engineering SME runs orders and bills of materials on a custom application written fifteen years ago. It still works, but the server's operating system no longer gets patches and the only developer who knows it is an outside contractor close to retirement. Instead of rewriting it, the company exposes its functions through an API for the new e-commerce site and documents the bill-of-materials calculation rules nobody had ever written down.

Why it matters for decision makers

Doing nothing has a cost that grows over time. A system with no security patches is an attack surface that widens every month that passes. Regulations such as NIS2 or GDPR ask companies to demonstrate adequate controls on every system that handles critical data, and an environment that can no longer be updated is hard to bring into compliance. And accumulated technical debt is not the system that keeps running: it is everything you cannot build on top of it while it stays locked there, while the one person who genuinely understands it gets closer to retirement. Deciding which strategy to adopt, and when, costs less than having the decision made by an incident or an unplanned departure.