Legacy software is not defined by age. It becomes a problem when it prevents the organisation from changing safely, serving users effectively or controlling material operational risk.

01

Begin with the business constraint

A slow codebase, old framework or unattractive interface may be frustrating, but these are not yet a modernisation strategy. Identify the business capability being constrained: release speed, integration, customer experience, security, reporting or continuity.

This makes the investment testable. The modernisation programme can be judged by whether it improves the organisation's ability to operate and change—not whether the technology looks newer.

02

Assess four forms of health

A useful assessment looks beyond code quality. It examines the whole system that must continue delivering value.

  • Product health: user value, workflow fit and unresolved friction
  • Technical health: architecture, security, performance and maintainability
  • Operational health: monitoring, recovery, support and deployment control
  • Delivery health: ownership, knowledge, tests and the ability to change safely
03

Use incremental modernisation where continuity matters

For critical products, a staged approach often creates value sooner and reduces transition risk. Introduce stable interfaces around legacy functions, improve observability, replace high-risk components and move journeys progressively.

This approach still requires a clear target architecture. Incremental does not mean directionless; it means sequencing the change so that the organisation can keep operating and learning.

04

Rebuild only when the economics support it

A rebuild becomes defensible when the existing foundation cannot support essential requirements, the cost of safe change remains structurally excessive, or continuity can be protected through a controlled replacement path.

Even then, avoid recreating every existing feature. Treat the rebuild as a product decision: retain the workflows that create value, remove accumulated complexity and validate the new operating model before full migration.

Key takeawayThe right decision is rarely 'old versus new'. It is the smallest responsible change that restores the organisation's ability to operate, improve and grow.