The first modernization decision is rarely a technology decision. It is a sequencing decision: what should change first, what should remain stable, and how can the organization learn without putting critical operations at risk?
01 / Establish the facts
Start with a fact-based baseline, not a migration plan
Before moving anything, build an accurate picture of the current state. Map infrastructure, applications, dependencies, ownership, cost, resilience, and the operational work that keeps each service running. Migration plans built on assumptions tend to stall when an unmapped dependency appears in the path of a release.
02 / Create the case
Prioritize by business value, not technical age
The oldest system is not automatically the best first candidate. Prioritize workloads that constrain agility, block revenue, create material risk, or absorb disproportionate operational effort. A stable legacy service may be a sensible retain decision while a newer, tightly coupled platform becomes the first modernization wave.
03 / Choose the right move
Treat different workloads differently
Not every workload needs to be refactored into microservices. A practical portfolio uses different strategies for different constraints:
04 / Build momentum
Move in waves, not one big program
Establish a secure, compliant landing zone first. Move a low-risk pilot to prove the tooling and operating model. Then continue in controlled waves, improving the platform and the run-state processes as you learn. Delivery should become a repeatable capability rather than a single heroic effort.
The practical takeaway
Good modernization reduces uncertainty before it increases velocity. Establish the facts, choose the right treatment for each workload, and let every wave improve the next one.