Legacy modernization gets hard because the old system is usually still doing real work. It may be ugly, slow, and expensive to change, but the business has learned how to survive around it. A rewrite that ignores that reality creates a second problem before it solves the first one.
The work I trust is incremental, observable, and reversible. Move one capability at a time. Put measurement around it. Keep the old path available until the new one has earned production confidence.
Where should modernization start?
Start where risk is concentrated and the boundary is understandable. That might be a reporting pipeline, an integration layer, a billing workflow, or a release process that keeps slowing the team down. The first win should teach the organization how the migration will work while proving the new stack can run.
For example, move invoice generation behind a switch. Run the new path in shadow mode and compare line items and totals with the old output, without sending a second invoice. Keep the old path authoritative until discrepancies are explained. Test switching back before routing customer-visible work to the replacement.
What should leaders be able to see?
Modernization needs a scoreboard people outside engineering can understand. Availability, latency, incident rate, release frequency, support load, and rollback safety usually matter more than framework choices. Those metrics turn architecture work into business risk removal.
How do you keep trust during the migration?
Keep continuity visible. Show what changes, what stays the same, where rollback lives, and how teams will know whether the new path is ready. Technical strategy matters, but trust is what keeps the organization from freezing halfway through the work.
If this is the kind of problem your team is working through, I am always glad to compare notes.