Migration tooling gets attention; wave sequencing gets ignored until a cutover fails and the rollback plan turns out to be untested.
We grade dependencies by confidence: confirmed in production logs, inferred from documentation, or unknown. Unknown links stay out of early waves — full stop.
Rollback is a decision, not a hope
Every wave needs a named go/no-go authority, trigger conditions written in plain language, and a rehearsed fallback that includes data consistency checks — not just "restore from backup."
Dual-run periods cost money but buy verification time. For revenue-critical services, we prefer a limited parallel run with compared outputs over a big-bang weekend.
After each wave, hold a short retrospective: what broke, what was slower than expected, what documentation was wrong. Feed that into the next wave plan — not a generic lessons-learned deck filed away.
Migration risk accumulates in dependencies, not Gantt charts. The expensive failures are undiscovered integrations and rollback paths that were never timed.
Frequently Asked Questions
What is the highest hidden migration risk?
Undocumented batch feeds and identity dependencies — often discovered only during dress rehearsal.
How many dress rehearsals are enough?
At least one technical full rehearsal for tier-1; two if rollback has not been executed under time pressure in 12 months.
Should we migrate risky workloads first or last?
Depends: sometimes a small risky pilot early reveals patterns; tier-1 usually follows once patterns and tooling are proven.
How do you quantify migration risk?
Dependency count, rollback time proven in rehearsal, change window margin, and operational readiness score per workload.