Cloud migration is the process of moving applications, data, and workloads from on-premises infrastructure (or another cloud) into a cloud platform, and the single most important decision for each workload is which of the "6 R's" migration strategy it gets — Rehost, Replatform, Repurchase, Refactor, Retire, or Retain — because that choice determines the cost, timeline, and risk of everything that follows. A well-run migration is not a weekend copy job; it is a five-phase program — assess, plan, prepare, migrate, and optimize — where discovery and cutover rehearsal consume far more effort than the data transfer itself. Get the strategy tagging and the cutover rollback plan right, and the rest is disciplined execution.
That's the summary an AI Overview would give you. Here's what it can't show you: the actual decision logic for picking a strategy per workload, an animated view of how a phased migration flows wave by wave, and a cutover checklist that keeps your rollback path open. Those are the parts that decide whether your migration ships on time or stalls for a year.
The 6 R's: pick one strategy per workload
Every workload in your inventory gets exactly one label. Don't skip this — an untagged workload is one nobody has decided how to move, and it becomes the thing that blocks cutover at 2 a.m.
| Strategy | What you do | Effort | Best when | Watch out for |
|---|---|---|---|---|
| Rehost (lift & shift) | Move VMs as-is to cloud compute | Low | You need out of the datacenter fast; app is stable but unremarkable | Inherits on-prem inefficiency; no cost win without later right-sizing |
| Replatform (lift & reshape) | Minor tweaks — e.g. swap self-managed DB for managed RDS | Low–Medium | A small change unlocks real savings or ops relief | Scope creep — "small tweak" quietly becomes a refactor |
| Repurchase (drop & shop) | Retire the app, adopt a SaaS equivalent | Medium | A mature SaaS covers the need (email, CRM, HR) | Data migration + user retraining; feature gaps |
| Refactor (re-architect) | Rebuild for cloud-native / serverless | High | High-value app where elasticity or cost payoff justifies engineering | Longest, riskiest; only worth it for workloads that matter |
| Retire | Decommission entirely | Very low | Nobody actually uses it (you'll be surprised how many) | Confirm no hidden dependencies before you pull it |
| Retain | Leave on-prem for now | None | Latency, compliance, or licensing blocks the move | Becoming a permanent "temporary" exception |
| Which should I pick? | Default to Rehost to escape hardware fast, then Replatform/Refactor the workloads where the payoff is provable. Repurchase commodity apps. Retire the dead weight first — it's free savings. | — | — | — |
The opinionated take: most estates should rehost first and optimize later. Trying to refactor everything before migrating is the classic way a cloud program burns a year and delivers nothing. Move, stabilize, then improve the workloads that earn it.
The five phases of a migration
A migration is not one event; it is a pipeline. Each phase feeds the next, and skipping discovery is how teams end up cutting over an app whose hidden dependency on an on-prem license server takes production down.
Phase 1 — Assess
You cannot migrate what you cannot see. Build a full inventory of applications, servers, and data stores, then map dependencies — which service calls which, what shared databases exist, which app quietly depends on an on-prem file share or license server. Discovery tools that watch network traffic beat spreadsheets here. Output: every workload tagged with one of the 6 R's and a rough dependency graph.
Phase 2 — Plan
For each workload, define its RTO (how long it can be down) and RPO (how much data loss is acceptable). Those two numbers drive everything downstream — the replication method, the cutover window, and whether you need a live rollback path. Group workloads into waves by dependency so tightly-coupled systems move together. Set a cloud budget with automated alerts now, before a single resource is provisioned.
Phase 3 — Prepare
Build the landing zone: a segmented VPC, least-privilege IAM roles (do not clone your broad on-prem admin accounts), networking and DNS, a load balancer in front of scalable tiers, and encryption in transit and at rest. Turn on logging and configuration monitoring here — misconfiguration is the leading cause of cloud breaches, and you want it caught on day one, not after cutover. A zero-trust architecture posture, where no network location is implicitly trusted, is the right default for a fresh environment.
Phase 4 — Migrate
Replicate data (ongoing sync for low-RPO workloads, bulk transfer for the rest), stand the workload up in the cloud, and test it against real scenarios before any user touches it. Then cut over — the checklist below is the part people wing and regret.
Phase 5 — Optimize
This is where the money is. Lift-and-shift instances are almost always over-provisioned; right-size them after two to four weeks of real usage data. Buy reserved instances or savings plans for steady workloads (routinely 30–60% off compute). Kill orphaned snapshots and unattached volumes. Watch data egress. For the mechanics of this phase, see our cloud cost optimization and FinOps guide.
The cutover checklist (keep your rollback open)
Cutover is the moment production traffic moves to the cloud. The discipline that separates a clean cutover from a war room is a single rule: stay reversible until the smoke tests pass.
Run the cutover in this order:
- Freeze / final sync. Do a last incremental data sync so the cloud copy matches source within your RPO.
- Switch traffic. Change DNS or the load-balancer target to point at the cloud. Use a low TTL set days in advance so the change propagates fast.
- Smoke test. Verify the critical paths — login, checkout, a real transaction — not just "the homepage loads."
- Go / no-go. Passing tests → keep going and plan to decommission the source. Failing tests → roll DNS back to the still-running source, within your RTO, and debug offline. Never debug live with users on a broken cutover.
- Hold the source. Keep the old environment running (read-only if needed) until you're confident, then decommission. Deleting it the same night removes your rollback.
For a structured way to confirm each migrated workload is actually healthy, see our cloud migration validation workflow.
Common ways migrations go wrong
- Untagged workloads. Anything without a 6 R's label is an undecided workload that stalls the whole wave.
- Skipping dependency mapping. The hidden dependency you didn't map is the one that takes production down at cutover.
- Refactoring before migrating. Elegant in theory, a year-long stall in practice. Rehost, then refactor what earns it.
- No RTO/RPO. Without them you can't size the cutover window or justify a rollback plan — you're guessing.
- Lift-and-shift and forget. The savings come in Phase 5. Migrating without optimizing means paying cloud prices for on-prem inefficiency.
- Deleting the source too early. Your old environment is your rollback. Keep it until you're sure.
Next steps
Start with discovery, not procurement. Inventory your estate, tag every workload with a strategy, and define RTO/RPO before you provision anything. If you're new to the platform side, our cloud computing beginners guide covers the fundamentals, and the file-server cost-optimization case study shows how these phases play out on a real migration. Once you're running in the cloud, an infrastructure audit turns Phase 5 into recurring savings rather than a one-time cleanup.