Every legacy system is load-bearing: it runs the business, encodes decades of edge cases, and terrifies everyone who touches it. The instinct to rewrite from scratch is understandable — and it remains one of the riskiest projects a company can undertake.
Strangle, don't demolish
The strangler fig pattern replaces a system piece by piece: put a facade in front, route one capability at a time to new services, and let the old system shrink until switching it off is an anticlimax. Each step ships value and each step is reversible.
Sequence by risk-to-value
Start with a capability that's painful, well-understood, and loosely coupled — reporting is a classic first slice. Save the gnarly core (billing, inventory math) for when the team has muscle memory and the scaffolding is proven.
The tests you don't have
Legacy code rarely has tests, so build characterization tests first: capture what the system actually does today, warts included, so you can prove the new code behaves identically before improving it.
Modernization done this way is boring in the best sense — a steady drumbeat of shipped improvements instead of a two-year cliff. It's how we'd sequence it, and how we'd want our own systems handled.