Tasks 4.1 and 4.2 open Domain 4 by covering how an architect decides what to migrate, which of the seven common migration strategies fits each workload, and which specific AWS tooling actually moves the data, application, and identity layer.
Portfolio Assessment and the 7 Rs
Migration at Professional scale starts with a portfolio-wide assessment, not workload-by-workload guesswork: AWS Migration Hub aggregates discovery and migration tracking across tools and migration waves in one place, and AWS Application Discovery Service (agent-based or agentless) inventories on-premises servers, their dependencies, and utilization data to inform sizing and sequencing decisions before a single workload moves. That assessment feeds the seven common migration strategies, known as the 7 Rs: Retire (decommission something no longer needed -- often the highest-ROI, lowest-effort "migration" available); Retain (keep on-premises for now, due to compliance, recent investment, or low priority); Relocate (move a VMware-based workload to AWS with no changes, via VMware Cloud on AWS); Rehost ("lift and shift" -- move as-is, typically the fastest path and a common first wave to build migration momentum); Replatform ("lift, tinker, and shift" -- move with targeted optimizations, like moving a self-managed database to RDS without changing the application); Repurchase (move to a different product, typically a SaaS replacement); and Refactor/Re-architect (rebuild the application to take advantage of cloud-native capabilities, the highest effort but highest long-term payoff). Evaluating total cost of ownership (TCO) -- comparing current on-premises cost (including often-underestimated factors like power, cooling, real estate, and staff time) against the target AWS cost -- is what turns a 7 Rs classification into a business case a migration actually gets funded on.
Wave Planning and Prioritization
Once workloads are classified, wave planning sequences the actual migration: early waves typically favor low-risk, low-complexity workloads (validating tooling and process with contained blast radius) and quick wins that build organizational confidence and momentum, while waves handling business-critical or deeply interdependent systems come later, once the team has practiced the process. Dependency mapping (informed by Application Discovery Service) prevents migrating a workload before something it depends on is ready, which is a common real-world migration failure mode the exam tests via scenario.
Data Migration Tooling
For data specifically: AWS DataSync automates online transfer of large datasets between on-premises storage (NFS, SMB, or object storage) and AWS storage services, with built-in validation and scheduling for ongoing sync, not just a one-time move. AWS Transfer Family provides managed SFTP, FTPS, and FTP endpoints backed by S3 or EFS, useful when partners or legacy systems need to keep using those protocols against AWS-hosted storage. The AWS Snow Family (Snowcone, Snowball Edge, Snowmobile) moves large datasets physically when network transfer would be impractically slow or expensive -- the decision point is almost always bandwidth versus data volume versus available time: a fixed formula (data size divided by available bandwidth) tells you whether network transfer finishes in time, and Snow Family wins when it wouldn't. Amazon S3 Transfer Acceleration speeds up long-distance uploads to S3 over the public internet by routing through CloudFront edge locations, a lighter-weight option than DataSync for simpler, less frequent large-file uploads.
Application, Network, and Database Migration Tooling
For application migration, AWS Application Migration Service (MGN) is now AWS's recommended lift-and-shift tool, performing continuous, non-disruptive block-level replication of source servers to AWS and enabling a fast, low-downtime cutover -- it has broadly superseded the older SMS (Server Migration Service) as the standard rehost tool. Networking during migration typically layers Direct Connect or Site-to-Site VPN (covered in Domain 1) for the hybrid connectivity migration itself depends on, plus Route 53 for coordinating DNS cutover once a workload is live on AWS. Identity services extend during migration too -- AWS Directory Service (including AD Connector for proxying to an existing on-premises Active Directory, or a fully managed AWS Managed Microsoft AD) lets migrated workloads keep authenticating against existing identity without a hard cutover on day one. For databases, AWS Database Migration Service (DMS) performs the actual data migration (homogeneous, like Oracle to Oracle, or heterogeneous, like Oracle to Aurora PostgreSQL) with support for continuous replication to minimize cutover downtime, while the AWS Schema Conversion Tool (SCT) handles the separate problem of converting schema and application SQL code when the source and target database engines differ.
Key Mechanics
- The 7 Rs, in order of typical increasing effort/payoff: Retire, Retain, Relocate, Rehost, Replatform, Repurchase, Refactor/Re-architect -- Retire is the highest-ROI option when a workload is genuinely no longer needed.
- Wave planning sequences low-risk, low-complexity workloads first to validate process before tackling business-critical, highly interdependent systems.
- DataSync handles ongoing/scheduled large-scale online data transfer; Snow Family handles offline physical transfer when bandwidth makes online transfer impractical; Transfer Acceleration speeds simpler public-internet S3 uploads.
- AWS Application Migration Service (MGN) is the current standard lift-and-shift tool via continuous block-level replication, having superseded SMS.
- DMS moves the actual database data (with continuous replication for low-downtime cutover); SCT converts schema and SQL code when migrating between different database engines -- they solve different problems and are often used together for a heterogeneous migration.
Exam Tip: "An application is no longer used by the business" is the signature phrase for Retire -- don't assume every workload needs an active migration strategy.
Exam Tip: When a scenario gives a specific data volume and available network bandwidth and asks whether online transfer will finish in time, do the math (data size ÷ bandwidth) before assuming Snow Family is or isn't the answer -- the exam expects that calculation, not a rule of thumb alone.
Exam Tip: "Migrate a database from one engine to a different engine" (heterogeneous) requires both SCT (for schema/code conversion) and DMS (for the data itself) -- a same-engine (homogeneous) migration typically needs only DMS.
Worked example: A company must migrate 200 TB of on-premises file data to AWS within two weeks, but its available internet bandwidth would take over two months to transfer that volume online. The team also needs to migrate an on-premises Oracle database to Amazon Aurora PostgreSQL with minimal downtime, and modernize its identity so migrated EC2 workloads can keep authenticating against the existing on-premises Active Directory without a hard cutover. The plan uses AWS Snowball Edge devices to physically transfer the 200 TB within the two-week window (since the bandwidth math rules out online transfer), uses AWS SCT to convert the Oracle schema and SQL to PostgreSQL-compatible syntax followed by DMS with continuous replication for the actual data migration and low-downtime cutover, and deploys AD Connector to proxy authentication requests from AWS back to the existing on-premises Active Directory -- addressing the data volume constraint, the heterogeneous database migration, and the identity continuity requirement as three distinct migration problems, each solved with the tool built for it.