Cloud migrations rarely fail outright. They stall, overrun, or land somewhere more expensive and no more capable than where they started. Six problems account for most of it.
Challenge 1: The bill is higher than the data centre
This is the most common post-migration shock, and it is usually the predictable result of a lift and shift.
The cause is that a data centre is a fixed cost you have already paid for, while cloud is a variable cost that bills for exactly what you provisioned. A server running at 8% utilisation costs you nothing extra on-premises and full price in the cloud. Migrating it unchanged converts a sunk cost into a recurring one.
What resolves it: right-size after two weeks of real metrics rather than matching old specifications. Commit to reserved capacity or savings plans for the stable baseline — usually a 30–50% reduction for a one or three-year commitment. Turn off non-production environments outside working hours, which alone often saves 60% of their cost. And model data transfer explicitly; egress charges are the single most commonly missed line.
Challenge 2: Dependencies nobody documented
Every estate has a server that something important talks to and nobody remembers. It surfaces during cutover, at the worst possible moment.
What resolves it: observed dependency mapping rather than documented. Capture actual network flows over a two-week period and build the map from traffic, not from the wiki. Then, before each move, disconnect the workload in a controlled window and see what complains. A deliberate short outage during discovery is far cheaper than an accidental long one during cutover.
Challenge 3: Data gravity
Large datasets are slow to move and expensive to move back, and everything that uses them wants to be near them. This produces a migration that gets 80% done and then stops, with the application layer in the cloud and the database still in the data centre, paying latency and transfer costs on every query.
What resolves it: sequence around the data rather than around the applications. Decide where each dataset will live first, then move the things that use it. Where the move must be staged, accept a temporary hybrid but set a hard end date, because the hybrid state is more expensive and more fragile than either end state.
For genuinely large volumes, physical transfer appliances shipped to the provider are routinely faster than network transfer, and the arithmetic is worth doing rather than assuming.
Challenge 4: The team does not know the platform yet
Engineers who are expert in the existing environment are novices in the new one, and the migration is the worst possible time to learn. Mistakes made in the first months — flat networks, over-permissive roles, resources created by hand — become the permanent shape of the environment.
What resolves it: train before migrating, not during. Give the team a sandbox account and a month of low-stakes building. Bring in outside help specifically for the landing zone design, which is the part that is hardest to change later and easiest to buy expertise for. And write down the standards — naming, tagging, network layout — before the first production workload lands.
Challenge 5: Downtime expectations are unrealistic
Someone promises zero downtime, nobody has budgeted for the engineering that zero downtime requires, and the migration either slips or happens with an unplanned outage.
What resolves it: negotiate the window honestly and early. Most businesses can tolerate a planned four-hour window at 2am on a Sunday; very few can tolerate an unplanned two-hour outage on a Tuesday. Trading a planned window for reduced risk is almost always the right deal, and it is much easier to agree three months out than three days out.
Where genuine zero downtime is required, budget for it as a distinct piece of work: dual writes, replication, traffic shifting and a rollback path. It is achievable and it is not free.
Challenge 6: The programme stalls halfway
The first few workloads move, the team gets pulled onto product work, and eighteen months later half the estate is in each place. This is the most expensive outcome available — two environments, two sets of tooling, two sets of expertise, and the benefits of neither.
What resolves it: three things. A named owner with authority rather than a committee. A visible countdown — a decommissioning date for the old environment, agreed with whoever signs the contract renewal, which creates a real deadline. And a cadence of small, completed moves rather than one large programme, so progress is continuously visible and the effort survives a reprioritisation.
The pattern underneath all six
Each of these is a planning failure rather than a technical one. The technical work in a migration is largely known and largely solved; what goes wrong is the discovery that was rushed, the dependency that was assumed, the cost that was not modelled, the deadline that was not real.
Weighting the schedule toward discovery and landing-zone design — perhaps a third of the total effort before anything production moves — is the single change that most reliably separates migrations that land from migrations that stall. Our cloud migration checklist sets out that sequence in order.
What to measure while it runs
Four numbers, reviewed fortnightly, keep a migration honest.
- Workloads migrated against plan. Not percentage complete, which is always 80%.
- Run cost in both environments. The combined figure is what the business is actually paying, and seeing it rise focuses attention on decommissioning.
- Incidents attributable to the migration. A rising count means you are moving too fast or testing too little.
- Date of old-environment shutdown. Tracked as a commitment, not an aspiration.
Two smaller problems that bite
Beyond the six above, two issues come up often enough to plan for.
Licensing. Database and operating-system licences are frequently priced per physical core or tied to specific hardware, and cloud instances count differently. Teams discover mid-migration that moving a commercial database multiplies the licence cost. Check every commercial licence against cloud terms during discovery, not after.
Backup and recovery assumptions. The old environment’s backup regime usually relies on something that does not exist in the new one — a tape library, a SAN snapshot, a script on a jump box. Recovery is the thing nobody tests until they need it, and a migration is an excellent moment to find out your restore procedure references a server that no longer exists. Run a full restore test in the new environment before decommissioning the old one, while you still have a fallback.
Deciding whether to migrate at all
Not every estate should move, and the question deserves an honest answer before the programme starts rather than a defensive one afterwards.
Migration tends to pay off where workloads are variable or seasonal, where the team wants managed services instead of maintenance, where a hardware refresh or data centre contract is due anyway, or where geographic expansion is planned.
It tends not to pay off where workloads are large, steady and already running on owned, depreciated hardware; where data volumes are enormous and mostly static; or where regulatory constraints would force a private deployment that captures none of the economics.
A credible answer requires modelling three years of total cost in both scenarios, including the migration itself and the staff time it consumes. Teams that skip this step often find themselves defending a decision made on general principle.
Frequently asked questions
Is hybrid cloud a permanent option?
It can be, deliberately, for regulatory or latency reasons. What causes trouble is accidental hybrid — the state a stalled migration leaves behind. See hybrid cloud vs multi-cloud for the distinction.
How much contingency should a migration plan carry?
Thirty to fifty percent on time for a first migration. Teams that have done it before can work to tighter estimates; teams that have not should not pretend to.
Should we migrate everything at once?
Only for very small estates. Staged migration is slower in total but far less risky, and it lets the team learn on low-stakes workloads first.
What is the best indicator a migration is in trouble?
The old environment’s decommissioning date moving more than once. Everything else can slip for good reasons; that date slipping repeatedly means the programme has lost momentum.
