The expensive part of legacy software isn't always the software.

Legacy systems are easy to criticise.

They can be expensive to maintain, difficult to integrate and dependent on technologies that fewer engineers want to work with.

The case for replacement may seem obvious.

But the true cost of a legacy system is not always visible in its source code, infrastructure or licensing.

Much of it exists in the business processes that have grown around the software.

The behaviour around the system

Over years, people adapt to a system's limitations.

They build spreadsheets beside it, informal checks around it and timing habits that work around its batch jobs.

A finance team may export data every morning because two systems do not reconcile automatically.

An operations manager may maintain a separate spreadsheet because the official application cannot represent a particular business exception.

A customer service team may know that some records need manual correction before an order can proceed.

These practices become part of the real operating model, even when they are absent from documentation.

Replacing the application without understanding these dependencies does not necessarily remove the complexity.

It may simply transfer that complexity back to employees during the transition.

The hidden dependency problem

A legacy application rarely operates alone.

Other systems may depend on its database structures, exports, identifiers, scheduled jobs or undocumented behaviours.

Some integrations may not even be recognised as integrations. A spreadsheet generated every Friday and imported elsewhere on Monday is still a dependency.

Before modernisation, the engineering team needs to understand:

• —Which systems exchange information with the application?
• —Which business decisions depend on its outputs?
• —Which workflows rely on manual intervention?
• —Which behaviours are intentional, and which are historical workarounds?
• —What happens if a dependency stops working during migration?

The answers often change the proposed architecture.

Replace, modernise or isolate?

Full replacement is one option, but not the only one.

Replacement

A new system takes over the responsibilities of the legacy application.

This may be appropriate when the existing platform cannot meet essential security, reliability, integration or business requirements.

However, replacement creates migration, adoption and operational risks that must be managed.

Incremental modernisation

Selected components or workflows are improved while the existing system continues operating.

This approach can reduce immediate disruption and provide opportunities to validate the new architecture progressively.

Integration and isolation

A stable legacy system may remain in place behind a controlled interface while surrounding applications are modernised.

This can be useful when replacement costs are high and the existing system still performs its core responsibilities reliably.

The right decision depends on business risk, technical constraints, cost, maintainability and the expected life of the system.

Migration is an operational problem

A migration plan is not complete when the new software passes functional tests.

The business also needs confidence that data, workflows and responsibilities will survive the transition.

A disciplined migration approach includes:

1. 01Discover actual usage. Observe the workflows performed by real users, including exceptions.
2. 02Map dependencies. Identify interfaces, data flows, scheduled processes and manual handovers.
3. 03Define equivalence. Decide which existing behaviours must be preserved and which should be deliberately changed.
4. 04Validate data. Establish reconciliation and quality checks before transferring critical records.
5. 05Introduce changes progressively. Use staged rollout, parallel operation or controlled migration where appropriate.
6. 06Prepare recovery. Define how failures will be detected and what fallback or rollback options are feasible.

Not every migration supports a simple rollback. Data transformations and changes to operational processes may make reversal difficult.

These limitations must be understood before the transition begins.

Measure the business outcome

Modernisation should not be judged only by the age of the technology stack.

Useful measures may include processing time, operational errors, availability, integration effort, change lead time, maintenance cost and the amount of manual work required.

A technically modern platform that increases operational complexity may not represent a successful transformation.

Conversely, a carefully modernised legacy environment can deliver significant value without replacing every component.

The engineering outcome

The purpose of modernisation is not to make software newer.

It is to make the business more reliable, adaptable and easier to operate.

That requires understanding the technology and the human processes built around it.

Sometimes the right answer is a full replacement.

Often it is a sequence of carefully engineered changes that allows the business to improve without losing the knowledge embedded in its existing systems.