Modernize, or make peace with it

Legacy is not a synonym for bad. It is software that survived long enough to matter. The system everyone complains about is often the one quietly running payroll, billing or dispatch, and it got there by being useful.

The expensive mistake is treating modernization as a moral obligation. Rewrites consume years, carry real risk and frequently recreate the original system's problems in a newer language. The better question is not "is this old?" but "is this old in a way that is costing us?"

Score the estate, not the feelings

For each significant system, score four things on a simple scale:

• Business criticality — what stops if this stops?
• Change frequency — how often does the business need it to change?
• Risk — security exposure, unsupported components, people who are the only ones who understand it.
• Cost of ownership — licences, infrastructure, and the hidden cost of slow change.

High criticality combined with high change frequency is where modernization pays back. Those systems sit on the path of the business's ambitions, and every month of friction compounds.

Make peace with the rest

Stable, low-change systems usually deserve containment rather than replacement. Wrap them behind a clear interface, add monitoring, document how they work and who owns them, and plan for the specific risks — an unsupported runtime, a single expert. Then stop apologizing for them.

When you do modernize, go incrementally

Prefer strangler patterns over big-bang rewrites. Route one capability at a time to the new system, keep the old one running until the new path is proven, and retire pieces as you go. You get value early, you can stop at any point, and a bad decision costs weeks rather than years.

The goal is an estate where every system is either improving on purpose or stable on purpose. That is a far more achievable target than "modern", and a far more useful one.