6.1 The 7 Rs of Cloud Migration

The 7 Migration Strategies

Quick Answer: The 7 Rs order migration strategies from simplest to most transformative: Retire (decommission), Retain (keep on-premises), Relocate (move VMware to VMware Cloud on AWS), Rehost (lift-and-shift to EC2), Replatform (move with minor tuning), Repurchase (switch to SaaS), and Refactor (re-architect cloud-native). On the SAA-C03 exam, the keywords "as-is," "fastest," and "minimal changes" almost always point to Rehost.

A migration assessment ranks each application against effort versus benefit. The exam frequently gives a scenario sentence and expects you to map it to exactly one R, so memorize the trigger phrase for each row below.

Mapping scenarios to a strategy

• "Migrate 500 servers as fast as possible" → Rehost (MGN).
• "Reduce database admin work without changing the app" → Replatform to RDS/Aurora.
• "We want event-driven serverless" → Refactor.
• "This app has no remaining users" → Retire.
• "Too entangled to move this quarter" → Retain.

Common trap: candidates pick Refactor because it sounds best. Refactor maximizes long-term benefit but is the slowest and costliest; when the scenario stresses speed, deadline, or "no code changes," Rehost wins.

AWS Migration Services and Tooling

AWS Migration Hub is the single pane of glass that tracks application status across the underlying tools — it does not move data itself. The execution services are summarized below.

Application Migration Service (MGN) — the rehost engine

MGN installs a lightweight agent on each source server and performs continuous, block-level replication into a low-cost staging area in your AWS account. Because replication is continuous, the final cutover window is minutes, not hours. You can launch test instances from the replicated data without touching production, validate, then perform a non-disruptive cutover. MGN supports physical, virtual (VMware/Hyper-V), and other-cloud servers, all targeting EC2.

Database Migration Service (DMS) and Schema Conversion Tool (SCT)

DMS keeps the source database fully operational during migration and supports change data capture (CDC) for ongoing replication, enabling near-zero-downtime cutovers.

• Homogeneous (MySQL→RDS MySQL, Oracle→Oracle): same engine, DMS only — no schema conversion required.
• Heterogeneous (Oracle→Aurora PostgreSQL, SQL Server→MySQL): different engine, run SCT first to convert tables, views, and stored procedures, then DMS to move and replicate the data.

Worked example: Migrate a 2 TB Oracle database to Aurora PostgreSQL with under five minutes of downtime. Convert the schema with SCT, start a DMS task with full-load + CDC, let CDC catch the change backlog, then cut the application over to the Aurora endpoint.

How the strategies sequence in a real program

Large migrations rarely use a single R; an enterprise portfolio typically blends several. A practical sequence is: first Retire the dead weight so you never pay to move it, then Rehost the bulk of servers quickly with MGN to vacate the data center and stop the lease, and finally Refactor the few high-value applications where cloud-native rewrites pay off. This "move fast, optimize later" pattern is why the exam treats Rehost as the default mass-migration answer and Refactor as a targeted, post-migration investment rather than a day-one choice.

Trap to watch: AWS Migration Hub does not move anything. If a question asks which service transfers the workload, it is MGN, DMS, DataSync, or Snow — Migration Hub only aggregates status and discovery data across those tools. Likewise, Relocate is narrow: it specifically means moving a VMware vSphere environment to VMware Cloud on AWS without converting the VMs to native EC2, so reserve it for scenarios that explicitly mention VMware and the desire to keep existing vSphere operations.

When in doubt between Rehost and Replatform, decide on whether any change is made: zero changes is Rehost; swapping a self-managed component for a managed equivalent (a database to RDS, a runtime to Elastic Beanstalk) is Replatform.