AWS Cloud Adoption Framework & Migration Strategies: The 7 Rs, DMS, and Snowball

Organizations rarely move to AWS one server at a time with no plan. A cloud adoption strategy answers three questions at different altitudes. First, at the organizational level: is the business ready — do people have the skills, does governance allow it, is leadership aligned? AWS answers this with the AWS Cloud Adoption Framework (AWS CAF), which structures readiness across six perspectives and describes the business outcomes adoption should produce. Second, at the workload level: for each application, how should it move? That is the job of the migration strategies commonly called the 7 Rs. Third, at the data level: how do terabytes of files and live databases physically get to AWS? That is where database replication with AWS DMS and offline transfer with AWS Snowball come in.

CLF-C02 treats these three altitudes as one task statement. A question may describe a company assessing employee skills before migrating (CAF, People perspective), a company moving a virtual machine unchanged (a migration strategy — rehost), or a company with a huge dataset and a slow internet link (a transfer decision — Snowball). Your first move on any Task 1.3 question is to identify which altitude the scenario lives at: organizational readiness and outcomes point to the CAF, per-application decisions point to a specific R, and moving bytes points to a transfer service.

Keep the boundaries with neighboring topics clean: the general advantages of cloud computing (elasticity, pay-as-you-go, global reach) belong to Task 1.1, the Well-Architected Framework's design pillars belong to Task 1.2, and cost models belong to Task 1.4. Task 1.3 is specifically about getting to the cloud.

The AWS CAF is guidance that helps organizations plan and accelerate their cloud transformation. It organizes the work into six perspectives, each a set of capabilities owned by different stakeholders. Three perspectives focus on business capabilities and three on technical capabilities.

Business capability perspectives

• Business — ensures cloud investments accelerate digital transformation ambitions and deliver business outcomes. Stakeholders: CEOs, CFOs, business managers.
• People — treats adoption as a culture and workforce change: leadership, skills training, organizational design, and a growth mindset. Stakeholders: HR leaders, people managers.
• Governance — orchestrates the transformation while managing risk: program and portfolio management, benefits realization, risk management, cloud financial management, data governance.

Technical capability perspectives

• Platform — builds the scalable, enterprise-grade cloud environment itself: architecture, infrastructure and data engineering, modern application development. Stakeholders: CTOs, architects, engineers.
• Security — achieves confidentiality, integrity, and availability of data and workloads: identity and access management, threat detection, vulnerability management, data protection.
• Operations — ensures cloud services meet business needs day to day: observability, incident and event management, change and configuration management.

A dependable memory device: the six perspectives spell B-P-G / P-S-O — Business, People, Governance on the business side; Platform, Security, Operations on the technical side. When a question describes who needs to do what kind of work to become cloud-ready — retraining staff, defining risk controls, designing landing zones — it is asking you to name a CAF perspective.

Separate from its perspectives, the CAF describes the business outcomes a cloud transformation should deliver. The exam guide names four benefit categories, and CLF-C02 expects you to match each to a scenario:

• Reduced business risk — cloud adoption improves reliability, increases performance, and strengthens security posture, lowering the chance of outages, breaches, and compliance failures. Scenario cue: a company wants fewer service disruptions or a stronger security and compliance position.
• Improved environmental, social, and governance (ESG) performance — better transparency and insight into operations, plus a lower carbon footprint from running on shared, efficiently utilized AWS infrastructure instead of underused private data centers. Scenario cue: sustainability targets, corporate responsibility reporting, reducing energy consumption.
• Increased revenue — the cloud lets the business create new products, reach new markets and customers, and monetize offerings faster. Scenario cue: launching new digital products, expanding to new geographic markets, growing the customer base.
• Increased operational efficiency — lower operating costs, higher workforce productivity, and faster delivery of new features because teams stop managing undifferentiated infrastructure. Scenario cue: reducing time spent on maintenance, shipping faster, doing more with the same staff.

Notice these are outcomes, phrased as business results, while the perspectives are work areas, phrased as organizational functions. A question asking "which benefit of the AWS CAF does this describe?" wants one of these four categories — never "Security" or "Operations," which are perspectives. The exam counts on candidates blurring the two lists; the next section makes the distinction mechanical.

The single most common way CLF-C02 probes the CAF is by mixing perspective names and benefit names in one answer set. The test is simple once you internalize the grammar of each list. Perspectives are nouns describing organizational functions: Business, People, Governance, Platform, Security, Operations. Benefits are verb phrases describing improvement: reduced business risk, improved ESG performance, increased revenue, increased operational efficiency. If the option starts with a change word — reduced, improved, increased — it is a benefit category. If it is a single functional noun, it is a perspective.

Watch for near-collisions the exam exploits. "Security" (perspective — the work of protecting data and workloads) is not the same as "reduced business risk" (benefit — the outcome of that work, among other things). "Operations" (perspective — running cloud services day to day) is not "increased operational efficiency" (benefit — the business getting more output per dollar and per person). "Governance" (perspective — managing the transformation and its risks) is not "improved ESG performance," even though the G in ESG stands for governance.

For completeness at recognition depth: the CAF also describes a transformation journey through four iterative phases — Envision (identify transformation opportunities tied to business outcomes), Align (find capability gaps across the six perspectives), Launch (deliver pilot initiatives in production), and Scale (expand pilots to full value). CLF-C02 rarely goes deeper than recognizing these phase names, but knowing they exist prevents you from mistaking a phase name for a perspective or a benefit.

Once an organization commits to migrating, every application in its portfolio gets one of seven dispositions — the 7 Rs. Each strategy trades effort against cloud benefit: the further right you go on the modernization spectrum, the more work up front and the more cloud-native the result. At CLF-C02 depth you need to recognize each strategy from a one-line scenario.

