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, online transfer with AWS DataSync, and offline transfer — AWS Snowball in the exam guide, AWS Data Transfer Terminal or Partner services for new AWS customers today — 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 — online or physical). 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. Capabilities include strategy management, portfolio management (prioritizing cloud products and initiatives), innovation management, product management, and data monetization. Common stakeholders: the CEO, CFO, COO, CIO, and CTO.
• People — the bridge between technology and business: treats adoption as a culture and workforce change. Capabilities: culture evolution, transformational leadership, cloud fluency (skills training), workforce transformation, change acceleration, organization design, and organizational alignment. Common stakeholders: the CIO, COO, CTO, cloud director, and cross-functional leaders.
• Governance — orchestrates the transformation while maximizing benefits and minimizing risk. Capabilities: program and project management, benefits management, risk management, cloud financial management, application portfolio management, data governance, and data curation. Common stakeholders: the chief transformation officer, CIO, CTO, CFO, chief data officer, and chief risk officer.

Two Governance capabilities are easy to misfile. Risk management here means transformation-level business risk, not protecting data (that is Security). Program and project management and application portfolio management (keeping an accurate inventory of applications and managing them in line with the strategy) are Governance, while the Business perspective owns strategy and the portfolio of cloud products and initiatives.

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 — the business runs better, with three kinds of result: lower operating cost (paying for what is used instead of idle hardware), higher productivity (manual, repetitive work such as patching or provisioning is automated or handed to managed services, so the same staff deliver more), and an improved employee and customer experience (less toil for teams, faster and more reliable service for customers). Scenario cue: hours of manual work eliminated, fewer staff tied up in maintenance, lower running costs, shipping faster.

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.

There is a third CAF list that can appear in the same answer set: the four transformation domains — Technology, Process, Organization, and Product — which describe what gets transformed (for example, migrating and modernizing infrastructure is the Technology domain; rethinking business models is Product). The CAF links the three layers in a chain: the six perspectives are the foundational capabilities that make the transformation domains possible, and transforming those domains produces the four benefit categories. Like perspectives, domain names are single nouns — so if an option is a noun, check which list it belongs to: Technology, Process, Organization, Product are domains; Business, People, Governance, Platform, Security, Operations are perspectives; only the reduced/improved/increased phrases are benefits.

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 you move toward modernization, 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.

Rehost, replatform, or relocate?

These three all move an application without rewriting it, so they are the easiest to confuse. Rehost keeps the application and its server stack and runs it on EC2 instances you still manage. Replatform keeps the application code but swaps what it runs on for something AWS manages — a database engine onto Amazon RDS, or a web application onto the managed runtime of AWS Elastic Beanstalk, which runs the infrastructure underneath it for you. Relocate moves the whole hypervisor platform to a cloud version of itself, so the virtual machines are not converted at all and operations keep the same tools. Relocate only exists where such a cloud platform exists — cloud versions of VMware vSphere are available on AWS (VMware Cloud on AWS, Amazon EVS), but none exist for other hypervisors such as Microsoft Hyper-V, so Hyper-V VMs moved unchanged onto EC2 are a rehost.

Exam shortcuts: "no changes, move quickly" → rehost. "Minor change to use a managed service or runtime" → replatform. "Rewrite as microservices / serverless" → refactor. "Switch to SaaS" → repurchase. "VMware, keep the same platform and operations" → 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 problems — one moves live, changing database data over the network; the other moves bulk data when the network is too slow. Because AWS no longer offers Snow Family devices to new customers, you also need to know what AWS recommends instead.

Database replication with AWS DMS

AWS Database Migration Service (AWS DMS) migrates databases to AWS while the source stays operational. A DMS task runs one of three migration types:

• Full load — copies the existing data once. Suitable when the source can be paused for the copy.
• Full load and ongoing replication (change data capture, CDC) — copies the existing data, then keeps streaming every change so the target stays in sync until you cut over. This is the choice when a production database must stay live with minimal downtime.
• CDC only — replicates only changes, for when the existing data was loaded some other way.

A homogeneous migration keeps the same engine family (for example MySQL to Amazon Aurora MySQL, or MySQL to Amazon RDS for MySQL) and needs no schema conversion — DMS moves the data directly. A heterogeneous migration changes engines (for example Oracle to Amazon Aurora PostgreSQL) and is a two-step job: first convert the schema and database code (stored procedures, functions) with DMS Schema Conversion, the managed feature inside DMS, or the downloadable AWS Schema Conversion Tool (AWS SCT); then move the data with DMS.

Keep DMS distinct from its neighbours: AWS DataSync copies files and objects, not live database changes; AWS Transform MGN replicates whole servers and launches them on EC2, so it cannot deliver a managed Amazon RDS target; AWS Backup protects copies of resources for recovery and is not a migration replication tool.

