Legacy System

When a System Becomes a Legacy System

There is no specific point in time at which a technical system automatically becomes a Legacy System.
A system that is ten, twenty, or forty years old can continue to perform its task reliably. A much younger application, by contrast, can already be difficult to maintain or almost impossible to modify.
Age or the technology used are therefore not the only decisive factors.

Indicators of a legacy situation can include, for example:

• technologies in use are no longer supported
• necessary knowledge is available only from a few people
• documentation is missing or no longer reflects the actual system
• changes have effects that are difficult to predict
• other systems depend on specific functions or data
• interfaces have grown historically
• data can only be transferred with considerable effort
• spare parts, development tools, or operating environments become difficult to obtain
• organizational processes depend on the system’s existing behavior

Not every one of these points automatically makes a system problematic.
What matters is their significance for the specific operation.

Functioning Old Systems Are Not Automatically a Problem

Technical modernization can easily create the assumption that older systems should generally be replaced.
That is not necessarily sensible.

An existing system can:

• function reliably
• be fully understood
• incur low operating costs
• have only a few dependencies
• fulfill its task adequately
• have been proven in practice for years

In such a case, continued operation can make more technical and economic sense than replacement.
A new technology does not have an advantage merely because it is newer.
The relevant question is rather whether the existing system can fulfill its current and foreseeable future task under acceptable conditions.

The Invisible System Around the System

In practice, a system that has been operated for a long time often consists of more than the actual software or hardware.

Additional structures may have arisen around its original function:

• scripts and utility programs
• data exports and imports
• spreadsheets and reports
• interfaces to other applications
• manual control steps
• organizational rules
• workflows
• knowledge held by individual employees
• exceptions and special cases

These components can be just as important to actual operation as the original system.
Replacing a single application can therefore affect processes that, at first glance, do not appear to be connected to it at all.

Lost Knowledge Changes Maintainability

In systems that have been operated for a long time, knowledge about their origin and operation can be lost.
Developers leave a company. Documentation is not updated. Temporary solutions remain in place permanently. The reasons for earlier decisions are no longer known later.
This changes the practical maintainability of the system.
Two technically identical systems can therefore have very different legacy characteristics.
If one is fully documented and maintained by people who understand its relationships, it can be developed further without problems.
With the other, even small changes can represent a considerable risk because their effects cannot be reliably assessed.
Legacy is therefore not exclusively a property of the technology used. Available knowledge and the embedding of a system in its environment also play a role.

Why Legacy Systems Have Practical Effects

• Changes require more preparation: Unknown dependencies must first be investigated.
• Migrations can have unexpected consequences: Other systems or processes can depend on existing behavior.
• Knowledge becomes an operational factor: Missing documentation and lost knowledge can make technical changes more difficult.
• Continued operation can be sensible: Not every older system has to be modernized.
• Partial modernization becomes possible: Individual problematic components can be changed without replacing the entire system.
• Risks can be considered more specifically: Age, support, dependencies, and modifiability can be evaluated separately.

Typical Example

An application has generated a file containing current order data every evening for twenty years.
The application itself is to be replaced.
During Systems Analysis, it becomes apparent that three other processes use this file. One of them is documented. The second was set up years ago by an employee. For the third, initially all that is visible is that the file is retrieved regularly.
The new system could fulfill all officially documented requirements of the old application and still disrupt operations if this inconspicuous export disappears.
The challenge of the Legacy System in this case does not primarily lie in its age.
It lies in dependencies that have developed over the years and must first be understood before a change is made.

Retain, Modify, or Replace?

A Legacy System does not necessarily have to be replaced completely.

Depending on the problem and constraints, different options can be considered:

• continue operating unchanged
• secure operation
• document it
• update individual components
• add interfaces
• remove problematic dependencies
• migrate data
• move functions incrementally
• replace parts of the system
• replace the entire system

Which option is appropriate can only be assessed once enough is known about which function the system actually performs and what effects a change would have.
Possible changes to a Legacy System or its environment are the subject of Legacy Modernization.

Distinction

• A Legacy System initially refers to an existing system in a particular technical and organizational situation.
• Legacy Modernization, by contrast, refers to possible changes to such a system or its environment.
• A Legacy System is also not the same as technical debt. Technical debt describes consequences of certain technical decisions that can make later changes more difficult or create additional effort. A Legacy System can contain technical debt, but does not have to have become a Legacy System for that reason alone.
• Systems Analysis and System Architecture also refer to something different. They provide methods and models that can be used, among other things, to examine and describe Legacy Systems and their dependencies.

Further Reading

Related Concepts

→ Systems Analysis
→ System Architecture
→ Solution Architecture
→ System Integration
→ Legacy Modernization
→ Digital Sovereignty