Migration Planning and Execution

Map the 7R migration strategies, Application Discovery Service, DMS CDC, DataSync, Snow Family, and MGN to exam scenarios for SAP-C02 Domain D4 migration coverage.

SAP-C02 Domain D4 (Accelerate Workload Migration and Modernization) covers 20% of the exam. It tests not just your knowledge of tool names but your ability to judge which strategy and tool combination is optimal for a given scenario.

You need to think like a migration specialist. Tool selection depends on data size, network bandwidth, acceptable downtime, and source/target engine types.

 

7R Migration Strategies

AWS classifies the strategies for migrating on-premises workloads to the cloud into 7 categories. You must clearly understand the name and key characteristics of each strategy.

| Strategy | Description | Operational Overhead | Code Changes | |---------|-------------|---------------------|-------------| | Rehost (Lift & Shift) | Move as-is to EC2 | High (OS management) | None | | Replatform | Move to managed services (e.g., EC2 to Elastic Beanstalk, RDS) | Medium | Minimal | | Refactor / Re-architect | Redesign as microservices or serverless | Low | Significant | | Repurchase | Replace with SaaS (e.g., CRM to Salesforce) | None | None | | Retire | Decommission unused apps | None | None | | Retain | Keep as-is (no migration needed) | Current state | None | | Relocate | Move to VMware Cloud on AWS | Low | None |

!The 7R migration strategies

A common exam pattern is "minimize code changes + reduce operational overhead simultaneously," which maps to Replatform (Elastic Beanstalk). You upload your Java WAR/JAR file as-is and ALB, Auto Scaling, and CloudWatch are automatically configured.

Rehost is the fastest migration but leaves infrastructure management (OS patching, security configurations) unchanged. Refactor offers independent scaling and optimal performance but requires significant code redesign.

 

Application Discovery Service + Migration Hub — Pre-Migration Assessment

Before starting a migration, you must understand the on-premises environment. AWS Application Discovery Service (ADS) collects server utilization, dependency, and network connection data.

ADS provides two collection modes. The Agentless Collector deploys as an OVA to VMware vCenter and collects VM metadata and performance data without installing agents on each VM. However, it does not collect detailed inter-process dependency information. The Agent-based approach installs a Discovery Agent on each server to collect detailed CPU, memory, process, and network connection data. For non-VMware environments (Hyper-V, physical servers), the agent approach is required.

Migration Hub centrally manages data collected by ADS, visualizes inter-server dependencies, and helps plan migration groups (waves). It also provides unified tracking of execution tools like DMS, MGN, and DataSync.

DMS and DataSync are execution tools and cannot be used for pre-migration assessment purposes.

 

DMS — The Core of Database Migration

AWS Database Migration Service (DMS) is a fully managed service for migrating databases with minimal downtime.

Full Load copies the entire initial dataset. CDC (Change Data Capture) then continuously replicates changes from the source database after Full Load completes, reading from the source's transaction logs (Oracle redo log, MySQL binary log) and applying changes to the target. The Full Load + CDC combination enables minimal-downtime migration.

For heterogeneous database migrations (e.g., Oracle to Aurora PostgreSQL), AWS Schema Conversion Tool (SCT) is used alongside DMS. SCT automatically converts the source DB's schema, stored procedures, and functions to target-compatible formats.

For DMS to Redshift migrations, an S3 intermediate staging bucket is mandatory. DMS does not insert directly into Redshift — it uses the COPY command via S3. The DMS replication instance and the S3 bucket must be in the same region, and the DMS service role requires S3 write permissions and Redshift COPY execution rights.

 

DataSync — High-Speed File Transfer

AWS DataSync transfers data from on-premises NFS/SMB storage to S3, EFS, or FSx at high speed. It provides automation well beyond a simple file copy.

Automatic checksums verify integrity on both source and destination sides. Incremental synchronization skips previously transferred files and retransfers only changed files. Schedule-based automation lets you configure transfer frequency and time windows from the console.

DataSync supports transfer over Direct Connect or VPN to bypass the public internet. When migrating to FSx for Windows File Server, DataSync preserves NTFS ACLs, timestamps, and metadata during transfer.

The distinction from Snowball is critical: when Direct Connect or sufficient network bandwidth is available, choose DataSync. When there is no network or it is too slow, or for large-scale (tens to hundreds of TB) initial migrations, choose Snow Family.

 

Snow Family — Offline Large-Scale Data Transfer

For data that would take months to transfer over the internet or Direct Connect, physical devices are used.

Snowcone is the smallest device, supporting up to 14 TB. Edge computing is supported and it is highly portable. Snowball Edge Storage Optimized supports up to 80 TB (usable capacity) and is recommended for migrations under 10 PB. AES-256 encryption is automatically applied. Snowmobile is a semi-trailer truck supporting up to 100 PB and is used for massive migrations exceeding 10 PB.

When 500 TB needs to be transferred, using multiple Snowball Edge devices in parallel can complete the job within deadline. At 500 Mbps bandwidth, transferring 800 TB would take about 151 days, exceeding a 6-week deadline.

When many small files exist on a Snowball Edge, the cumulative cost of per-file AES-256 encryption initialization slows throughput dramatically. Batch compression — bundling files into tar or zip archives to reduce file count — is the solution.

 

MGN — VM Lift-and-Shift

AWS Application Migration Service (MGN) uses agent-based block-level replication to migrate VMs to AWS. It continuously replicates the entire disk including OS, drivers, agents, and configurations.

Install the MGN agent on operating VMs and replication begins in the background. After replication is complete, launch test instances for validation, then perform the final cutover. The cutover completes within minutes, minimizing downtime.

When OS upgrades are required, MGN cannot be used because it replicates the source OS as-is. In this case, build new EC2 instances with the desired OS (Replatform approach).

When large data volumes and VMs both need to be migrated in a bandwidth-constrained environment, combine MGN with Snowball Edge. Use MGN for VMs requiring real-time synchronization (like ERP), and Snowball for large data sets with bandwidth constraints.

 

Exam Key Points

"No code changes, fastest migration" -- Rehost (Lift & Shift)

"Minimize code changes + reduce OS management simultaneously" -- Replatform (Elastic Beanstalk)

"VMware environment, agentless discovery" -- ADS Agentless Collector

"Detailed process dependency analysis, non-VMware environment" -- ADS Discovery Agent

"Track migration progress, visualize dependencies" -- Migration Hub

"DB minimal downtime migration" -- DMS Full Load + CDC

"Heterogeneous DB schema conversion (Oracle to PostgreSQL)" -- AWS SCT

"DMS to Redshift required configuration" -- S3 staging bucket + IAM Role

"NFS/SMB incremental sync, checksum verification" -- DataSync

"Large-scale offline migration when network is absent or slow" -- Snow Family (Snowcone 14TB / Snowball Edge 80TB / Snowmobile 100PB)

"Snowball slow with many small files" -- batch compression (tar/zip) to reduce file count

"Full VM agent-based live replication, minimal downtime" -- MGN

"Migration requiring OS upgrade" -- MGN cannot be used; build new EC2 instances

Back to blog list