Migrations overrun because the assessment covered infrastructure and skipped the two things that actually cause delay: undocumented application dependencies and a team that has never operated the target platform.
Assess per application, not per datacentre. Readiness varies enormously between applications. A single programme-level rating hides the two legacy systems that will consume most of the timeline.
Discover dependencies from traffic, not from documentation. Application owners consistently under-report integrations. Use connection logs and flow data over at least a month to find what actually talks to what.
Score team capability honestly. A team that has never run the target platform in production will be learning during the migration. That is survivable if planned for and expensive if assumed away.
Here's a preview. Unlock the free download to get all 3 sections (2 more below).
Score 1-5 per dimension. Anything scoring 2 or below needs remediation before the migration wave, not during it.
| Application | Business criticality | Dependencies mapped | Data portability | Licensing permits cloud | Team capability | Cost modelled | Total | Outcome |
|---|---|---|---|---|---|---|---|---|
| Finance ERP | Tier 1 | 3 | 4 | 2 | 3 | 4 | 16 | Conditional (licence review first) |
| Internal wiki | Tier 3 | 5 | 5 | 5 | 5 | 5 | 25 | Go (wave 1) |
More free templates IT teams use alongside this one.
Wave planning goes wrong when waves are grouped by team or by datacentre rack rather than by dependency. Applications that talk to each other must move together or tolerate the latency of being split, and that decision belongs in the plan.
Untagged cloud resources make cost attribution guesswork and orphaned resources invisible. Tagging only works if it is enforced at creation. Retrofitting tags across thousands of resources is a project nobody finishes.
Dependency maps built from interviews are wrong, because teams know what their application calls and rarely know what calls it. This one is built from observed traffic, with the interview used only to explain what you found.
Per application: dependency mapping from real traffic data, data portability and volume, licensing restrictions, team capability on the target platform, modelled run cost including egress, and a defined rollback approach.
Most often because of undocumented application dependencies discovered mid-cutover, and teams learning the target platform while operating it. Both are visible in advance if the assessment uses traffic data and an honest capability rating.
No. Some are cheaper and lower-risk where they are, and some should be retired instead of migrated. A readiness assessment that cannot produce a 'stay' or 'retire' outcome is not really an assessment.
