Home / Insights / Architecture and Modernization
Architecture and Modernization
Why Cloud Migrations Fail — and How to Rescue One That Is Going Wrong
Cloud migrations often run late, cost more than expected or fail to deliver the promised benefits. This guide sets out the usual causes, the warning signs and a practical rescue plan for migrations that have stalled.
TopicsArchitecture and ModernizationSoftware Costs and BudgetsBusiness Operations and Integration
Key takeaways
- Most migration failures start before the first workload moves: unclear goals, incomplete discovery and unrealistic timelines.
- Lift-and-shift without optimisation can raise costs; re-architecting everything at once raises risk. Choose a strategy per application.
- Warning signs include repeated delays, rising cloud bills with old infrastructure still running, frequent incidents and team burnout.
- Rescue starts with a pause to reassess goals, inventory and costs, then re-plans in smaller waves with clear success criteria.
- Build cloud skills, cost governance and operations practices alongside the migration, not after it.
On this page
Cloud migration promises flexibility, resilience and lower costs. Yet many organisations find their migration taking longer than planned, costing more, or leaving them with a mix of old and new infrastructure that is harder to run than before. The good news is that most failures share a small set of causes, and most stalled migrations can be recovered.
Common causes of failure
| Cause | How it shows up |
|---|---|
| — | — |
| Unclear business goals | Success is not defined; priorities shift; benefits cannot be shown |
| Incomplete discovery | Hidden dependencies, undocumented integrations and licences surface mid-migration |
| One strategy for everything | All applications lifted and shifted, or all re-architected, regardless of fit |
| Underestimated data migration | Large databases, downtime constraints and data quality problems cause delays |
| Cost surprises | Running old and new environments in parallel; oversized cloud resources; data transfer fees |
| Skills gaps | Teams learn cloud operations under pressure; security and reliability suffer |
| Weak governance | No tagging, budgets or landing-zone standards; inconsistent security |
| Change management | Operations, finance and business users not prepared for new processes |
Several causes usually combine.
Choose a strategy per application
| Strategy | When it fits |
|---|---|
| — | — |
| Retire | Unused or duplicate applications |
| Retain | Applications not worth moving yet |
| Rehost (lift and shift) | Quick moves with tight deadlines, followed by optimisation |
| Replatform | Small changes for managed services, such as managed databases |
| Refactor or re-architect | Applications needing scalability or modernisation |
| Repurchase | Replace with software as a service |
Decide per application based on value, complexity and risk.
Warning signs
- Milestones slip repeatedly without root causes being addressed.
- Cloud spending rises while on-premises costs have not fallen.
- Incidents increase after migration waves.
- Teams spend most of their time firefighting rather than migrating.
- Stakeholders cannot say what the migration has achieved so far.
A rescue plan
- Pause new waves briefly to stop compounding problems.
- Restate goals: what must the migration achieve — exit a data centre, improve resilience, reduce costs, enable new products — and by when?
- Rebuild the inventory: applications, dependencies, data volumes, owners and current status.
- Assess costs: current cloud spend, remaining on-premises costs, waste and quick savings.
- Stabilise operations: monitoring, backups, security baselines and incident processes for what has already moved.
- Re-plan in smaller waves grouped by dependency, with clear entry and exit criteria.
- Close skill gaps with training, partners and clear ownership.
- Report progress against goals, not just workloads moved.
Cost control during migration
- Set a target date to decommission each on-premises component once its replacement is stable.
- Right-size cloud resources after a few weeks of real usage.
- Tag everything from the first day.
- Use commitment discounts only after usage patterns are clear.
- Watch data transfer costs between environments.
Our guide to FinOps in the software lifecycle covers ongoing cost management.
Example
A hypothetical logistics company had moved 40% of its applications in 18 months — mostly lift-and-shift — while its cloud bill grew and its data centre contract remained. A rescue review found that half the remaining applications could be retired or replaced with SaaS, the largest database needed a staged migration with change data capture, and no one owned cloud costs. The company re-planned the remaining work in four waves, retired 30 applications, assigned cost owners and set a firm data-centre exit date. Progress became measurable again.
Frequently asked questions
Is lift-and-shift a mistake?
Not necessarily. It can be the fastest route out of a data centre, provided it is followed by optimisation. Problems arise when it is the only plan.
How long should a cloud migration take?
It depends on the number and complexity of applications. Plan in waves of weeks to a few months each, with value delivered along the way.
Should we bring in a partner?
A partner helps when skills are missing or the programme has stalled, but ownership and knowledge must stay with your team.
Can we move back on-premises?
Some organisations repatriate specific workloads where cloud costs are consistently higher. Base the decision on measured costs and requirements.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
Related reading
Continue your research
Is your cloud migration stuck or over budget?
Share where you are and what is going wrong. We will assess the situation and help you build a realistic recovery plan.