13. Migration and Transfer

Migration services facilitate the secure and efficient movement of data and physical/virtual servers into the AWS ecosystem.

13.1 The 7 R's of Migration Strategy (exam-critical framework)

The exam frequently describes a business constraint (timeline, budget, willingness to refactor code) and expects you to name the correct migration strategy, not just a tool:

• Rehost ("lift-and-shift") — Move the application as-is, with no code changes, onto AWS infrastructure (e.g., EC2). Fastest path to the cloud; the standard answer for tight timelines or a large number of servers to move quickly. AWS MGN is the tool for this strategy.
• Replatform ("lift-tinker-and-shift") — Make a few targeted cloud optimizations without changing the core architecture (e.g., moving a self-managed MySQL database to Amazon RDS) — gets some managed-service benefit without a full rewrite.
• Refactor / Re-architect — Redesign the application to be cloud-native (e.g., breaking a monolith into microservices, moving to serverless). Most effort and cost, but unlocks the most agility/scalability long-term — the answer when a question emphasizes long-term innovation over migration speed.
• Repurchase ("drop and shop") — Replace the existing application with a different product, typically a SaaS alternative (e.g., moving a self-hosted CRM to Salesforce). The answer when a question implies the existing software is no longer worth maintaining/licensing.
• Retire — Decommission applications that are no longer needed, removing them from scope entirely. Correct answer whenever a discovery/assessment reveals unused or redundant systems — the "cheapest migration" is not moving something at all.
• Retain — Keep an application on-premises for now (e.g., due to compliance, recent investment, or it not being a migration priority yet), revisiting later. The answer when a question says a workload should stay put for the current phase.
• Relocate — Move infrastructure to the cloud without changes, at the hypervisor level, using VMware Cloud on AWS — distinct from Rehost because it moves the entire virtualized environment as a unit rather than re-provisioning each server individually.

The tell: "move quickly with no code changes" → Rehost. "Some optimization, keep the architecture" → Replatform. "Rebuild as microservices/serverless" → Refactor. "Switch to a different vendor's product" → Repurchase. "No longer used" → Retire. "Not migrating this yet" → Retain. "Move the whole VMware environment as-is" → Relocate.

AWS Application Migration Service (MGN)

Service Introduction: The primary migration service for lift-and-shift, automatically converting source servers (physical or virtual) to run natively on EC2.

Common Usage: Rapidly migrating large-scale server fleets to AWS with minimal downtime and data loss (low RPO). The process involves installing a Replication Agent on source servers, performing an initial replication, running acceptance tests, then a final cutover — the recommended tool when a company needs to move hundreds of servers quickly without the overhead of application refactoring.

Project Examples:

• Migrating an on-premises data center with 200 servers to AWS in under 30 days.
• Moving a multi-tier enterprise application from a secondary cloud provider to AWS.

AWS DataSync

Service Introduction: An online data transfer service that accelerates moving data between on-premises storage (NFS/SMB) and AWS storage services.

Common Usage: Automating recurring data transfers for migration, replication, or hybrid cloud workflows. Supports source protocols NFS, SMB, and HDFS, delivering into S3, EFS, or FSx. Fully managed, and can be configured to keep traffic private via a VPC endpoint. Requires a stable, sufficient internet connection — this is the key exam gotcha: on a slow/unreliable link, DataSync is the wrong answer and physical transport (Snow Family) is correct instead.

Project Examples:

• Synchronizing a local NAS with an S3 bucket for nightly off-site backups.
• Replicating massive research datasets from a local lab to Amazon FSx for Lustre.

AWS DMS (Database Migration Service)

Service Introduction: A service that helps migrate databases to AWS quickly and securely while the source database remains operational.

Common Usage: Supporting both homogeneous (RDS to RDS) and heterogeneous (Oracle to Aurora) migrations and continuous replication.

Project Examples:

• Migrating an on-premises SQL Server database to Amazon Aurora PostgreSQL.
• Continuously replicating data from an on-premises ERP database to Amazon Redshift for BI.

AWS Snow Family

Service Introduction: A collection of physical devices (Snowcone, Snowball, Snowmobile) for transporting petabytes of data into and out of AWS.

Common Usage: Moving data in edge locations with limited bandwidth or where a physical transport is faster than the network. Beyond simple transfer, Snowball Edge can also provide local compute and data collection in disconnected/remote environments. In bandwidth-constrained scenarios — e.g., petabyte-scale data over a slow or unreliable link with a tight deadline — physical transport via this appliance beats any over-the-wire method.

Project Examples:

• Migrating a 100 TB dataset from a remote research vessel with no internet.
• Deploying a Snowball Edge for local compute and data collection in a disconnected factory.

AWS Transfer Family

Service Introduction: A fully managed service that enables file transfers directly into and out of Amazon S3 or EFS via SFTP, FTPS, and FTP.

Common Usage: Migrating legacy file-transfer workflows to the cloud without changing client-side configurations or software. Highly available, automatically scaling across three Availability Zones. Supports managed workflows — e.g., triggering an AWS Lambda function to process a file immediately after upload. Note this manages SFTP/FTP endpoints into S3/EFS — it doesn't solve bulk migration of an on-premises storage device with bandwidth constraints; that's DataSync (stable connection) or Snowball (unstable/no connection).

Exam Example (SAA-C03 pattern): "A company has 500 TB of data on a local NAS that must be migrated to Amazon S3. The internet connection is highly unstable and limited to 10 Mbps. Which migration tool is most appropriate?" Answer choices: AWS Snowball Edge / AWS DataSync / AWS Transfer Family / AWS Application Migration Service (MGN).

• Correct Answer: AWS Snowball Edge — In bandwidth-constrained environments, physical transport of petabyte-scale data is faster and more reliable than any over-the-wire method.
• Why not DataSync? — It's an online transfer service that requires a stable, sufficient connection, which 10 Mbps for 500 TB is not.
• Why not Transfer Family? — Manages SFTP/FTP endpoints for S3, but doesn't address the physical bandwidth constraint of moving a massive dataset over an unstable link.
• Why not MGN? — Intended for lift-and-shift migration of server workloads, not bulk data transfer from an on-premises storage device.

Project Examples:

• Setting up an SFTP endpoint for external vendors to upload invoices to S3.
• Moving a legacy FTP-based document sharing system to a serverless, managed backend.