Step 4 — Migration Planning

Somewhere around a third of the Professional exam is, in one form or another, a migration question dressed up in different scenario clothing. That’s not an accident — moving an existing estate to AWS, or between AWS accounts and Regions, is where the messy realities of an enterprise (legal contracts on software licenses, a mainframe nobody wants to touch, a 200 TB file share, a security team that won’t approve public internet transfer of customer data) collide with clean architecture diagrams. This step builds the decision framework you need when a scenario hands you an inventory of a thousand workloads and asks what happens to each one.

The 7 Rs: A Decision Tree, Not a List to Memorize

Every migration question ultimately reduces to picking one of seven dispositions for a given workload. Memorizing the list gets you nowhere on its own — you need to know which signals in a scenario point to which R.

Is the workload still needed?
│
├── No, nobody uses it ──────────────────────────────▶ RETIRE
│
├── Yes, but it can't move (regulatory, or already
│   on a contract that outlasts the migration) ─────▶ RETAIN
│
└── Yes, it needs to move. How much change can you invest?
    │
    ├── None — move as-is ───────────────────────────▶ REHOST ("lift and shift")
    │
    ├── Just the location, not the platform
    │   (e.g. VMware Cloud on AWS) ──────────────────▶ RELOCATE
    │
    ├── Replace it with a SaaS/COTS product ─────────▶ REPURCHASE
    │
    ├── Minor optimizations during the move
    │   (managed DB instead of self-hosted DB) ──────▶ REPLATFORM
    │
    └── Full redesign to be cloud-native ────────────▶ REFACTOR / RE-ARCHITECT

The exam signal words are worth drilling. “Move quickly with minimal changes, deadline in 60 days” almost always means rehost. “Reduce operational overhead of patching the database, but don’t touch the application” means replatform (self-managed MySQL on EC2 to RDS for MySQL, same engine, managed service). “The vendor is discontinuing support for our on-prem CRM” means repurchase — you’re not migrating the old thing, you’re buying its SaaS replacement. “Legal requires this data stay in a specific facility for three more years” means retain. Scenarios rarely say the word “rehost” outright; they describe the constraint and expect you to name the R.

A cost-governance angle that Professional questions like to fold in: rehosted workloads are the ones you immediately evaluate for Reserved Instances or Savings Plans once steady-state usage is observed, because a lift-and-shift doesn’t change the consumption pattern — it just changes where the servers live.

Migration Tooling by Workload Type

Workload Type	Primary Tool	What It Actually Does
Physical/virtual servers, whole-OS	AWS Application Migration Service (MGN)	Continuous block-level replication to a staging area, then a cutover with minimal downtime
Relational/NoSQL databases	AWS Database Migration Service (DMS)	Continuous replication with change data capture; Schema Conversion Tool handles engine translation for heterogeneous migrations
Large file systems, ongoing sync	DataSync	Online transfer with automatic checksumming, useful for NFS/SMB shares and recurring incremental syncs
Managed file transfer (SFTP/FTPS partners)	AWS Transfer Family	Fully managed SFTP/FTPS/FTP endpoints backed by S3 or EFS, for external partner integrations that can’t change protocol
Massive offline datasets, poor connectivity	Snow Family (Snowball, Snowball Edge, Snowmobile)	Physical device shipped to your site, filled, shipped back; Snowball Edge also runs compute at the edge during transfer

MGN deserves particular attention because it replaced the older Server Migration Service as the default lift-and-shift tool, and the exam expects you to know the mechanism: it installs a lightweight agent, continuously replicates disk blocks to a staging subnet in your target AWS account, and lets you test-launch the replicated servers without affecting the ongoing replication or the source environment. Cutover is a final sync followed by launching production instances from the fully replicated state — this is what makes downtime measured in minutes rather than the hours a traditional backup-and-restore migration requires.

DMS’s Schema Conversion Tool (SCT) matters specifically for heterogeneous migrations — Oracle to Aurora PostgreSQL, SQL Server to Aurora MySQL — where the schema, stored procedures, and proprietary SQL dialect need translation before replication can even begin. Homogeneous migrations (SQL Server to SQL Server, just moving location or to RDS) skip most of that translation work, which is why the exam sometimes tests whether you’d reach for SCT unnecessarily — you wouldn’t, for a same-engine move.