Is the network fast enough? A rule of thumb

A link running flat out at 100 Mbps moves roughly 1 TB per day (1 Gbps roughly 10 TB per day), and real links rarely sustain full speed. So 60 TB over a 50 Mbps link (about 0.5 TB per day) takes around 120 days — roughly four months — before any slowdown. When the estimate runs past your deadline, or saturating the link would disrupt the business, plain online transfer is not enough. Amazon S3 Transfer Acceleration does not fix this: it routes uploads through CloudFront edge locations to improve the path over long distances, but it can never push data faster than your own internet connection.

Online transfer with AWS DataSync

AWS DataSync is AWS's online data movement service: an agent reads NFS or SMB shares, HDFS, or object storage and copies the files and objects to Amazon S3, Amazon EFS, or Amazon FSx, with encryption, integrity validation, and incremental re-runs. It suits one-time migrations and scheduled copies. When the existing link is the bottleneck, AWS suggests running DataSync over an AWS Direct Connect hosted connection procured from a Direct Connect Delivery Partner just for the duration of the project. Contrast AWS Storage Gateway: it gives on-premises applications ongoing hybrid access to cloud storage, rather than performing a migration copy.

Offline transfer: AWS Snowball and today's alternatives

AWS Snowball (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, encrypted throughout. It is the offline option the exam guide names. However, since 7 November 2025 AWS no longer offers any Snow Family device to new customers; existing Snowball customers can keep using it. For a new customer, AWS recommends:

• AWS DataSync for online transfer (optionally over a temporary Direct Connect connection, as above).
• AWS Data Transfer Terminal — a secure, reservable AWS physical location: you book a slot in the console, bring your own storage devices, and upload over a high-speed connection directly into AWS.
• AWS Partner offline data transfer services, available through AWS Marketplace.

The decision logic the exam tests has not changed: estimate transfer time over the usable link, and consider connectivity quality — remote sites, ships, or disconnected environments may have little or no usable network at all; continuous synchronization of a live database needs an online method (DMS); a one-time bulk move that the network cannot finish in time needs a physical path — Snowball if the customer already uses it, Data Transfer Terminal or a Partner service if not. Snowball Edge devices also offered local storage and compute at disconnected edge locations; for new edge-compute needs AWS points customers to AWS Outposts.

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

• AWS Transform MGN (formerly AWS Application Migration Service, the name in the exam guide) — the primary rehost tool: it continuously replicates source servers (physical, virtual, or other clouds) at block level and launches them natively on Amazon EC2 with short cutover windows. Scenario cue: "lift-and-shift servers to AWS with automated replication."
• AWS Migration Hub — named in the exam guide as the central place to discover servers, plan, and track migrations across tools. It has been closed to new customers since 7 November 2025; AWS points new customers to AWS Transform for similar discovery, planning, and tracking capabilities.
• AWS Database Migration Service (DMS) — database migration and continuous replication, covered above.
• Migration Evaluator — builds a data-driven business case from the measured utilization of your current on-premises servers, projecting what the same footprint would cost on AWS. Contrast AWS Pricing Calculator, where you enter configurations by hand for what-if estimates, and AWS Cost Explorer, which analyzes spend you already have on AWS. Scenario cue: "a business case based on our actual on-premises usage."
• 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.

Two neighbours look relevant but are not migration planners. AWS Trusted Advisor runs automated best-practice checks (cost, security, fault tolerance, performance, service quotas) on resources already running in your AWS account — useful after migration, but it does not plan one. AWS re:Post is a community technical Q&A site that also hosts AWS Knowledge Center articles — good for answering a specific question, but not a documented migration methodology or a team that will do the work.

The recognition pattern: rehost servers → AWS Transform MGN; databases → DMS; files and objects → DataSync; business case from measured usage → Migration Evaluator; documented strategies → Prescriptive Guidance; external expertise → AWS Partners; central tracking → Migration Hub for existing customers, AWS Transform for new ones.

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 that would need months to upload, 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 Transform MGN (formerly AWS Application Migration Service), with discovery and tracking in AWS Transform (Migration Hub is closed to new customers). The Oracle database migrates with AWS DMS full load and ongoing replication so it stays live until cutover — and if the team moves it to Aurora PostgreSQL, it is a heterogeneous migration: convert the schema with DMS Schema Conversion first, then move the data. The 80 TB archive is a one-time bulk move the link cannot finish in time: the company, new to AWS, cannot order a Snowball device, so it copies the archive to its own drives and uploads it at an AWS Data Transfer Terminal (or runs AWS DataSync over a temporary Direct Connect connection). 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.

Before committing, it built the business case with Migration Evaluator. 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.