A financial services firm starts a cloud migration in January. By June they're six months in, 40% over budget, and the production environment is still on-premise because every cutover attempt has revealed something the assessment missed. The board is asking questions. The IT team is exhausted.

This scenario has a name in the industry: "cloud migration purgatory." It's common, it's expensive, and it's almost entirely preventable with the right approach upfront.

Why Migrations Go Wrong

The most common failure mode is the wrong migration strategy applied at the wrong time. There are six ways to move a workload to cloud — rehost, replatform, refactor, repurchase, retire, retain — and they have very different risk profiles, timelines, and cost implications. A migration that treats every workload as a simple "lift-and-shift" will create a cloud environment that's more expensive and less reliable than the on-premise it replaced.

The Discovery Phase Nobody Skips Enough Time On

The most valuable investment in a cloud migration is the first four weeks: a thorough discovery and dependency mapping exercise that answers questions most migrations only encounter mid-flight.

• What are the actual dependencies between applications? Not the documented ones — the actual ones, discovered by monitoring network traffic.
• Which workloads have regulatory data residency requirements that constrain cloud region selection?
• What are the licensing implications of moving commercial software to cloud? (This is where surprise costs appear.)
• Which applications will require refactoring to run in cloud, and which can be rehosted with minimal risk?
• What are the performance baselines — latency, throughput, concurrency — that the migration must match or exceed?

Every hour spent in discovery saves three hours of emergency debugging mid-migration.

The Phased Migration Model

We never recommend big-bang migrations. The risk concentration is too high and the blast radius of a problem too large. Instead, we organise migrations into waves, ordered by risk and dependency:

Wave 1: Non-critical development and test environments. Low risk, high learning value. Build cloud muscle before touching production.

Wave 2: Stateless or easily replicable production workloads. Deploy to cloud in parallel, run dual-stack, validate performance, then cut over with a tested rollback procedure.

Wave 3: Stateful and complex production workloads. By this point your team has handled dozens of cutovers. The process is tested. The monitoring is mature. The surprises are behind you.

This approach means your first production cutover is never your first cloud deployment. The team has already done it twenty times in lower-stakes environments.

What a Successful Migration Actually Delivers

Beyond the infrastructure shift, a well-executed migration creates the foundation for everything that follows: container orchestration, auto-scaling, CI/CD pipelines, infrastructure-as-code, and the observability stack needed to manage cloud at scale. Done right, migration isn't just a destination — it's the beginning of a genuinely better infrastructure posture.