What makes software "legacy"

Legacy software does not mean old software. Some 20-year-old systems run just fine and continue to serve their business well. Legacy, in the meaningful sense, means software that has become a constraint — on the business's ability to change, to grow, to integrate with other systems, or to attract and retain engineers who can maintain it.

The signals that software has crossed from "old but fine" into "legacy problem":

Changes take much longer than they should because the codebase is hard to understand or modify safely
Engineers avoid touching certain parts of the system because they are afraid of what might break
The technology is no longer maintained or supported — the underlying framework, language version, or database is end-of-life
Integrating with new systems is extremely difficult because the architecture was not designed for it
It is becoming difficult to recruit engineers who know the technology
The system has reliability problems that are difficult to diagnose and fix

If your system shows two or three of these signals, you are looking at a legacy problem. If it shows four or more, it is probably already affecting your business in ways that are measurable.

When to modernise vs when to manage

Not all legacy software needs to be modernised immediately. The decision involves balancing the cost of modernisation against the cost of continuing to manage the legacy system, and both of those need to be measured honestly.

The case for modernisation is stronger when:

The business is growing and the legacy system is limiting the rate of growth
The technology is reaching end-of-life and will present security risks without modernisation
Engineer productivity is materially affected by the legacy codebase
Competitive requirements demand capabilities that the legacy system cannot support
Integration requirements cannot be met with the current architecture

The case for managing rather than modernising is stronger when:

The system is stable and the business is not growing in ways that stress it
The cost of disruption from modernisation exceeds the cost of continuing to manage it
The business is considering strategic changes (acquisition, pivot) that would change the requirements anyway

The modernisation options

Incremental modernisation (strangler fig pattern)

Named after a plant that gradually envelops and replaces a tree, the strangler fig pattern involves replacing the legacy system component by component, with each new component replacing part of the legacy system's functionality while the rest continues to run.

Traffic is gradually shifted from the legacy system to the new components as each one is completed. Eventually, the legacy system handles nothing and can be decommissioned.

This approach has significant advantages: the legacy system remains live throughout, changes can be rolled back if problems arise, and the modernisation is much less likely to cause a business-disrupting failure than a big-bang rewrite.

Rewrite with parallel run

A complete rewrite of the system, run in parallel with the legacy system until the new system is verified to work correctly, then a cutover. The legacy system is decommissioned after a period of parallel operation.

This is appropriate when the legacy system is so architecturally compromised that incremental modernisation would cost more than a clean rewrite, or when the technology change required makes incremental migration impractical.

The risk is the "second system effect" — rewrites often take much longer than estimated and the new system often replicates bugs or missing features from the old one because the full behaviour of the old system was not fully documented. Rigorous testing and user acceptance testing of the new system before cutover is essential.

Encapsulation and API layer

Rather than replacing the legacy system, wrapping it with an API layer that exposes its functionality in a modern, integrable way. The legacy system continues to run internally but external systems interact with the API layer rather than directly with the legacy system.

This is useful when the legacy system works well but cannot be easily integrated with. It buys time and enables new integrations without a full modernisation. It is not a permanent solution — the legacy system still has its other problems — but it can be the right pragmatic step in the short term.

Common modernisation mistakes

The big bang rewrite

Throwing out the entire legacy system and building a replacement from scratch, with the intention of switching over on a defined date. This approach fails more often than it succeeds. The scope of the legacy system is almost always larger than it appears from the outside, the rewrite takes longer and costs more than estimated, and the cutover date becomes a source of enormous pressure that typically results in quality shortcuts.

Modernising without first understanding the legacy system

Legacy systems contain accumulated business logic that is often not documented anywhere — it lives in the code and in the heads of the people who have been maintaining it. Beginning modernisation without thoroughly understanding this logic means the new system will be missing behaviour that users depend on and do not even know to mention because it "just works".

Modernising the technology without addressing the architecture

It is possible to spend significant money upgrading a legacy system to a modern technology stack while leaving the underlying architectural problems — poor modularity, tangled dependencies, bad data model decisions — entirely intact. The result is a legacy system with a new face. Define architectural improvements as explicit goals of the modernisation, not optional extras.

A practical starting point

If you are considering legacy modernisation, the right starting point is a thorough assessment of the current system. This covers: the technology stack and its maintenance status, the architecture and its major weaknesses, the business logic embedded in the system, the integrations that exist and are needed, the data model and its quality, and the reliability and performance characteristics.

From that assessment, you can develop a prioritised modernisation plan that addresses the most business-critical problems first and works within the constraints of keeping the business running throughout.

Legacy Software Modernisation: When and How to Upgrade Your Systems