Modernization begins with understanding which behavior must survive the change. A system may be awkward to maintain and still encode years of important operational knowledge.
Find the boundary
Identify a business capability with a clear owner, known inputs, and observable outputs. Document its data authority: which system holds the canonical record, and which systems consume copies?
That boundary is usually more useful than splitting software according to a technical layer. It gives the migration a purpose people outside engineering can understand.
Define proof before migration
Before moving a workflow, decide how to compare the old and new behavior. Useful checks include representative transactions, historical reconciliation, failure scenarios, and the actual user journey.
A running container proves that a process started. It does not prove that a business operation is correct.
Keep recovery concrete
A rollback plan should explain what happens to writes made after the cutover. Restoring an older application image may be insufficient if schemas or data semantics have changed.
Keep the first migration small enough to inspect. Agree on success criteria, ownership, and a decision point for continuing or reverting. Once that cycle works, repeat it across the next boundary.
Modernization is a sequence of managed changes. The architectural diagram matters, but so does the evidence that each step preserved the business.