Migration is one of the four domains on the AWS Certified Solutions Architect Professional (SAP-C02) exam, and it carries significant weight. The exam expects you to evaluate complex migration scenarios, recommend the right strategy from the 7Rs framework, select appropriate migration tools, and design migration architectures that minimize downtime and risk.
This guide walks through each migration strategy in detail, covers the major AWS migration tools, and presents realistic scenarios that mirror what you will see on the exam. For a complete view of all SAP-C02 domains, see our SAP-C02 exam guide.
The 7Rs Migration Framework
The 7Rs framework provides a structured approach to deciding what to do with each application in your portfolio during a cloud migration. Each strategy represents a different level of effort, risk, and cloud optimization.
1. Retire
What it means: Decommission the application entirely. It is no longer needed.
When to use:
- Applications that are redundant or have overlapping functionality
- End-of-life applications with no active users
- Applications where the cost of migration exceeds the business value
Exam context: Retire is the correct answer when the scenario describes an application with no business justification for continued operation. The exam tests whether you can identify when migration is not the right answer.
2. Retain (Revisit)
What it means: Keep the application in its current environment for now. Revisit the migration decision later.
When to use:
- Applications with unresolved compliance or licensing issues
- Recently purchased or upgraded on-premises hardware
- Applications that require significant refactoring and the team is not ready
- Dependencies that must migrate after other applications
Exam context: Retain is correct when the question describes constraints that prevent immediate migration — regulatory holds, licensing complications, or dependency ordering.
3. Rehost (Lift and Shift)
What it means: Move the application to AWS without making any changes. The same OS, application, and configuration run on AWS infrastructure instead of on-premises.
When to use:
- Large-scale migrations where speed is the priority
- Applications that need to move quickly due to data center lease expiration
- Legacy applications where source code is unavailable
- When the team lacks cloud-native skills for immediate optimization
Key tools:
- AWS Application Migration Service (MGN) — The primary tool for rehost migrations. Performs continuous block-level replication from source servers to AWS.
- VM Import/Export — For importing virtual machine images as AMIs
Typical process:
- Install MGN replication agent on source servers
- Continuous replication begins to staging area in AWS
- Perform test launches to validate
- Execute cutover during maintenance window
- Redirect traffic to AWS instances
Exam tip: Rehost is the fastest migration strategy with the lowest initial effort. If the question emphasizes speed or a tight deadline, rehost is usually correct even if it is not the most optimized approach.
4. Relocate
What it means: Move the application to AWS without changes, but at the infrastructure level. This applies specifically to VMware workloads migrating to VMware Cloud on AWS.
When to use:
- Organizations heavily invested in VMware
- Applications that depend on VMware-specific features (vMotion, vSAN)
- When you want to move to AWS infrastructure without changing the virtualization layer
Key tool: VMware Cloud on AWS — Run VMware vSphere workloads natively on AWS infrastructure.
Exam context: Relocate appears in questions involving VMware environments. If the scenario mentions VMware and the requirement is minimal disruption, relocate is the answer.
5. Repurchase (Drop and Shop)
What it means: Replace the application with a different product, typically a SaaS solution.
When to use:
- Replacing a self-hosted CRM with a cloud-native CRM service
- Moving from a self-managed email server to a managed email service
- Replacing a custom-built application with a commercial SaaS product
- When the build-vs-buy analysis favors buying
Examples:
- Self-hosted database to Amazon RDS or Aurora
- Custom HR system to a SaaS HR platform
- On-premises file server to Amazon WorkDocs or S3
Exam context: Repurchase is correct when the question describes a scenario where maintaining the existing application is more expensive or complex than adopting a managed or SaaS alternative.
6. Replatform (Lift, Tinker, and Shift)
What it means: Make a few targeted optimizations during migration without changing the core architecture. You adopt some cloud capabilities without a full re-architecture.
When to use:
- Migrating a self-managed MySQL database to Amazon RDS (same engine, managed service)
- Moving from a self-managed Kubernetes cluster to Amazon EKS
- Replacing a self-managed message queue with Amazon SQS
- Containerizing an application for ECS without redesigning the architecture
Key distinction from Rehost: Replatform makes targeted changes to leverage managed services. Rehost makes no changes at all.
Key distinction from Refactor: Replatform preserves the core architecture. Refactor changes the fundamental design.
Exam tip: If the question asks for “some optimization” or “leverage managed services” without a full redesign, replatform is the answer.
7. Refactor / Re-architect
What it means: Fundamentally redesign the application to be cloud-native. This involves breaking monoliths into microservices, adopting serverless patterns, implementing event-driven architectures, and fully leveraging AWS-native services.
When to use:
- Applications that need to scale dramatically
- When you need features that the current architecture cannot support
- Monolithic applications being decomposed into microservices
- Applications moving to serverless (Lambda, API Gateway, DynamoDB)
Key AWS services:
- Lambda, API Gateway, Step Functions (serverless)
- ECS, EKS (container orchestration)
- SQS, SNS, EventBridge (event-driven patterns)
- DynamoDB, Aurora Serverless (cloud-native data stores)
Exam context: Refactor is correct when the question emphasizes scalability, agility, or cloud-native benefits. It is the most expensive and time-consuming strategy, so the business justification must be strong.
7Rs Comparison Table
| Strategy | Effort | Risk | Optimization | Speed | Cost |
|---|---|---|---|---|---|
| Retire | None | None | N/A | Immediate | Saves money |
| Retain | None | None | None | N/A | Status quo |
| Rehost | Low | Low | None | Fast | Low migration cost |
| Relocate | Low | Low | None | Fast | Low migration cost |
| Repurchase | Low-Medium | Medium | High | Medium | Variable (licensing) |
| Replatform | Medium | Medium | Medium | Medium | Moderate |
| Refactor | High | High | Highest | Slow | Highest migration cost |
AWS Migration Tools
The SAP-C02 tests your knowledge of when to use each migration tool. Here is a comprehensive overview.
AWS Application Migration Service (MGN)
Purpose: Primary service for rehosting (lift and shift) migrations. How it works: Installs a lightweight replication agent on source servers. Performs continuous block-level replication to AWS. Supports test launches and cutover with minimal downtime. Source support: Physical servers, VMware, Hyper-V, Azure VMs, other cloud providers Exam use case: Any question about migrating servers to EC2 with minimal changes.
AWS Database Migration Service (DMS)
Purpose: Migrate databases to AWS with minimal downtime. How it works: Creates a replication instance that connects to source and target databases. Supports full load, change data capture (CDC), or both. Key features:
- Supports homogeneous (MySQL to MySQL) and heterogeneous (Oracle to PostgreSQL) migrations
- Use AWS Schema Conversion Tool (SCT) for heterogeneous migrations to convert schema and code
- CDC enables near-zero-downtime migrations by replicating ongoing changes
- Supports S3 as a target for data lake ingestion
Exam use case: Any database migration question, especially those involving ongoing replication or schema conversion.
AWS DataSync
Purpose: Accelerated data transfer for file-based data. How it works: Agent-based service that transfers data between on-premises storage (NFS, SMB, HDFS, self-managed object storage) and AWS storage services (S3, EFS, FSx). Key features:
- Up to 10x faster than open-source tools
- Automatic integrity verification
- Bandwidth throttling
- Incremental transfers (only changed data)
- Scheduled transfers
Exam use case: Migrating file shares, NAS systems, or Hadoop data to AWS. If the question mentions NFS, SMB, or large-scale file transfer, DataSync is likely the answer.
AWS Snow Family
Purpose: Physical data transfer for large datasets or edge computing.
| Device | Storage | Use Case |
|---|---|---|
| Snowcone | 8 TB (HDD) or 14 TB (SSD) | Small edge locations, limited connectivity |
| Snowball Edge Storage Optimized | 80 TB | Large data transfers, local storage |
| Snowball Edge Compute Optimized | 42 TB | Edge computing with local processing |
| Snowmobile | 100 PB | Exabyte-scale data center migrations |
When to use: When network transfer would take too long. The general rule: if the transfer would take more than one week over your available bandwidth, consider Snow Family.
Exam use case: Questions involving petabyte-scale migrations, limited bandwidth, or remote locations without reliable internet.
AWS Transfer Family
Purpose: Managed file transfer service supporting SFTP, FTPS, FTP, and AS2 protocols. How it works: Provides fully managed servers that connect to S3 or EFS backends. Exam use case: When the question describes existing file transfer workflows (SFTP partners, B2B file exchange) that need to continue during and after migration.
AWS Migration Hub
Purpose: Central tracking dashboard for migrations across multiple tools. How it works: Aggregates migration status from MGN, DMS, and other tools into a single view. Key features:
- Application discovery integration
- Migration progress tracking
- Strategy recommendations via Migration Hub Strategy Recommendations
Portfolio Assessment Approach
The SAP-C02 tests your ability to plan large-scale migrations, not just individual application moves.
Discovery Phase
Before choosing strategies, you must understand what you are migrating:
AWS Application Discovery Service provides two discovery modes:
- Agentless discovery — Deploys an OVA in your VMware environment. Collects VM configuration, performance metrics, and utilization data. No agents on individual servers.
- Agent-based discovery — Installs agents on individual servers. Collects detailed data including running processes, network connections, and system performance.
AWS Migration Hub Strategy Recommendations analyzes discovery data and recommends a migration strategy (Rehost, Replatform, or Refactor) for each application based on compatibility and complexity.
Planning and Prioritization
Once discovery is complete, organize applications into migration waves:
Wave 1 — Quick Wins: Simple, standalone applications with few dependencies. Rehost candidates. Build team confidence and migration muscle.
Wave 2 — Core Business: Important applications that need replatforming or minor optimization. Moderate complexity.
Wave 3 — Complex Transformations: Applications requiring refactoring, database conversions, or significant redesign.
Wave 4 — Retire and Retain: Applications identified for decommissioning or delayed migration.
Dependency Mapping
Understanding application dependencies is critical for migration planning:
- Use Application Discovery Service agent-based mode for network dependency mapping
- Identify databases, shared storage, APIs, and middleware dependencies
- Group tightly coupled applications into the same migration wave
- Identify migration order constraints (e.g., database must migrate before application tier)
Real-World Migration Scenarios
Scenario 1: Data Center Lease Expiration
Situation: A company has 500 servers in a data center with a lease expiring in 6 months. They need to migrate everything to AWS. Teams have limited cloud experience.
Correct strategy: Rehost (lift and shift) the majority of servers using MGN. Retire any decommissionable applications. Retain applications with licensing restrictions. Replatform databases to RDS where straightforward.
Why: The 6-month deadline makes refactoring impossible for most applications. Rehosting is the only strategy that can move 500 servers in that timeframe. Optimization can happen post-migration.
Scenario 2: Oracle to Aurora Migration
Situation: A company wants to migrate from Oracle on-premises to Amazon Aurora PostgreSQL to eliminate licensing costs.
Correct approach:
- Use AWS Schema Conversion Tool (SCT) to convert Oracle schema, stored procedures, and functions to PostgreSQL
- Use AWS DMS with full load + CDC to migrate data with minimal downtime
- Validate data integrity in Aurora
- Cutover application connections during maintenance window
- Run parallel for a validation period before decommissioning Oracle
Why this is heterogeneous migration: Oracle to PostgreSQL requires schema conversion (different data types, PL/SQL to PL/pgSQL). SCT + DMS is the standard AWS-recommended pattern.
Scenario 3: Petabyte-Scale Data Lake Migration
Situation: A company has 2 PB of data in an on-premises Hadoop cluster. Network bandwidth is 10 Gbps with a dedicated Direct Connect connection.
Calculation: 2 PB over 10 Gbps = approximately 18.5 days of continuous transfer.
Correct approach: Use multiple Snowball Edge devices for the initial bulk transfer (faster than network transfer for this volume). Use DataSync for ongoing incremental synchronization. Once the bulk transfer is complete, use DataSync for delta syncs during cutover.
Alternative: If the question emphasizes “fastest possible” and money is not a constraint, Snowmobile could be considered for multi-petabyte transfers, but Snowball Edge is more practical for 2 PB.
Scenario 4: Monolith Decomposition
Situation: A company wants to break a monolithic Java application into microservices as part of their migration. The application has distinct modules for user management, order processing, and inventory.
Correct strategy: Refactor/Re-architect. Decompose into microservices using ECS or EKS. Use API Gateway for service communication. Replace the monolithic database with per-service databases (DynamoDB for inventory, Aurora for orders).
Phased approach on the exam: Questions may describe a gradual refactoring using the Strangler Fig pattern — route new features to microservices while the monolith handles legacy functionality, progressively migrating modules.
Migration Anti-Patterns on the SAP-C02
The exam also tests your ability to identify bad migration decisions:
- Refactoring everything at once — Too risky and slow for large migrations. Migrate first, optimize later for most applications.
- Ignoring dependencies — Migrating an application before its database causes outages.
- Using Snow Family for small datasets — If network transfer takes less than a week, online transfer is simpler and faster.
- Using DMS without SCT for heterogeneous migrations — Schema conversion is required when changing database engines.
- Treating all applications the same — Each application needs individual assessment. One strategy does not fit all.
Exam Tips for Migration Questions
- Read the constraints carefully: deadline, budget, team skills, compliance, and existing architecture all influence the correct strategy
- “Minimal downtime” for database migration almost always means DMS with CDC
- “Minimal changes” means rehost or replatform, never refactor
- Snow Family is for bandwidth-constrained scenarios or very large datasets
- DataSync is for file-based transfers (NFS, SMB, HDFS)
- MGN is for server migrations (the replacement for SMS and CloudEndure Migration)
- The exam loves questions about Oracle-to-Aurora migration — always pair SCT with DMS
- For questions about migration tracking and planning, Migration Hub is the central service
Frequently Asked Questions
What is the difference between rehost and replatform?
Rehost (lift and shift) moves the application to AWS without any changes. Replatform makes targeted optimizations during migration, such as switching from a self-managed database to RDS or containerizing an application for ECS, without changing the core architecture.
When should I choose refactor over replatform?
Choose refactor when the application needs fundamental architectural changes — breaking a monolith into microservices, moving to serverless, or redesigning for cloud-native scalability. Choose replatform when you want managed service benefits without redesigning the application architecture.
How does AWS MGN handle the cutover with minimal downtime?
MGN performs continuous block-level replication from the source server to AWS. During cutover, it stops replication, performs a final sync, and launches the target instance from the replicated data. The downtime is limited to the final sync and instance launch — typically minutes rather than hours.
Can DMS migrate data between different database engines?
Yes. DMS supports heterogeneous migrations (e.g., Oracle to PostgreSQL, SQL Server to Aurora MySQL). For heterogeneous migrations, you should first use the AWS Schema Conversion Tool (SCT) to convert the database schema, then use DMS for data migration with optional CDC for ongoing replication.
How do I decide between DataSync and Snow Family?
If the data transfer would take less than one week over your available network bandwidth, use DataSync (online transfer). If it would take longer or your bandwidth is limited, use Snow Family (offline transfer). For very large datasets (petabytes), Snow Family is almost always faster and more cost-effective.
What is the Strangler Fig pattern?
The Strangler Fig pattern is an incremental refactoring approach where you gradually replace components of a monolithic application with microservices. New features are built as microservices, and existing functionality is progressively migrated. An API Gateway or load balancer routes traffic between the monolith and new microservices during the transition.
Does the SAP-C02 exam test specific migration tool configurations?
The exam does not test step-by-step tool configurations, but it does test your ability to select the right tool for each scenario and understand how tools work together. For example, you should know that SCT + DMS is the pattern for heterogeneous database migration, and that MGN uses continuous block-level replication.
How should I handle licensing concerns during migration?
Licensing is a real factor in migration strategy selection. For bring-your-own-license (BYOL) scenarios, dedicated hosts or dedicated instances may be required. For applications with restrictive licenses, repurchase (replacing with a SaaS or AWS-native service) may be more cost-effective than maintaining the license on AWS.
Conclusion
Migration strategy is a defining topic on the SAP-C02 exam. Mastering the 7Rs framework, understanding each tool’s purpose, and practicing portfolio-level migration planning will prepare you to handle the complex scenario-based questions the exam presents. This knowledge connects directly to multi-account architecture (where do migrated workloads land?) and networking (how do you establish connectivity for hybrid migrations?).
Reinforce your migration knowledge with realistic exam practice. Sailor.sh’s SAP-C02 mock exams include scenario-based migration questions that test your ability to evaluate constraints, select strategies, and design migration architectures — just like the real exam.