Why cloud migration still fails in 2025
Most failed migrations look identical: a date is announced, everything is lifted as-is, costs spike, and reliability regresses. Teams then spend the following months fixing problems that could have been designed out from the start.
The issue is rarely “cloud vs. on-prem.” It’s migrating without a clear business case, a stable landing zone, or a repeatable pattern for subsequent waves.
For technology leaders
As a CTO or VP of Engineering, your biggest risk isn’t whether a single cutover works— it’s whether the migration program stays credible after the first 3–4 waves.
- What you can delegate: tooling, detailed runbooks, individual app plans.
- What you must own: the migration thesis (why now), risk appetite, and how success is measured.
We make those trade-offs explicit and then design the technical plan around them.
The DevOps City migration approach
1) Strategy & business case
- Clarify the primary driver: cost, agility, resilience, or expansion—not all three at once.
- Model scenarios: stay-put vs. rehost vs. replatform vs. refactor, including TCO and risk.
- Define “done” in measurable terms (e.g., X% workloads moved, Y% cost delta, DR posture).
2) Landing zone & foundations
- Design cloud landing zones (AWS/Azure/GCP) with identity, networking, and guardrails baked in.
- Stand up shared services: logging, monitoring, DNS, key management, backup, SSO.
- Capture it as infrastructure-as-code so it’s repeatable and auditable.
3) Portfolio analysis & migration waves
- Inventory applications, data stores, integrations, and operational runbooks.
- Group workloads into waves by risk and business capability, not just org structure.
- Select 1–2 lighthouse apps to prove the pattern end-to-end before scaling out.
4) Execute, learn, and industrialize
- Run rehearsal cutovers and rollback drills; log friction, then update the playbook.
- Automate as much as is sensible: golden images, validation checks, smoke tests.
- Package the migration as an internal product: templates, FAQs, and office hours.
Migration scorecard
Executives need a simple way to see whether the migration is working. Dimensions, baselines, and targets are agreed with your organization before work starts.
| Dimension | Baseline (DC) | Target (Cloud) | Current |
|---|---|---|---|
| Run-rate infra cost | Set with you | Set with you | Tracked |
| Critical incident rate | Set with you | Set with you | Tracked |
| Apps migrated | Set with you | Set with you | Tracked |
| Teams on landing zone | Set with you | Set with you | Tracked |
What we aim to improve
- Predictable migration waves instead of hero projects.
- Landing zones designed to be reusable, so future regions and acquisitions can build on them.
- Cost and risk agreed up front with finance and security at the table.
- Operational readiness baked in—SLOs, DR, and on-call part of the definition of done.
How we typically engage
- Migration assessment: portfolio map, landing-zone gap analysis, and executive-level roadmap.
- First-wave delivery: co-delivery with your teams for 1–3 lighthouse workloads.
- Playbook & enablement: training, docs, and clinics so internal teams can own future waves.