TL;DR: Migrations that go wrong almost always fail the same five ways: no dependency mapping, a big-bang cutover, lift-and-shift applied blindly to everything, security bolted on after the move, and no cost guardrails before go-live. None of these are exotic failure modes, they're predictable, which means they're avoidable. A real 7-month phased migration (40+ workloads, sensitive regulated data) shipped with under 2 hours of total cutover downtime and zero compliance gaps by avoiding exactly these five.
Cloud migration has a reputation for being risky, and the reputation is earned, but not because migration is inherently dangerous. It's because most failures trace back to the same five mistakes, made in roughly the same order, on roughly every project that skips them. Fix these five and a migration stops being a leap of faith and starts being boring, in the best sense.
The four phases, in order (skipping one causes the next one's failure)
| Phase | What happens | Skip it and... |
|---|---|---|
| 1. Assess | Inventory workloads, map every dependency | Hidden dependencies break at cutover |
| 2. Plan | Sequence into waves, pick a strategy per workload, define rollback | You improvise mid-migration |
| 3. Migrate | Move in waves, test, then cut over | Untested waves fail in production |
| 4. Optimize | Right-size, harden security, add cost controls | You inherit a migrated-but-unmanaged mess |
The order matters more than any individual step. A team that rushes past assessment doesn't skip that work, it just does it during cutover, under pressure, in front of users.
The five mistakes that actually cause outages
| # | Mistake | What breaks | The fix |
|---|---|---|---|
| 1 | Skipping dependency mapping | Hidden shared DBs / internal APIs break when only one side moves | Map every dependency before anything moves |
| 2 | Big-bang cutover | One failure takes down the whole business at once | Migrate in small, reversible waves |
| 3 | Lift-and-shift everything | You inherit old problems at cloud prices | Pick a strategy per workload (the 7 Rs) |
| 4 | Security bolted on after | Gaps and compliance failures surface late, expensive to retrofit | Build encryption, least-privilege, and compliance checks into every wave |
| 5 | No cost guardrails | The first full bill is a shock | Tag, budget, and right-size before go-live, as part of the plan |
Two of these deserve a closer look, because they're the ones teams underestimate specifically because they feel optional.
Why "just lift-and-shift it" is a trap
A pure lift-and-shift is the fastest way to get something running in the cloud, and applied to everything, it's the fastest way to pay cloud rates for the same problems you had on-prem. The fix isn't "never lift-and-shift," it's choosing per workload, using the well-known 7 Rs (rehost, replat form, refactor, repurchase, retire, retain, relocate). Some apps genuinely just need to move as-is. Others are wasting money staying architecturally frozen. The mistake is applying one strategy to a portfolio that needs several.
Why the cutover strategy matters more than the migration tooling
Big-bang cutovers concentrate every risk into a single weekend. Wave-based migration does the opposite: start with low-risk, non-production workloads, prove the process works, and only touch critical systems once you've built confidence through repetition. Each wave is small enough to be reversible, which means a wrong call costs you an hour of investigation, not an incident review.
Migrating securely (not securing it afterward)
Security added post-migration is a retrofit, and retrofits are slow and leaky. The teams that get this right decide three things before anything moves: data travels over a private connection (not the public internet) for sensitive workloads, everything is encrypted in transit and at rest, and migration tooling gets least-privilege access, nothing broader. Each workload gets validated against its compliance rules before cutover, not assumed to have carried over. For jurisdictions with real residency rules (NESA, TDRA, SBP, or similar), that validation includes confirming data landed in the right region, not just that the app is running.
Case study: 40+ workloads, under 2 hours of total downtime
A Dubai insurance group needed to move off an aging on-prem data center while holding sensitive policyholder data under NESA and TDRA rules, meaning a big-bang move wasn't an option and neither was cutting corners on compliance. Seven-month phased migration, client engineers pairing throughout so they'd own the platform afterward:
| Risk | What we did | Outcome |
|---|---|---|
| Unknown dependencies | Full discovery and dependency mapping first | Zero cutover-day surprises |
| Downtime fear | 40+ workloads migrated in small waves | Under 2 hours total cutover downtime |
| Sensitive data + compliance | Encrypted transfer, least privilege, residency by design | NESA + TDRA cleared, zero data loss |
| Runaway cost | Right-sizing and FinOps built into the optimize phase | Run cost 24% below the old data center |
The number that mattered wasn't any single stat, it's that all four came out of the same seven months, because none of the five common mistakes got made. Confidence didn't come from a big reveal at the end; it came from every small wave working, which is what made the final critical cutover feel routine instead of terrifying.
FAQ
What's the single biggest predictor of a bad migration?
Skipping dependency mapping. Almost every cutover-day surprise traces back to a dependency nobody documented before the move started.
Is lift-and-shift always the wrong call?
No, it's the wrong default. Some workloads genuinely just need to move as-is. The mistake is applying it to every workload instead of choosing a strategy (one of the 7 Rs) per app.
How do you migrate regulated data without a compliance gap?
Validate each workload against its compliance rules before cutover, not after, and build encryption, least-privilege access, and residency checks into every wave rather than adding them once everything's already moved.
Originally published on the Sherdil Cloud blog, the full piece (with the complete four-phase framework and secure-migration checklist) is here. For choosing a strategy per workload, see legacy system modernization; for the cost-guardrails side, cloud cost optimization strategies.
About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.
Top comments (0)