Legacy Modernization

How Legacy Modernization Works

In Legacy Modernization, the selection of a new technology should not come before clarifying the actual problem.
First, it must be clarified why an existing system should be changed.

Possible reasons include:

• lack of vendor or security support
• hardware or operating environments that are difficult to obtain
• security risks
• high operating or modification costs
• missing or unsuitable interfaces
• software that is difficult to modify
• problematic dependencies
• lack of knowledge about parts of the system
• requirements that the existing system can no longer satisfy

These problems can affect different parts of a system and therefore do not necessarily require the same solution.
Only when the specific problem and the relevant dependencies are sufficiently understood can it be decided which change is appropriate.

Modernization Is Not a Single Procedure

Between “everything stays as it is” and “we replace the entire system” lie many possible steps.

An existing system can, for example:

• be documented better
• be secured technically or organizationally
• be transferred to a different operating environment
• be opened through additional interfaces
• be separated from problematic dependencies
• be partially updated
• be combined with new components
• have individual functions gradually replaced by others
• be completely redeveloped or replaced by another product

Several of these measures can be combined or distributed over a longer period.
Modernization therefore describes a process of change rather than a specific technology.

First the Problem, Then the Modernization

It can be problematic to begin a modernization with a predetermined technical solution.

The question then is no longer, for example:

“Which problems do we need to solve?”

but:

“How do we get this system into the cloud?”

A possible solution has thereby already been made a prerequisite.
This can be reasonable if there are already well-founded reasons for this decision. Without such reasons, however, there is a risk that only the technical environment will be changed while the actual problems remain.
A system that is difficult to understand does not automatically become easier to understand because it is operated on a new platform.
A problematic dependency does not necessarily disappear if both components involved are replaced with more modern products.
And an unsuitable process does not become better simply because it is reprogrammed.

Small Changes Can Be Modernization

Legacy Modernization does not have to be a large transformation project.
Suppose an old system works reliably but has only a proprietary data export that makes its replacement or integration more difficult.
A small additional component could convert this export into a documented open format.
The original system initially remains unchanged.
Nevertheless, its position within the overall architecture changes: Other systems no longer need to know its proprietary data structure directly, and later replacement can become easier.
A comparatively small technical change can therefore prepare a larger modernization step.

Incremental Modernization

Especially with central or poorly documented systems, incremental change can reduce risks.
Instead of completely shutting down the existing system at a specific point in time, individual functions can be extracted from it or replaced one after another.
Old and new components can temporarily exist in parallel.

This makes it possible to:

• test individual changes separately
• observe effects in real operation
• use experience from one step for the next
• discover unknown dependencies earlier
• limit the scope of a change when problems occur

Incremental modernization may take longer than complete replacement. In return, it can reduce the risk of intervening simultaneously in many unknown parts of an existing system.

Not Every Dependency Has to Disappear

Modernization is sometimes associated with the goal of eliminating as many dependencies as possible.
Technical systems often have dependencies on other components, systems, or their environment.
What matters is therefore which dependencies exist and what consequences they have.
A stable, documented, and replaceable interface can represent a perfectly acceptable dependency.

Dependencies become problematic, for example, when they:

• are unknown
• become visible only indirectly
• are undocumented
• make changes unnecessarily difficult
• practically prevent changing providers
• cannot be controlled
• affect a disproportionately large part of the system

Modernization can therefore also mean not removing dependencies, but making them visible, understandable, and controllable.

Why Legacy Modernization Has Practical Effects

• Changes can be limited: Not every problem requires replacing the entire system.
• Existing functions can be preserved: Proven parts of a system do not have to be replaced without reason.
• Risks can be reduced incrementally: Critical areas can be addressed one after another.
• Migrations become more controllable: Old and new components can be operated together during a transition.
• Dependencies can be made visible: Connections to other systems can be documented or restructured.
• Later decisions become easier: Small modernization steps can prepare future changes.
• Technology remains a means to an end: The selection of new technology follows the problem to be solved.

Typical Example

A company operates an older application that is required for an important business process.
The application itself works reliably. Its operating environment, however, is problematic: The operating system in use no longer receives security updates and can only be operated on new hardware to a limited extent.
In addition, several other systems access the application’s database directly.
One possible modernization could proceed incrementally.
First, the functions and dependencies that actually exist are examined. The application is then moved to a more controllable operating environment.
A defined interface is created for other systems so that direct database access can gradually be removed.
Only then is it decided whether the application itself also needs to be replaced.
The modernization therefore does not consist of a single replacement, but of several targeted changes that address different risks of the existing system.

Distinction

• A Legacy System refers to an existing system whose current technical or organizational situation can cause particular challenges.
• Legacy Modernization refers to possible changes to this system or its environment.
• A migration can be part of a modernization, but is not the same thing. Migration initially describes the transfer of systems, data, or functions from one environment to another.
• Solution Architecture and System Integration can also play a role in modernization. Solution Architecture describes the fundamental structure of a planned solution; System Integration concerns the interaction of the systems involved.
• Legacy Modernization is also not automatically digital transformation. It can be limited to a single, clearly defined technical problem area.

Further Reading

Related Concepts

→ Legacy System
→ Systems Analysis
→ System Architecture
→ Solution Architecture
→ System Integration
→ Verification and Validation
→ Resilience
→ Digital Sovereignty