Cloud migration overruns are the norm rather than the exception: roughly 75% of migrations exceed their budget, IDC puts the average overrun at 23%, and around 18% end up rolling at least some workloads back. The projects that land are the ones that assess before they move, migrate in waves, and budget for the parallel-running period nobody quotes.
This guide covers how to assess an estate, choose a strategy per workload, sequence the waves, and cut over without a rollback.
Key takeaways
- Budget 10–20% above the quote: Data transfer, parallel running, retraining and legacy integration are the costs that get omitted.
- Migrate in waves, never all at once: The first wave should be low-risk and chosen to teach you what the estate is really like.
- Lift-and-shift rarely saves money on its own: Cost reduction comes from what you do after landing, not from moving.
- Plan the rollback before the cutover: Nearly one in five migrations needs one.
Assess before you plan
An estate inventory is the deliverable that decides everything else. For each application record what it does, who depends on it, what it integrates with, its data volume and sensitivity, its performance profile, and whether anyone still understands it.
Two categories emerge immediately and are worth acting on before any migration: systems nobody uses that can be retired, and systems whose owner has left. The first is free money. The second is the risk that surfaces in wave three if you do not find it now.
Choose a strategy per workload
| Strategy | What it means | Effort | When it fits |
|---|---|---|---|
| Retire | Switch it off | None | Usage collapsed or another system covers it |
| Retain | Leave it where it is | None | Regulatory, latency or licensing reasons to stay |
| Rehost | Move as-is | Low | Time pressure; datacentre exit deadline |
| Replatform | Small changes to use managed services | Medium | Managed database or container hosting removes real operational cost |
| Repurchase | Replace with SaaS | Medium | The process has become standard |
| Refactor | Restructure for the platform | High | The application is strategic and its architecture blocks growth |
Most estates use four or five of these. Applying one strategy uniformly is the most common planning error, and it usually means either an expensive refactor of something about to be retired, or a lift-and-shift of something that needed rebuilding.
Understand what actually reduces cost
Lift-and-shift moves a workload without changing its shape, so it usually costs the same or more once you add migration effort. Savings come afterwards: right-sizing instances, moving to managed services, adopting reserved or committed pricing, shutting down non-production environments outside working hours, and lifecycle rules on storage.
Budget the optimisation phase explicitly. A migration that lands and stops produces a cloud bill that surprises everyone in month three, one reason 84% of organisations report struggling to manage cloud spend.
Sequence the waves deliberately
Wave one should be low-risk, well-understood, and chosen for what it teaches: an internal application with few integrations and tolerant users. Its purpose is to expose your real constraints, network, identity, deployment, monitoring, while the cost of being wrong is low.
Sequence later waves by dependency rather than by size. Applications sharing a database move together or not at all, and an integration crossing the boundary between migrated and unmigrated systems is where latency and failure appear.
Keep waves small enough that a rollback is a decision rather than a crisis.
Budget for the costs nobody quotes
| Hidden cost | Typical impact |
|---|---|
| Data egress from the old environment | Charged per gigabyte; large for data-heavy estates |
| Parallel running | Both environments billed for the overlap, often months |
| Staff retraining | New tooling, new operational model |
| Integration to systems left behind | Frequently the largest single surprise |
| Testing environments | Duplicated during transition |
| Rollback capacity | Held in reserve and unused if all goes well |
These commonly add 10–20% to the original estimate. Adding them to the plan turns an overrun into a forecast.
Decide the data strategy first
Data is where migrations fail. Answer before committing: how much there is, how long the transfer takes at your available bandwidth, whether the source can be read-only during cutover, how the two sides are reconciled while both run, and what the acceptable data loss window is.
Large estates frequently need physical transfer appliances or an extended replication period. Both are cheaper than discovering the transfer alone takes eleven days during your cutover weekend.
Plan the cutover and the rollback together
Write the cutover as a runbook with timings, owners and a decision point: what condition triggers a rollback and who is authorised to call it.
Rollback is only real if you have rehearsed it and if the old environment is still capable of taking traffic. Turning off the source too early is what converts a recoverable problem into an incident, and roughly one in five migrations needs that path.
Measure the outcome you promised
Set the baseline before you move: infrastructure cost, deployment frequency, incident rate, and performance for the journeys users notice.
Cloud migration is often approved on cost and then judged on agility, or the reverse. Naming the measure in advance is what allows the programme to be assessed on evidence rather than on whoever describes it most confidently afterwards.
Related guides
- If that is the next question, read AI Workflow Automation: Use Cases, Risks, and Roadmap.
- The question this one leaves open is answered in Admin Dashboard Development: Features, Architecture, and Cost Drivers.
If Cloud Migration Roadmap: From Assessment to Cutover means getting the foundations right before adding features, Discuss Your Platform Foundation.
Ali Boran Gazel