What's actually left in the stalled 20%
Legacy systems with no current owner, applications tightly coupled to on-premises hardware for reasons nobody fully documented, and workloads whose business case for migration was always weaker than the easy wave's are what remain — and they need a different kind of planning, not just more migration engineering effort.
Throwing the same migration playbook that worked on easy workloads at this remainder is the most common reason the stall continues for years rather than months.
What actually unsticks it
Naming an accountable owner for each remaining workload, building an honest business case for each one individually rather than assuming the original programme case still applies, and being willing to decommission rather than migrate some of them, is what actually moves a stalled migration forward.
The last 20% stalls because nobody owns the decision, not because nobody can move the workload.MNB Cloud Practice
Key actions
- Name an accountable owner for every remaining unmigrated workload
- Build an individual business case per workload, not a blanket programme case
- Consider decommissioning instead of migrating where the case is weak
- Avoid applying the easy-wave playbook unchanged to harder remaining workloads