What Actually Breaks During a Cloud Migration

Ask a team what went wrong six weeks after a bad migration. Nobody ever says "we picked the wrong instance type." The compute was fine. The network was fine.

What broke was something nobody had written down.

Here is where it goes wrong, roughly in the order it hurts.

The dependency nobody knew about

Every old system has a few connections that live only in someone's memory. A nightly job that reads a file share. A reporting tool with a hardcoded IP. A partner that allowlists one outbound address. A certificate from an internal CA that a service quietly trusts.

None of these are on the architecture diagram. They show up at 2am on cutover night.

The fix is boring. Before you plan anything, capture real traffic. Flow logs, connection tables, DNS queries, over a full business cycle. Include month end, because that is when the batch jobs nobody remembers finally run. Compare that against the documented architecture. The gap between them is your real risk list.

Identity is always the hard part

On premises, a lot of access control is implicit. A service works because it runs on a machine inside a trusted network, under an account that collected permissions over the years. Nobody has audited it.

Move that workload to the cloud and the implicit trust is gone. Every permission has to be written down. The quickest way to get the application working again is to grant something far too broad and promise to tighten it later.

That is how migrations turn into security findings. Give identity mapping real time and treat it as its own workstream, not a task hidden inside the application work.

Data size is a schedule problem

Teams usually get the transfer mechanics right. What they underestimate is time.

A few terabytes over a limited link, with a consistency requirement and a fixed cutover window, is a scheduling problem that can take over the whole project.

Work backwards from the longest downtime you can accept. If the maths does not fit, you need a different approach, either replication with a short final sync or a phased move. You need to know that in week two, not week twenty.

Slow things that used to be fast

Applications built on premises assume the components sit in the same rack. Split them across availability zones and a service that makes 400 sequential calls per request becomes the slowest thing you own.

This is not a cloud problem. It is an old design assumption that the previous environment was hiding for you. Find the chatty paths before the move, because afterwards they will be reported as "the cloud is slow."

The cutover nobody practised

The most common serious failure is procedural.

The runbook exists. Nobody has run it end to end. Nobody has timed it. Nobody has tested the rollback. The rule for aborting is "we will know it when we see it," which under pressure means the team keeps pushing past the point where going back was still cheap.

So practise the cutover against an environment that looks like production. Time every step. Write down the abort conditions and the go/no-go checkpoints in advance, while everyone is calm. Check that rollback is actually possible at each stage. In most data migrations there is a point where it stops being possible, and everyone should know exactly where that point is.

What this adds up to

The infrastructure part of a migration is the part we all understand. The risk sits in the joins: hidden coupling, implicit trust, physics, old assumptions, and untested procedure.

That is why discovery is the phase to protect when the schedule gets tight. It is always the first thing cut, and it is always the thing that would have caught the problem.