Cloud migration planning: the risks that appear after the kickoff
Most migrations fail in the unglamorous middle: incomplete inventory, identity left until last, and cutovers that cannot be reversed.
A cloud migration is often announced as a date. The work that decides whether that date is honest happens earlier, and it is mostly inventory and politics. The technical patterns — rehost, replatform, rebuild — are the easy part of the conversation. The hard part is knowing what you actually run.
Inventory is a product, not a spreadsheet
Start with runtime truth: load balancers, scheduled jobs, file exchanges, vendor appliances, and the one virtual machine that still prints invoices. CMDBs are a hint. DNS, traffic, and the people who get called at night are better sources. If a dependency is missing from the map, it will appear during the cutover as an outage with a surprising owner.
- Name the system of record for each business process, not just each server.
- Record who can actually change it, which is often not the named application owner.
- Note the batch windows and customer commitments that constrain a weekend.
Waves beat a single leap
Group systems by blast radius and by the people who understand them. A first wave should include something that matters — otherwise you learn nothing — and something you can reverse. “Move everything in one freeze” is a project plan that assumes the inventory was complete.
Identity and networking are not week-twelve tasks
If people still share a root user, or if the new network cannot reach a payment processor, the first production login will be the first incident. Landing-zone work is unglamorous and should precede any serious workload move. So should a restore test. Backups that have never been restored are a story you tell yourself.
A migration that cannot roll back is not a plan. It is a hope with a status slide.
What “done” should mean
Done is not “the servers are in a different building.” Done is documented access, monitored user journeys, a cost view with owners, and a team that can change the environment without the people who ran the programme. If those are missing, you have relocated an estate, not modernized it.
Common questions
What should a cloud migration plan include?
A runtime-accurate inventory of systems and dependencies, the system of record for each business process, a migration strategy per workload, wave sequencing with rollback for each wave, a landing zone with identity and networking ready before the first move, and a definition of done that covers monitoring, access, and cost ownership.
What are the biggest cloud migration risks?
Missing dependencies discovered during cutover, identity and network access left until late, cutovers that cannot be reversed, untested backups, and costs that rise because workloads moved unchanged. Each is reduced by inventory work, early landing-zone build, rehearsed rollback, and restore tests.
This article supports our cloud engineering services. If the situation it describes is familiar, tell us about the systems involved.
