The word legacy makes people think of dead weight: brittle code, unloved infrastructure, strange admin workarounds, and a handful of staff who know which buttons not to press. That part is real. But legacy systems are often still carrying valuable operational knowledge. They hold the approvals, edge cases, naming conventions, report logic, and workarounds that keep the business moving.

That is why full rewrites go wrong so often. The old system looks ugly, so people underestimate how much real business behaviour is buried inside it.

Rewrite pressure is usually emotional before it is technical

Businesses reach for rewrite language when people are tired:

• the interface feels dated
• small changes take too long
• nobody trusts the codebase
• key staff are compensating with spreadsheets and manual checks
• new requirements keep colliding with old assumptions

Those are real problems. But they do not automatically mean “start again from zero”. Often they mean the business needs a more disciplined way to stabilise, understand, and improve the system in stages.

Modernise first when the business already depends on the workflow

A legacy system is usually a better modernisation candidate than a rewrite candidate when most of these are true:

• staff use it every day for important work
• it still produces core operational outcomes
• the pain is more about maintainability, speed of change, or UX than total functional collapse
• the business cannot tolerate a long cutover period or a high-risk migration
• there is embedded workflow logic that would be easy to miss in a fresh rebuild

In that situation, a rewrite is often the most expensive possible discovery process. You pay to re-learn what the old system already knew.

What modernisation can look like in practice

Modernisation does not mean “leave everything as it is”. It means improving the system in an order that reduces risk while increasing usefulness.

That can include:

• documenting the real workflow and hidden dependencies
• isolating brittle parts of the system so changes stop breaking everything else
• improving painful screens, forms, or field workflows first
• adding tests around high-risk logic before changing it
• cleaning deployment and release processes so safe iteration becomes normal
• migrating selected modules or integrations without freezing the whole business
• replacing spreadsheet sidecars with proper workflow support inside the system

This is the difference between software archaeology and software rescue. Archaeology just describes the mess. Rescue creates a path where the system can keep serving the business while it becomes less fragile.

When a rewrite actually is the right call

Sometimes the rewrite camp is correct. A replacement is more justified when:

• the system is barely functioning and people already work around it most of the time
• the architecture blocks the core business direction, not just developer convenience
• security, platform, or vendor constraints make the current stack commercially dangerous
• the real workflow is simple enough to rebuild with confidence
• the business is willing to fund a proper discovery and migration effort, not just a hopeful rebuild

Even then, the smartest rewrites usually begin with a modernisation mindset: map the workflow, preserve the important logic, and migrate with evidence instead of fantasy.

The practical question to ask

The question is usually not “is this code old?”

The better question is:

What is the fastest safe path to a system that is easier to change, easier to trust, and still supports the real business workflow?

Sometimes that answer is a rewrite. Very often it is staged modernisation.