Cloud migration starts with a dependency map, not a target platform

Cloud migration projects are often framed around a destination: which platform, which region, which landing zone design. The destination matters, but the work that determines success is understanding what currently depends on what.

Why dependencies decide the schedule

A reporting database that looks simple may be read by three finance tools, a nightly file job and a partner integration nobody documented. Move the database first and each of those breaks in a different way. The migration plan has to reflect those links.

Build the map before the plan

• Inventory applications, data stores, integrations and scheduled jobs, including the ones that run on servers nobody wants to touch.
• Record the data flows between them: what moves, how often, and who depends on the result.
• Classify each workload by business criticality, change frequency and compliance requirements.
• Identify the workloads that can move early because they are isolated and well understood.

Sequence in waves, each with an exit

Group workloads into waves by dependency and risk. Each wave needs cutover criteria, a rollback plan and, for systems that cannot tolerate downtime, a period of parallel running. A wave that cannot describe how it would be reversed is not ready.

Cost follows the same logic. Track spending by workload from the first wave, so that savings and overruns are tied to specific decisions rather than to a monthly total nobody can explain.