Exam shortcuts: "no changes, move quickly" → rehost. "Minor change to use a managed service" → replatform. "Rewrite as microservices / serverless" → refactor. "Switch to SaaS" → repurchase. "VMware, keep operating the same way" → relocate. "Can't or shouldn't move yet" → retain. "Turn it off" → retire. Also note that retire and retain are the two strategies where nothing migrates — a favorite distractor pair.

The exam guide names two migration mechanisms explicitly: database replication and AWS Snowball. They solve different physics problems — one moves live, changing data over the network; the other moves bulk data past an inadequate network.

Database replication with AWS DMS

AWS Database Migration Service (AWS DMS) migrates databases to AWS while the source stays operational, using continuous replication: it copies the existing data, then streams ongoing changes so the target stays in sync until you cut over — minimizing downtime. DMS supports homogeneous migrations (same engine, such as on-premises MySQL to RDS for MySQL) and heterogeneous migrations (different engines, such as Oracle to Amazon Aurora PostgreSQL), where its schema conversion capability translates the database schema and code between engines (the standalone AWS Schema Conversion Tool, AWS SCT, serves the same purpose). When a scenario says "migrate a production database with minimal downtime," the answer is DMS.

Offline transfer with AWS Snowball

AWS Snowball (via Snowball Edge devices) is a physical, ruggedized appliance AWS ships to you. You load data locally, ship the device back, and AWS imports the data into Amazon S3. Data is encrypted on the device, and Snowball Edge variants also offer local storage and compute for edge locations with limited or no connectivity. Choose the transfer path with this decision list:

• Data volume vs. bandwidth — estimate how long the transfer would take over your actual usable link. When the network transfer time stretches from days into weeks or longer, a shipped device is usually faster and cheaper.
• Connectivity quality — remote sites, ships, or disconnected environments with weak or no links favor Snowball regardless of volume.
• Ongoing vs. one-time — continuous synchronization (like a live database or recurring file sync) needs an online method such as DMS or AWS DataSync; a one-time bulk seed of an archive favors Snowball.
• Network impact — if saturating the corporate link would disrupt business operations, offloading the bulk transfer to a device avoids the contention.

For online transfers at foundational depth, know that AWS DataSync accelerates moving file data over the network and that dedicated connectivity (AWS Direct Connect) can make large online transfers viable — but when the question emphasizes petabyte-scale data, limited bandwidth, or a hard deadline, Snowball is the intended answer.

AWS surrounds migrations with services, guidance, and people. CLF-C02 asks you to recognize what each resource is for, not to operate it.

• AWS Migration Hub — a single place to discover your existing servers, plan migrations, and track the progress of application migrations across multiple AWS tools and Partner solutions. Scenario cue: "central dashboard to track migration status."
• AWS Application Migration Service (MGN) — the primary rehost tool: it continuously replicates source servers (physical, virtual, or other clouds) and converts them to run natively on EC2 with minimal downtime. Scenario cue: "lift-and-shift servers to AWS with automated replication."
• AWS Database Migration Service (DMS) — database migration and continuous replication, covered above.
• AWS Prescriptive Guidance — a library of proven strategies, guides, and patterns from AWS experts and Partners that documents how to plan and execute migrations and modernization. Scenario cue: "documented best-practice strategies for planning a migration."
• AWS Partners (AWS Partner Network) — consulting and software partners, including those with migration competencies, who deliver hands-on migration expertise when the customer lacks in-house skills. Scenario cue: "needs external experts to execute the migration."
• AWS Professional Services and the Migration Acceleration Program (MAP) — AWS's own experts and a structured program (assess, mobilize, migrate and modernize) that provides methodology, tooling, and investment to accelerate large enterprise migrations.
• Migration Evaluator — builds a data-driven business case by analyzing your current on-premises footprint and projecting AWS costs. Scenario cue: "needs a business case before deciding to migrate."

The recognition pattern: track → Migration Hub; rehost servers → Application Migration Service; databases → DMS; documented strategies → Prescriptive Guidance; external expertise → AWS Partners; business case → Migration Evaluator.

Consider a regional insurance company planning its move to AWS. Leadership wants the migration to support two stated outcomes: fewer customer-facing outages and a public commitment to cut data-center energy use. The IT estate includes 300 virtual machines, a 4 TB Oracle claims database that must stay live through cutover, an 80 TB document archive at a branch office with a slow internet link, a self-hosted email system, and a legacy mainframe scheduling tool that a compliance review says cannot leave the premises for two more years. Two internal reporting apps duplicate each other.

Map it: the two stated outcomes are CAF benefit categories — reduced business risk (fewer outages) and improved ESG performance (energy reduction). Before execution, the company assesses staff skills and retrains its infrastructure team — work under the CAF People perspective — and defines cloud risk controls under Governance. Per workload: the 300 VMs move fastest by rehost using AWS Application Migration Service, tracked centrally in AWS Migration Hub. The Oracle database migrates with AWS DMS continuous replication — and if the team converts it to Aurora PostgreSQL, the schema conversion makes it a heterogeneous migration. The 80 TB archive on a weak link ships on an AWS Snowball device into S3. Email is repurchased as SaaS. The mainframe tool is retained; one duplicate reporting app is retired. Lacking migration experience, the company engages an AWS Partner and follows AWS Prescriptive Guidance playbooks.

Every Task 1.3 concept appears in one story. On the exam you will see the same elements one slice at a time — a single paragraph asking you to name the benefit, the perspective, the R, the transfer method, or the supporting resource. Practice reading a scenario and tagging which of those five things it is really asking for.