"Modernise the legacy system" is one of those phrases that sounds like a single project. In practice it's several different problems wearing the same name, and conflating them is how modernisation efforts stall.
Legacy isn't a technology problem first
Old code isn't inherently the issue — code that still does its job reliably is doing fine. The real signal is whether the system can absorb change: can you add a feature, fix a bug, or bring on a new engineer without everything taking three times longer than it should.
Rewrite, replatform, or refactor
A full rewrite is rarely the first move. Replatforming (moving the same logic onto current infrastructure) or targeted refactoring of the worst-behaved modules usually gets more value for less risk than starting over, and keeps the business running while it happens.
“The goal isn't newer code. It's a system the business can keep changing without fear.”
Where to actually start
Start with the part of the system that blocks the most other work — usually a data layer or an integration point everything else depends on. Fixing the highest-leverage constraint first makes every subsequent change cheaper.
Modernisation succeeds when it's sequenced around what's actually slowing the business down, not around what looks oldest.