Choosing between DataSync and Snow Family usually comes down to bandwidth math the question will imply rather than state directly: a stated data volume against a stated (or clearly limited) network connection either supports an online transfer within the migration window or it doesn’t. When it doesn’t — satellite offices, ships, remote facilities, or simply datasets in the hundreds of terabytes to petabytes against modest bandwidth — physical transfer via Snow Family wins even though it feels counterintuitive to ship a physical box in a cloud-native course.

Wave Planning: Sequencing a Thousand-Workload Migration

No enterprise migrates everything simultaneously, and the exam tests whether you know how to sequence dependencies correctly, not just which tool to use per workload.

Wave 0 — Foundation (weeks 1-4)
  Landing zone, networking (VPC, Direct Connect/VPN), IAM, logging baseline

Wave 1 — Low-risk, low-dependency (weeks 5-10)
  Dev/test environments, internal tools, stateless web tier pilots

Wave 2 — Core dependencies (weeks 11-20)
  Shared databases, Active Directory, internal APIs consumed by later waves

Wave 3 — Business-critical (weeks 21-30)
  Customer-facing production systems, payment processing

Wave 4 — Complex/high-risk (weeks 31+)
  Mainframe-adjacent systems, workloads with unresolved licensing questions

The pattern to internalize: you migrate the things other things depend on before the things that depend on them, and you migrate low-risk workloads early to build organizational muscle memory and validate the landing zone before betting anything customer-facing on it. A scenario describing “the migration team wants to prove the process works before touching production” is describing Wave 1, and any answer that jumps straight to migrating the payment system first should be treated as wrong regardless of how technically sound that individual migration might be.

The AWS Migration Hub ties this together operationally — it aggregates migration status across MGN, DMS, and other tools into a single tracking view, which matters once you have dozens of workloads in flight across different waves and tools simultaneously and someone in a steering committee asks “what’s actually done.”

Hybrid Architecture During the Transition

Migrations take months to years, not a weekend, which means for most of that period you’re running a hybrid estate — some workloads on-prem, some in AWS, and they need to communicate as if they were on one network.

On-Premises Data Center                    AWS
┌──────────────────────┐                  ┌───────────────────────┐
│  Core apps (not yet   │   Direct Connect │   Migrated workloads   │
│  migrated)             │◀────────────────▶│   VPC                  │
│                        │   (private,      │                        │
│  Storage Gateway       │    consistent    │   S3 (backed by        │
│  appliance             │    low latency)  │   Storage Gateway)     │
└──────────────────────┘                  └───────────────────────┘
                │
                └── VPN (backup path / lower-priority traffic)

Direct Connect gives you a private, consistent-latency circuit to AWS instead of routing hybrid traffic over the public internet — important for both performance and for compliance requirements that specifically prohibit sensitive data traversing the public internet, even encrypted. Most enterprise migrations pair a primary Direct Connect circuit with a VPN as a lower-cost failover path, since Direct Connect provisioning can take weeks and a single circuit is a single point of failure the exam expects you to recognize as unacceptable at this scale — a resilient design uses two Direct Connect circuits from different providers/locations, or Direct Connect plus VPN failover, never one.

Storage Gateway bridges on-premises applications that expect local file or block storage to S3-backed durability without an application rewrite. The three types map cleanly to use cases: File Gateway presents an NFS/SMB share backed by S3 (good for on-prem apps reading/writing files during a phased migration), Volume Gateway presents iSCSI block storage with either cached volumes (working set local, full data in S3) or stored volumes (full data local, async backup to S3), and Tape Gateway replaces a physical tape backup process with a virtual tape library backed by S3 and Glacier — useful when a company’s existing backup software expects to talk to tape and rewriting that isn’t in scope for the migration itself.

Exam Focus: What Questions Test From This Step

Mapping scenario language (deadline pressure, “don’t touch the app,” vendor discontinuing support, regulatory hold) to the correct one of the 7 Rs
MGN’s continuous block-level replication mechanism and why it enables minimal-downtime cutover
DMS plus Schema Conversion Tool for heterogeneous database engine migrations versus simpler homogeneous moves
Choosing DataSync (online, recurring) versus Snow Family (offline, bandwidth-constrained or massive volume) based on implied bandwidth math
Correct wave sequencing: foundation and low-risk workloads before dependency-heavy and business-critical systems
AWS Migration Hub as the cross-tool tracking layer during large migrations
Direct Connect resiliency: recognizing a single circuit as a single point of failure and designing dual-circuit or DX-plus-VPN failover
Matching Storage Gateway type (File, Volume cached/stored, Tape) to the on-premises application’s storage expectation