AWS migration strategies are a structured set of seven approaches (the 7 R's of migration) that an enterprise uses to move workloads from on-premises data centres to the AWS Cloud: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, and Refactor. Alongside these technical AWS migration strategies, the AWS Cloud Adoption Framework (AWS CAF) provides six organisational perspectives — Business, People, Governance, Platform, Security, and Operations — that align stakeholders around a successful migration to AWS.
If you are preparing for AWS CLF-C02 task statement 1.3, expect scenario questions that describe a workload and ask you to choose the correct AWS migration strategy among the 7 R's, plus questions that match organisational pain points to the right AWS CAF perspective.
What Are AWS Migration Strategies?
AWS migration strategies (often called the 7 R's of migration, or historically the 6 R's before Relocate was added) are AWS's canonical playbook for every workload you consider moving to AWS. Each of the 7 R's of migration represents a different trade-off between speed, cost, cloud-native benefit, and engineering effort. The exam wants you to recognise which AWS migration strategy fits a given business narrative.
In CLF-C02, the AWS migration strategies topic combines two complementary bodies of knowledge:
- The technical AWS migration strategies — the 7 R's — which describe what you do with each individual application during your migration to AWS.
- The AWS Cloud Adoption Framework (AWS CAF) — which describes how your organisation transforms people, process, and governance to sustain AWS migration strategies at scale.
Both layers are tested. Candidates who memorise only the 7 R's of migration often lose points on AWS CAF perspective questions, and vice versa.
The 7 R's of migration are AWS's canonical AWS migration strategies: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, Refactor. Each R represents a distinct approach to moving (or not moving) a workload to AWS during a migration to AWS. Memorising all seven names and their definitions is the single highest-leverage activity for this CLF-C02 topic. Reference: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
Why Migration to AWS Matters for CLF-C02
Migration to AWS is a Domain 1 topic (weight 24%), but within Domain 1 it is the fastest-rising sub-topic — community signal shows a +15% year-over-year mention increase, driven by CLF-C02 explicitly adding AWS CAF coverage that CLF-C01 did not emphasise. Expect 5–10 questions in your 65-question exam touching AWS migration strategies or AWS CAF perspectives.
Analogy 2 — AWS CAF as a Construction Site Command Centre
AWS Cloud Adoption Framework 的六個 perspectives 就像一個大型工地（construction site）的六個指揮部門：
- Business perspective：業主方（出錢、決定方向）— 業務部門與投資人。
- People perspective：工人組織與訓練 — HR 把員工重新培訓成雲端人才。
- Governance perspective：工地安全規章與預算管控 — IT governance、portfolio management。
- Platform perspective：工地鷹架與基礎建設 — 雲端架構師搭建 landing zone。
- Security perspective：工地門禁卡（access card）與安全組長 — resilience、compliance、identity。
- Operations perspective：工地日常運作、每日朝會 — monitoring、incident response、SLA。
工地要蓋得成功，六個部門缺一不可。AWS CAF 的價值就在於告訴你 migration to AWS 不只是技術問題，而是全組織的轉型工程。
Core Operating Principles — The 7 R's of Migration in Detail
Every one of the 7 R's of migration represents a distinct AWS migration strategy. The CLF-C02 exam tests your ability to match a business scenario to the correct R. Study each H3 below carefully.
Retire
Definition: Decommission applications that are no longer needed. No migration to AWS happens — the workload simply goes away.
When to use: During the assessment phase of migration to AWS, you typically find that 10–20% of applications in the portfolio are unused, duplicate, or legacy systems with zero business value. Retiring them saves licence fees, reduces attack surface, and shrinks the migration to AWS scope.
Concrete example: A company discovers three separate internal wiki systems (Confluence, MediaWiki, and a custom PHP site) all containing overlapping content. Two are retired; only Confluence migrates to AWS. This is pure Retire — no AWS migration strategies needed, just a shutdown.
Retain (Revisit)
Definition: Keep the application running on-premises for now. Often called Retain or Revisit — you defer the decision to migrate to AWS until conditions change.
When to use: You retain a workload when regulatory constraints, licensing contracts, dependency lock-in, or business criticality make immediate migration to AWS too risky. Retain is not the same as "never migrate" — it is "not yet."
Concrete example: A healthcare provider has a legacy on-premises claims-processing system bound by a 3-year vendor support contract. They retain the system until the contract ends, then revisit the AWS migration strategies decision. Retain explicitly keeps the workload out of the current migration to AWS wave.
Relocate (Hypervisor-Level Lift)
Definition: Move the workload from an on-premises hypervisor (typically VMware) into AWS with zero changes — using VMware Cloud on AWS or similar. No operating system change, no IP change, no application change.
When to use: Relocate is the fastest AWS migration strategy when the organisation already runs VMware at scale and wants to decommission physical data centres quickly without re-IP-ing or retraining operations teams. It is a relatively new addition to the 7 R's of migration (added after the original 6 R's).
Concrete example: A retailer runs 500 VMware virtual machines in two data centres. They use VMware Cloud on AWS to Relocate all 500 VMs to AWS infrastructure in a weekend cutover. Applications continue running unchanged. This illustrates why Relocate is distinct from Rehost — no agent, no new AMI, just hypervisor portability.
Rehost (Lift-and-Shift)
Definition: Move the application as-is to AWS compute (typically EC2) with no code changes. This is the true "lift-and-shift migration" approach, and it is the single most-tested of the AWS migration strategies on CLF-C02.
When to use: Rehost is ideal for rapid, large-scale migration to AWS when the priority is speed and data-centre exit. You accept that you will not immediately benefit from managed services, but you unlock cloud benefits later through Replatform or Refactor passes. AWS provides AWS Application Migration Service (MGN) to automate Rehost.
Concrete example: A financial services company lifts 2,000 Windows and Linux servers from on-premises VMware onto EC2 instances using AWS Application Migration Service, completing the migration to AWS in 9 months. They do not yet touch the applications — that comes in a later wave.
AWS migration strategies exam cue: If a CLF-C02 scenario says "no code changes," "fastest," "minimal refactoring," or "move as-is to EC2," the answer is almost always Rehost. Rehost is the dominant AWS migration strategy for enterprises exiting physical data centres on a deadline. Reference: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/rehost.html
Replatform (Lift-Tinker-and-Shift)
Definition: Move the workload to AWS and make targeted cloud optimisations without changing the core architecture. Often called "lift-tinker-and-shift." Replatform balances speed with modest AWS cloud-native benefit.
When to use: Replatform works when you want some managed-service leverage without a full rewrite. Typical Replatform moves include swapping self-managed databases for Amazon RDS or Aurora, swapping self-managed web servers for Elastic Beanstalk, or moving session state to ElastiCache.
Concrete example: A SaaS company Rehosts its application tier to EC2 but simultaneously Replatforms its PostgreSQL database from a self-managed on-premises deployment to Amazon RDS for PostgreSQL. The application connection string changes but the SQL does not. They gain managed backups, automatic patching, and Multi-AZ failover — clear migration to AWS wins without a rewrite.
Repurchase (Drop-and-Shop)
Definition: Abandon the existing application and replace it with a different product — typically a SaaS offering. Often called "drop-and-shop."
When to use: Repurchase fits commodity business functions (CRM, ERP, HR, email, collaboration) where a mature SaaS market already exists. Instead of a migration to AWS that hosts your old software, you repurchase a subscription.
Concrete example: A mid-market company retires its on-premises Siebel CRM and Repurchases Salesforce as a SaaS replacement. No AWS migration strategies for the CRM workload are required beyond user provisioning. Similarly, a company may Repurchase Microsoft Exchange for Microsoft 365, or an on-premises HRIS for Workday.
Refactor / Re-architect
Definition: Redesign the application from scratch using cloud-native patterns — microservices, serverless, managed databases, event-driven architectures. The highest-effort but highest-benefit of the AWS migration strategies.
When to use: Refactor when the existing architecture cannot deliver the scalability, feature velocity, or cost profile the business needs, and when the application is strategic enough to justify a rebuild. Refactor is often a second-pass AWS migration strategy after an initial Rehost gets you off on-premises.
Concrete example: A streaming company Refactors its monolithic Java content-ingestion pipeline into AWS Lambda functions triggered by Amazon S3 events, with metadata in Amazon DynamoDB and orchestration via AWS Step Functions. Throughput scales 10x, costs drop 40%, and release frequency goes from monthly to daily. This is the canonical cloud-native end-state for AWS migration strategies.
The 7 R's of migration — memorise this ordering and definition in one line each:
- Retire — turn off (decommission).
- Retain — keep on-premises for now (defer).
- Relocate — hypervisor move (VMware Cloud on AWS).
- Rehost — lift-and-shift (no code changes, typically onto EC2).
- Replatform — lift-tinker-and-shift (targeted cloud optimisations, e.g., RDS).
- Repurchase — drop-and-shop (replace with SaaS, e.g., Salesforce).
- Refactor / Re-architect — redesign cloud-native (Lambda, DynamoDB, microservices).
Primary Use Cases — Matching Scenarios to AWS Migration Strategies
A core CLF-C02 skill is mapping a described business situation to the right AWS migration strategy. Here are the scenario-matching patterns that recur in exam prep communities.
"We need to exit our data centre in 12 months"
Speed dominates every other consideration. Answer: Rehost (mass lift-and-shift). Use AWS Application Migration Service. A secondary consideration might be Relocate if the estate is VMware-heavy.
"We want to reduce database operational burden"
Managed service leverage. Answer: Replatform — migrate to AWS RDS, Aurora, or DynamoDB. Pair with AWS Database Migration Service (DMS) for the actual data pipeline.
"Our CRM is bespoke and painful to maintain"
Commodity function with mature SaaS alternatives. Answer: Repurchase — move to Salesforce, HubSpot, or similar.
"We want to fully leverage cloud-native features"
Strategic investment. Answer: Refactor — redesign into microservices, serverless, or containers.
"Regulatory constraints prevent movement until 2027"
Policy blocker. Answer: Retain — defer the migration to AWS decision.
"This system has not been logged into in 18 months"
Dead weight. Answer: Retire — decommission and remove from the migration to AWS scope.
AWS Cloud Adoption Framework (AWS CAF) — The 6 Perspectives
The AWS Cloud Adoption Framework (AWS CAF) is AWS's organisational playbook for sustaining AWS migration strategies at enterprise scale. AWS CAF organises cloud transformation into six perspectives, each led by different stakeholders. CLF-C02 candidates must match each perspective to its typical concerns.
The AWS Cloud Adoption Framework is AWS's guidance for organisational cloud transformation. AWS CAF is built on six perspectives — Business, People, Governance, Platform, Security, Operations — each grouping a set of capabilities that stakeholders improve during their migration to AWS. AWS CAF complements the AWS migration strategies (7 R's) by addressing the people-and-process dimensions, not just the technical workload moves. Reference: https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/welcome.html
Business Perspective
Owner: CEO, CFO, COO, CIO, and line-of-business leaders.
Concerns: Aligning the migration to AWS with business outcomes. Capabilities include strategy management, portfolio management, innovation management, product management, strategic partnership, data monetisation, and business insights.
Exam cue: "We need to align IT spending to revenue-generating initiatives" → Business perspective.
People Perspective
Owner: CHRO, CIO, cloud centre of excellence (CCoE) leads.
Concerns: Closing the cloud skills gap. Capabilities include culture evolution, transformational leadership, cloud fluency, workforce transformation, change management, organisation design, and talent management.
Exam cue: "We need to train our staff on cloud skills" or "We need to hire cloud engineers" → People perspective. This is one of the most consistently tested AWS CAF perspective mappings.
Governance Perspective
Owner: CIO, CTO, CFO, CDO (data officer), CRO (risk officer).
Concerns: Managing cloud initiatives to maximise benefits and minimise risk. Capabilities include programme and project management, benefits management, risk management, cloud financial management, application portfolio management, and data governance.
Exam cue: "We need to control cloud spend and risk across projects" → Governance perspective.
Platform Perspective
Owner: CTO, technology leaders, cloud architects, engineering leads.
Concerns: Building the enterprise cloud platform — landing zones, shared services, CI/CD pipelines. Capabilities include platform architecture, data architecture, platform engineering, data engineering, provisioning and orchestration, modern application development, and CI/CD.
Exam cue: "We need to build our AWS landing zone and CI/CD" → Platform perspective.
Security Perspective
Owner: CISO, CCO (compliance), internal audit.
Concerns: Achieving confidentiality, integrity, availability, privacy, and resilience. Capabilities include security governance, security assurance, identity and access management, threat detection, vulnerability management, infrastructure protection, data protection, application security, and incident response.
Exam cue: "We need to demonstrate compliance with HIPAA and SOC 2" → Security perspective.
Operations Perspective
Owner: CIO, COO, technology leaders, SRE/platform teams.
Concerns: Running and evolving cloud services to meet business needs. Capabilities include observability, event management (AIOps), incident and problem management, change and release management, performance and capacity management, configuration management, patch management, availability and continuity management, and application management.
Exam cue: "We need 24/7 monitoring and incident response for our AWS workloads" → Operations perspective.
AWS CAF mnemonic: Remember the 6 AWS CAF perspectives as B-P-G-P-S-O — "Big People Govern Platforms Securely Operating." Match each perspective to a typical C-suite role: Business → CEO/CFO, People → CHRO, Governance → CIO/CRO, Platform → CTO, Security → CISO, Operations → COO/SRE. The CLF-C02 exam almost always phrases AWS CAF questions in terms of "who cares about this concern?" Reference: https://aws.amazon.com/cloud-adoption-framework/
AWS CAF Benefits — Why CAF Matters During Migration to AWS
AWS highlights four primary benefits from applying AWS CAF to migration to AWS:
- Reduced business risk — proactively identifying and mitigating risks across all six perspectives reduces the probability of migration failure.
- Improved ESG performance — AWS CAF aligns sustainability considerations with the Sustainability pillar of the Well-Architected Framework, enabling environmentally responsible migration to AWS.
- Increased revenue — cloud-enabled agility creates new products, channels, and customer experiences that drive top-line growth.
- Increased operational efficiency — automation, managed services, and modern operations practices reduce unit cost and accelerate delivery.
These four AWS CAF benefits are an occasional CLF-C02 question pattern — "which of the following is a benefit of AWS CAF?"
Migration Support Tools — The AWS Migration Toolkit
AWS offers a toolbox of services that accelerate AWS migration strategies across all 7 R's of migration. For CLF-C02 you need awareness-level familiarity with each.
AWS Migration Hub
A single console to plan, track, and report on an enterprise migration to AWS across multiple AWS regions and migration tools. Migration Hub aggregates discovery data, assessment results, and migration status.
AWS Application Migration Service (MGN)
The primary Rehost engine. MGN replicates source servers block-by-block to AWS and performs a near-zero-downtime cutover onto EC2. It is the preferred tool for lift-and-shift migration to AWS at scale.
AWS Application Discovery Service
Discovers on-premises workloads, captures server specs, performance data, and dependencies. Output feeds AWS migration strategies decision-making — helping you decide which R to apply to each workload.
AWS Database Migration Service (DMS)
Migrates databases to AWS with minimal downtime. AWS DMS supports homogeneous migrations (Oracle → Oracle on RDS) and heterogeneous migrations (Oracle → Aurora PostgreSQL). DMS is essential for Replatform and Refactor AWS migration strategies that change the database tier.
AWS Schema Conversion Tool (SCT)
Paired with AWS DMS for heterogeneous database migration to AWS. AWS SCT converts database schemas, stored procedures, and SQL dialect differences between source and target engines. Use SCT before DMS when moving Oracle → PostgreSQL, SQL Server → Aurora, etc.
AWS DataSync
Online data transfer service for moving file data (NFS, SMB, HDFS) between on-premises storage and AWS storage services (S3, EFS, FSx).
Database migration to AWS combination to memorise: AWS SCT (Schema Conversion Tool) converts the schema, then AWS DMS (Database Migration Service) moves the data. SCT handles the structure changes that a heterogeneous Replatform requires; DMS handles the continuous data replication and cutover. This pairing appears repeatedly in CLF-C02 migration to AWS scenario questions. Reference: https://aws.amazon.com/dms/schema-conversion-tool/
AWS Snow Family — Physical Data Migration to AWS
When networks cannot handle the data volume for migration to AWS (too much data, too little bandwidth, too remote a location), AWS Snow Family devices physically ship data into AWS.
AWS Snowcone
- Capacity: up to 8 TB HDD / 14 TB SSD usable storage.
- Form factor: smallest, ruggedised, portable (4.5 lb).
- Use case: edge compute and light data migration to AWS from tactical, mobile, or field environments — e.g., a drone or vehicle collecting sensor data.
AWS Snowball (Snowball Edge)
- Capacity: Snowball Edge Storage Optimized offers 80 TB of usable HDD storage (plus 1 TB SSD), and the Compute Optimized variant offers 42 TB HDD with more vCPU/RAM for edge workloads.
- Form factor: briefcase-sized, ruggedised.
- Use case: mid-scale data migration to AWS — petabyte-order batch transfers. Common for branch-office backups, field data collection, and disconnected environments.
AWS Snowmobile (legacy)
- Capacity: up to 100 PB per unit.
- Form factor: a 45-foot shipping container pulled by a semi-truck.
- Use case: exabyte-scale data-centre migration to AWS. Historically used for massive video archives, genomics, and seismic data. Note: as of 2024 AWS has retired new Snowmobile orders for most regions, but it remains in the CLF-C02 exam guide as a concept you must recognise.
AWS Snow Family sizing shortcut: Snowcone ≈ terabytes (portable, edge). Snowball ≈ tens of terabytes to petabytes (standard migration to AWS). Snowmobile ≈ petabytes to exabytes (a truck). If a CLF-C02 migration to AWS scenario mentions "100 PB" or "semi-truck" or "exabyte," pick Snowmobile. If it mentions "ruggedised, portable, edge," pick Snowcone. For everything in between, pick Snowball. Reference: https://aws.amazon.com/snow/
Key Numbers and Limits You Must Memorise
- 7 R's of migration: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, Refactor (memorise order and definition).
- 6 AWS CAF perspectives: Business, People, Governance, Platform, Security, Operations.
- 4 AWS CAF benefit categories: reduced risk, ESG, revenue, operational efficiency.
- AWS Snowcone: up to 8 TB HDD / 14 TB SSD.
- AWS Snowball Edge Storage Optimized: 80 TB usable HDD.
- AWS Snowmobile: up to 100 PB, 45-foot container.
- AWS DMS + SCT: DMS moves data; SCT converts schemas for heterogeneous migration to AWS.
Common Traps — Where CLF-C02 Candidates Lose Points
Community signal (from CLF-C02 exam prep forums and blog post-mortems) identifies three recurring AWS migration strategies traps. Study these carefully.
Trap 1 — Rehost vs Replatform vs Refactor Confusion
The classic CLF-C02 trap. Many candidates treat Rehost and Replatform as synonyms for "lift-and-shift." They are not.
- Rehost = no code changes. Pure copy of the VM/application onto EC2.
- Replatform = targeted optimisations, same architecture. Typical example: swap self-managed DB for Amazon RDS.
- Refactor = redesign from scratch. Typical example: rewrite as Lambda + DynamoDB.
Trap 2 — Retire vs Retain Confusion
- Retire = turn off. The application is permanently decommissioned.
- Retain = defer. The application stays on-premises and will be revisited later.
Candidates frequently answer "Retire" when the scenario clearly describes a regulatory-locked system that must stay on-premises for now. That scenario is Retain.
Trap 3 — AWS CAF vs Well-Architected Framework Confusion
- AWS CAF = organisational transformation (people, governance, business outcomes). Applied before and during migration to AWS.
- Well-Architected Framework = workload architecture review (6 pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability). Applied to a specific workload already on AWS.
A scenario about "training staff on cloud skills" is AWS CAF (People perspective), not Well-Architected. A scenario about "improving a workload's reliability through multi-AZ" is Well-Architected (Reliability pillar), not AWS CAF.
AWS migration strategies top exam trap: A CLF-C02 scenario reads: "A company wants to move its database to AWS with minimal effort and take advantage of managed backups and patching. The application code will not change." Many candidates pick Rehost because "minimal effort" suggests lift-and-shift. Wrong — the correct answer is Replatform, because moving to a managed service (Amazon RDS) with managed backups and patching is the textbook Replatform move. Rehost keeps you on self-managed EC2 with no managed-service benefits. Always re-read the scenario for managed-service keywords — they signal Replatform, not Rehost. Reference: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/replatform.html
Disambiguation — Rehost vs Replatform vs Refactor Side-by-Side
| Dimension | Rehost | Replatform | Refactor |
|---|---|---|---|
| Code changes | None | Minor (config, connection strings) | Major (redesign) |
| Architecture | Unchanged | Core unchanged, components swapped | Completely new |
| Managed services | No | Some (e.g., RDS) | Heavy (Lambda, DynamoDB, etc.) |
| Speed | Fastest | Moderate | Slowest |
| Cloud-native benefit | Low | Medium | Highest |
| Typical example | EC2 via MGN | Self-managed DB → RDS | Monolith → microservices |
| CLF-C02 keyword cue | "as-is", "no code changes", "fastest" | "managed database", "some optimisation" | "cloud-native", "serverless", "microservices" |
Disambiguation — AWS Migration Strategies vs AWS CAF vs Well-Architected Framework
| Dimension | AWS Migration Strategies (7 R's) | AWS CAF | Well-Architected Framework |
|---|---|---|---|
| Level | Per-workload technical approach | Organisation-wide transformation | Workload architectural review |
| Unit | One application at a time | Six perspectives across the enterprise | Six pillars per workload |
| Timing | During migration to AWS | Before + during migration to AWS | After workload is on AWS |
| Output | A decision (which R) per workload | A transformation plan per perspective | An improvement plan per pillar |
| Example question | "Which R moves this DB to RDS?" | "Which CAF perspective owns staff training?" | "Which pillar covers automatic recovery?" |
Migration Benefits — Why Move to AWS at All
Beyond the technical choice of AWS migration strategies, CLF-C02 candidates must articulate why enterprises pursue migration to AWS. Four benefit categories dominate the exam.
Reduced Total Cost of Ownership (TCO)
Migration to AWS converts data-centre CapEx (hardware, real estate, power, cooling) into cloud OpEx (pay-as-you-go consumption). Rightsizing, Reserved Instances, Savings Plans, and automatic scaling typically reduce TCO by 20–40% versus equivalent on-premises.
Agility and Speed to Market
Provisioning new AWS environments takes minutes versus weeks for physical hardware procurement. Developers can experiment cheaply, kill failed experiments, and iterate faster. AWS migration strategies that include Refactor amplify agility further via serverless and CI/CD.
Global Reach
AWS operates 30+ regions worldwide. A Replatform or Refactor migration to AWS can deploy to multiple regions in hours, providing low-latency service to global customers and compliance with data-residency regulations.
Focus on Core Business
Managed services (RDS, Lambda, S3, DynamoDB) remove undifferentiated heavy lifting — patching OS, managing storage arrays, tuning database engines. Engineers spend time on business features, not infrastructure.
FAQ — AWS Migration Strategies Top Questions
Q1: What is the difference between the 6 R's and the 7 R's of migration?
Originally AWS published 6 R's of migration (Retire, Retain, Rehost, Replatform, Repurchase, Refactor). AWS later added Relocate to acknowledge VMware Cloud on AWS and similar hypervisor-level moves, forming the modern 7 R's of migration. CLF-C02 exam materials reference both, but the 7 R's is the current canonical list for AWS migration strategies.
Q2: Is AWS CAF the same as the AWS Well-Architected Framework?
No. AWS CAF addresses organisational transformation through six perspectives (Business, People, Governance, Platform, Security, Operations) and is applied before and during migration to AWS. The Well-Architected Framework addresses workload-level architecture through six pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability) and is applied to workloads already on AWS. A CLF-C02 question distinguishing these is a common trap.
Q3: Which AWS migration strategy gives the biggest cloud benefit?
Refactor / Re-architect gives the biggest cloud-native benefit — serverless scale, event-driven cost, microservices velocity. However, Refactor also has the highest effort and risk. Most enterprise migration to AWS programmes combine Rehost for speed (to exit data centres fast) with Replatform or Refactor for selected strategic workloads over a longer horizon.
Q4: Which AWS service do I use to physically ship petabytes to AWS?
Use the AWS Snow Family. For terabyte-scale ruggedised edge cases, use AWS Snowcone (up to 14 TB SSD). For standard petabyte migration to AWS, use AWS Snowball Edge (80 TB usable on the Storage Optimized model). For exabyte-scale data-centre evacuation, use AWS Snowmobile (100 PB per 45-foot container). This is one of the most common migration to AWS scenario patterns in CLF-C02.
Q5: Which AWS CAF perspective owns staff training and cloud skills?
The People perspective. It covers culture evolution, transformational leadership, cloud fluency, workforce transformation, change management, organisation design, and talent management. If a CLF-C02 scenario mentions training, hiring, culture, or change management, the AWS CAF perspective is almost always People. Do not confuse it with Operations (day-to-day running) or Governance (risk and portfolio management).
Q6: When is Repurchase the correct AWS migration strategy?
Repurchase (drop-and-shop) is correct when a mature SaaS alternative exists for a commodity business function — CRM (Salesforce), ERP (Workday, NetSuite), email/collaboration (Microsoft 365, Google Workspace), HRIS (Workday). Repurchase removes the workload from your migration to AWS scope entirely — you no longer host it on AWS compute; you consume a third-party SaaS.
Q7: What is the relationship between AWS DMS and AWS SCT?
AWS SCT (Schema Conversion Tool) converts database schemas between heterogeneous engines (e.g., Oracle → PostgreSQL). AWS DMS (Database Migration Service) migrates the actual data, supporting continuous replication with minimal downtime. For a heterogeneous Replatform migration to AWS, you use SCT first, then DMS. For a homogeneous Replatform (Oracle → Oracle on RDS), you use DMS alone.
Further Reading and Official Sources
- AWS Cloud Adoption Framework whitepaper (v3): https://docs.aws.amazon.com/pdfs/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf
- AWS Prescriptive Guidance — Migration Strategies (7 R's): https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
- AWS Snow Family: https://aws.amazon.com/snow/
- AWS Database Migration Service (DMS): https://aws.amazon.com/dms/
- AWS Application Migration Service (MGN): https://aws.amazon.com/application-migration-service/
- AWS Migration Hub: https://aws.amazon.com/migration-hub/
- AWS Certified Cloud Practitioner (CLF-C02) Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf
Summary — AWS Migration Strategies Exam Cheat Sheet
- Memorise the 7 R's of migration: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, Refactor — and one-line definitions.
- Memorise the 6 AWS CAF perspectives: Business, People, Governance, Platform, Security, Operations — and the typical C-suite owner of each.
- Know the AWS Snow Family sizing ladder: Snowcone (TB) → Snowball Edge (80 TB) → Snowmobile (100 PB).
- Know that AWS DMS + AWS SCT is the standard heterogeneous database migration to AWS combo.
- Beware the Rehost vs Replatform trap: managed-service keywords (RDS, managed patching) signal Replatform, not Rehost.
- Beware the Retire vs Retain trap: Retire = decommission; Retain = defer.
- Beware the AWS CAF vs Well-Architected trap: AWS CAF = organisation and migration to AWS; Well-Architected = workload already on AWS.
Mastering AWS migration strategies and the AWS Cloud Adoption Framework is one of the highest-ROI topics for CLF-C02 task statement 1.3 — and it scales into every higher-level AWS certification you pursue afterwards. Keep returning to the 7 R's of migration and the 6 AWS CAF perspectives until the scenario-matching becomes second nature.