What's changed: Deepened SAP-C02 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.1Choosing a Migration Strategy (The 7 Rs)
Understand migration approaches—the 7 Rs (rehost/replatform/refactor/repurchase/retire/retain/relocate) and assessment via Migration Hub/Application Discovery Service. Pick the best path per workload.
Large migrations start by assessing the portfolio, then assigning each app a strategy from the 7 Rs. Effort and value trade off.
4.1.1The 7 Rs
- Rehost (lift & shift): move to EC2 unchanged; fastest, least effort (automated by AWS MGN).
- Replatform: minor optimization (e.g., self-managed DB → managed RDS).
- Refactor: rebuild cloud-native (serverless/microservices); high effort, high value.
- Repurchase: drop self-hosting for SaaS. Retire: decommission the unneeded. Retain: keep for now. Relocate: move as-is.
Common on SAP-C02: fast, no change = rehost (lift & shift, MGN), small optimization like managed DB = replatform, cloud-native rebuild = refactor, go SaaS = repurchase, decommission = retire / keep = retain; assessment = Discovery Service + Migration Hub. Rehost for speed/low risk, refactor for long-term value.
Application Discovery Service collects dependencies/utilization; Migration Hub tracks migration progress centrally. Visualize first, then assign strategies.
SAP-C02 centers on choosing the right R from constraints (deadline, budget, skills, risk tolerance). Rehost is fastest and lowest-risk since nothing changes, ideal for large migrations under a data-center-exit deadline—but it captures few cloud benefits (managed services, elasticity). Replatform is "optimize without over-touching," classically moving a self-managed DB to RDS/Aurora to offload patching, backups, and HA. Refactor is the most effort but maximizes long-term agility, scale, and cost via serverless/microservices—best reserved for high-business-value cores. Repurchase drops self-hosting for SaaS (e.g., in-house mail → managed SaaS). Retire removes unneeded assets so there is less to migrate; Retain means "do not move yet" due to regulation, dependencies, or imminent decommission; Relocate moves at the hypervisor level as-is, e.g., via VMware Cloud on AWS. In the assessment phase, feed Application Discovery Service results (agent/agentless collection of CPU, memory, and network dependencies) into Migration Hub to track per-application progress and status centrally.
| Situation | Chosen R | Why |
|---|---|---|
| DC-exit deadline, minimal change | Rehost | Fastest, lowest risk (automate with MGN) |
| Cut ops, no big rewrite | Replatform | Small optimizations like managed DB |
| Long-term agility for core | Refactor | Max value via serverless/microservices |
| Drop self-hosting commodity | Repurchase | Switch to SaaS |
Scenario: Six months until a data-center contract ends; hundreds of servers must move. Most are mature line-of-business apps with little rewrite budget, but some self-managed MySQL should shed ops burden. → Move the bulk via rehost (MGN) to hit the deadline reliably, and replatform just the MySQL to RDS. First map dependencies with Discovery Service and track wave-by-wave progress in Migration Hub.
FAQ: Relocate vs Rehost? Rehost moves individual servers to EC2 (lift & shift), while Relocate moves an entire virtualization layer as-is via, e.g., VMware Cloud on AWS, without changing OS or apps. It is the least-change, fastest option but captures the fewest cloud-native benefits.
Exam trap: Choosing Refactor when the goal is "migrate in the shortest time" is wrong—Refactor takes the most effort and time. For short deadlines and low risk, Rehost is correct; conversely, when the goal is "maximize long-term agility/cost-efficiency," Refactor is correct. Weigh the deadline trade-off.
4.1.2Section summary
- 7 Rs = rehost/replatform/refactor/repurchase/retire/retain/relocate
- Assessment = Application Discovery Service + Migration Hub
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. With a tight deadline, you want to move existing servers to EC2 quickly with no changes first. Which strategy?
Q2. You want to move a self-managed MySQL to Amazon RDS managed DB with almost no app changes to cut ops burden. Which strategy?
Q3. Before a large migration, you want to collect on-prem dependencies/utilization and track migration progress centrally. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.