Cloud migrations rarely fail on technology. They fail on incomplete discovery, missing foundations, and cutovers that were never rehearsed. This roadmap covers what actually determines success on AWS, Azure, or Google Cloud: an honest application of the 7R framework, a landing zone built before the first workload moves, data migration mechanics that preserve integrity, and a cost model that survives contact with the first invoice.

Start With Assessment and Discovery

Every migration plan is only as good as its inventory. Before choosing strategies, catalogue applications, servers, databases, licenses, and — most importantly — the dependencies between them. Undocumented dependencies are the single most common cause of migration-day surprises: the batch job nobody owns, the hardcoded IP address, the shared file mount three teams forgot about.

All three major providers ship discovery tooling: AWS Application Discovery Service and Migration Evaluator, Azure Migrate, and Google Cloud Migration Center. Run agents or agentless collectors for at least two to four weeks to capture real utilization and network flows, then classify each workload by business criticality, compliance constraints, and data gravity. The output should be a wave plan: groups of applications that move together because they talk to each other.

The 7R Framework, Correctly Defined

The industry-standard migration framework defines seven strategies, and getting the definitions right matters because each carries a different cost, risk, and timeline profile:

  • Rehost (lift and shift): Move the workload as-is onto cloud VMs. Fastest path, but not automatically cheap — an unmodified server fleet at on-demand rates often costs more than the hardware it replaced until it is right-sized and committed.
  • Replatform (lift, tinker, and shift): Make targeted optimizations during the move without changing the core architecture — for example, swapping a self-managed PostgreSQL for Amazon RDS, Azure Database for PostgreSQL, or Cloud SQL, or moving an app into containers on a managed Kubernetes service. It does not mean switching cloud platforms.
  • Refactor (re-architect): Redesign the application to be cloud-native — managed services, horizontal scaling, event-driven patterns. Highest effort and highest long-term payoff; reserve it for workloads where the business case is explicit.
  • Repurchase: Retire the self-hosted system and replace it with a SaaS product — the classic CRM move.
  • Retire: Decommission what nobody uses. Discovery typically finds 10–20% of an estate that can simply be switched off — the cheapest migration there is.
  • Retain: Deliberately keep workloads on-premises for now — latency-bound systems, regulatory constraints, or applications close to end-of-life.
  • Relocate: Move at the hypervisor level without re-architecting, using VMware Cloud on AWS, Azure VMware Solution, or Google Cloud VMware Engine. Useful for evacuating a datacenter on a deadline.

Most real programs mix strategies: retire and repurchase aggressively, rehost or relocate the long tail, replatform the databases, and refactor the handful of systems that differentiate the business.

Build the Landing Zone Before the First Workload

A landing zone is the multi-account (or subscription, or project) foundation your workloads land in: federated identity and SSO, a hub-and-spoke or shared-VPC network topology, centralized logging and audit trails, and guardrails enforced as policy — AWS Service Control Policies, Azure Policy, or GCP Organization Policies. AWS Control Tower, the Azure Cloud Adoption Framework landing zones, and Google’s Fabric FAST blueprints all provide opinionated starting points; whichever you choose, define it as infrastructure-as-code from day one. Migrating into a flat, hand-built account is how teams end up rebuilding their cloud estate eighteen months later.

Data Migration Mechanics

Data is where migrations get real. For databases, the pattern on every cloud is the same: an initial full load followed by change data capture (CDC) that keeps the target in sync until cutover. AWS Database Migration Service, Azure Database Migration Service, and GCP Database Migration Service all implement this, reducing downtime to the minutes it takes to repoint connection strings. If you are changing database engines, budget separately for schema conversion — tools like the AWS Schema Conversion Tool automate much of it, but stored procedures and vendor-specific SQL always need human review.

For file and object data, choose between online and offline transfer based on simple bandwidth math: moving 100 TB over a dedicated 1 Gbps link takes roughly ten days at full utilization. Online options include AWS DataSync, Azure Storage Mover and AzCopy, and Google Storage Transfer Service; when the math does not work, ship the data on AWS Snowball, Azure Data Box, or a Google Transfer Appliance. Whatever the path, validate with checksums and row counts — corruption discovered after the source is gone is unrecoverable.

Cutover Strategies

Plan cutover per wave, not per program. The three workable patterns are big bang (everything at once — only for small, low-risk systems), phased cutover (move components or user segments incrementally), and parallel run (old and new run side by side with results compared before the switch). In all cases: lower DNS TTLs days in advance, declare a change freeze around the window, and — non-negotiably — write and rehearse the rollback procedure. A rollback plan that has never been executed is a hypothesis, not a plan.

Cost Modeling Beyond the Calculator

Naive cost models compare on-demand list prices against depreciated hardware and conclude whatever the author wanted to conclude. An honest model includes the dual-running period when both environments are live, egress and data transfer during migration, migration tooling and staffing, and the operational cost of the retained estate. Commit to Reserved Instances or Savings Plans only after workloads have been right-sized and usage has stabilized — committing to an oversized footprint locks the waste in for one to three years. Once you are live, the work shifts to continuous optimization; our cloud cost cutting guide covers that loop in detail.

Common Failure Modes

  • Migrating unknowns: skipping dependency mapping and discovering integrations at 2 a.m. on cutover night.
  • No landing zone: landing workloads in an unstructured account and paying for the re-foundation later.
  • Treating rehost estimates as final: lift-and-shift is a starting position, not a steady state; without right-sizing, the bill disappoints.
  • Untested rollback: assuming reversibility instead of rehearsing it.
  • Forgetting the people: operations teams need cloud skills before go-live, not after the first incident.
  • The immortal “temporary” environment: dual-run setups that quietly bill for a year because nobody owned decommissioning.

Where to Start

Run discovery, assign each workload one of the seven Rs, build the landing zone, and move a low-risk wave first to exercise the machinery end to end. If you want experienced hands on the plan — from assessment through cutover — our cloud computing practice runs migration programs on AWS, Azure, and GCP, and our managed services team can operate the estate once you are there.

Tags: #Cloud #Migration #AWS #Azure #GCP #Strategy