UNIXDEV

What is a legacy system? Examples and modernization

A legacy system is software a business still relies on but finds hard to change or support. See examples, risks and four ways to modernize it.

By UNIXDEV Team · 5 min read
Original published · English edition

Editorial illustration for What is a legacy system? Examples and modernization

A legacy system is software or a system an organization still relies on for important work, but which is built on technology the vendor no longer supports or that few people can maintain. As a result, it becomes steadily harder to change, integrate or keep secure.

Age alone does not make a system legacy. An older system that is still supported and easy to change is not the problem; the constraints that make change, operation or support difficult are.

Common examples of legacy systems

Legacy systems are not tied to one language or vendor. Common examples, grouped by technology (end-of-support dates are taken from each vendor's lifecycle page, checked in October 2026):

  • Mainframe and COBOL programs: core transaction systems that still run, but COBOL skills are getting harder to find and business rules often live in the code and in a few people's heads.
  • AS/400 (IBM i) and RPG programs: the issue is usually not the platform itself but old RPG programs, OS releases that were never upgraded, or long-serving hardware.
  • VB6 and FoxPro: desktop or client-server programs written long ago. Microsoft ended support for the Visual Basic 6.0 IDE on April 8, 2008. The runtime is still supported for the lifetime of supported Windows versions, limited to serious regressions and critical security issues, so the programs still run, but there is no supported tool to keep changing them.
  • Older ERP: ERP customized so heavily that it cannot follow the vendor's upgrades, or a version the vendor no longer supports. Check the support dates with each vendor.
  • PHP 5 web applications: PHP 5.6, the last PHP 5 branch, reached end of life on 31 December 2018. Applications tied to PHP 5 are usually also tied to old frameworks or libraries that must be upgraded with it.
  • Windows Server 2003 to 2012: extended support for Windows Server 2003 ended in July 2015 and for Windows Server 2008 in January 2020. Windows Server 2012 and 2012 R2 extended support ended on 10 October 2023, and the third and final year of paid Extended Security Updates ended on 13 October 2026. Servers still running these versions no longer receive security updates from Microsoft.
  • CentOS 7: CentOS Linux 7 reached end of life on 30 June 2024, so application and database servers still on it no longer receive updates from the project.

Legacy system vs legacy application: a legacy application is the program or code itself; a legacy system usually means the whole stack, from the application and database to the operating system, hardware and integrations. The terms are often used interchangeably, but separating them shows which layer needs work. If the application is sound but the operating system is out of support, moving platforms may be enough without rewriting the application.

If these systems cannot move yet, read how to keep an end-of-support legacy system running safely. If the system has no documentation or its authors have left, see taking over an undocumented legacy system. Agencies hiring a contractor to maintain an existing system can start from what a legacy-maintenance TOR should specify.

Six signs to examine

  • Dependencies or platforms no longer receive the support you need.
  • Only one person understands an important part of the application.
  • Changes are difficult to test and release safely.
  • Integration relies on fragile manual transfer or undocumented behavior.
  • Performance or capacity limits affect real users.
  • Access, backup or recovery arrangements are unclear.

These signs call for an assessment. They do not automatically justify replacing the entire system.

Why modernization gets postponed

The risk of change is easier to see than its benefit

The existing system works well enough on an ordinary day, while a migration has an obvious cost and interruption risk. Describe the recurring operational cost and constraints with evidence so both sides of the decision are visible.

Knowledge lives with people

Business rules may exist only in code or in the memory of long-serving staff. Recover that knowledge through workflow reviews, representative records and tests before changing the implementation.

Funding does not match continuing work

A one-time project budget may not cover assessment, gradual improvement and ongoing operation. Plan the phases and operating costs explicitly rather than treating maintenance as an afterthought.

No one can coordinate the decision

Modernization crosses business units, suppliers and technical teams. Identify an owner who can resolve priorities and secure decisions, with technical support for the trade-offs.

The team fears a failed cutover

Reduce uncertainty through rehearsal, data reconciliation, rollback criteria and a clear approval process. Some systems can change in stages; others need a tightly planned transition window.

The cost of doing nothing

Unsupported components, scarce skills, repeated defects and slow delivery can accumulate. Assess these risks against the actual system and business consequences. Avoid using age alone as a proxy for security or reliability.

Four modernization approaches

  • Rehost: change where the system runs with limited code change.
  • Replatform: update selected infrastructure or platform components.
  • Refactor: improve internal structure or interfaces while preserving required behavior.
  • Rebuild: create a replacement when the business need or system condition justifies it.

A staged plan can combine these approaches. Define how old and new parts exchange data and how each stage will be accepted. If you are refactoring and deciding whether to split into microservices, see from legacy to cloud-native.

Start with a supportable next step

Inventory the code, data, accounts and dependencies. Verify backups and restore procedures. Document critical workflows and establish a test environment. Then compare options with scope, risks and acceptance checks.

UNIXDEV’s legacy application maintenance service begins with that assessment. The content-platform operations case study illustrates ongoing care alongside change without claiming that every workstream finished at once.

Continue reading