# AWS Cloud Architecture — Part 17: Migration & Modernization

> **Series:** AWS Cloud Architecture (17 of 19)
> **Part 1:** `01-fundamentals-and-account-structure.md` — Fundamentals & Account Structure
> **Part 2:** `02-iam-and-identity.md` — IAM & Identity
> **Part 3:** `03-compute-ec2-and-autoscaling.md` — Compute: EC2 & Auto Scaling
> **Part 4:** `04-networking-vpc-deep-dive.md` — Networking: VPC Deep Dive
> **Part 5:** `05-storage-s3-ebs-efs.md` — Storage: S3, EBS & EFS
> **Part 6:** `06-managed-databases-and-data-services.md` — Managed Databases & Data Services
> **Part 7:** `07-containers-and-serverless.md` — Containers & Serverless
> **Part 8:** `08-load-balancing-cdn-and-dns.md` — Load Balancing, CDN & DNS
> **Part 9:** `09-security-and-compliance.md` — Security & Compliance
> **Part 10:** `10-monitoring-logging-and-tracing.md` — Monitoring, Logging & Tracing
> **Part 11:** `11-cicd-iac-and-messaging.md` — CI/CD, IaC & Messaging
> **Part 12:** `12-multi-region-dr-migration-and-cheatsheet.md` — Multi-Region, DR, Migration & Cheat Sheet
> **Part 13:** `13-api-gateway-integration-and-identity.md` — API Gateway, Cognito & Event Integration
> **Part 14:** `14-beanstalk-sam-and-developer-tooling.md` — Elastic Beanstalk, SAM & Developer Tooling
> **Part 15:** `15-systems-manager-and-fleet-operations.md` — Systems Manager & Fleet Operations
> **Part 16:** `16-cost-optimization-and-finops.md` — Cost Optimization & FinOps
> **Part 17:** This file — Migration & Modernization
> **Part 18:** `18-data-analytics-and-engineering.md` — Data Analytics & Engineering
> **Part 19:** `19-machine-learning-and-ai.md` — Machine Learning & AI on AWS
> **Questions:** `questions.md`

Assumes you're comfortable with VPC networking (Part 4), database fundamentals and DMS (Part 6), and the
6 R's as briefly introduced in Part 12 — this part goes into the actual depth SAP-C02 expects, since
"Accelerate Workload Migration and Modernization" is 20% of that exam, its single heaviest-weighted domain.

## Table of Contents

1. [Why This Part Exists](#why-this-part-exists)
2. [The 6 R's, in Real Depth](#the-6-rs-in-real-depth)
3. [Choosing a Migration Strategy Per Application](#choosing-a-migration-strategy-per-application)
4. [Application Discovery Service — Knowing What You Actually Have](#application-discovery-service--knowing-what-you-actually-have)
5. [The Agentless Collector](#the-agentless-collector)
6. [Migration Hub — The Central Tracking Surface](#migration-hub--the-central-tracking-surface)
7. [AWS Transform — Agentic Migration and Modernization](#aws-transform--agentic-migration-and-modernization)
8. [AWS Transform MGN — Rehosting, Revisited](#aws-transform-mgn--rehosting-revisited)
9. [How MGN Actually Works: Continuous Replication and Cutover](#how-mgn-actually-works-continuous-replication-and-cutover)
10. [Wave Planning](#wave-planning)
11. [Database Migration Service, Revisited for Heterogeneous Migrations](#database-migration-service-revisited-for-heterogeneous-migrations)
12. [The Schema Conversion Tool](#the-schema-conversion-tool)
13. [Moving Data at Scale: The Decision Framework](#moving-data-at-scale-the-decision-framework)
14. [AWS DataSync — Online, Automated Data Transfer](#aws-datasync--online-automated-data-transfer)
15. [DataSync Enhanced Mode for Cross-Cloud Transfers](#datasync-enhanced-mode-for-cross-cloud-transfers)
16. [AWS Transfer Family — Managed File Transfer](#aws-transfer-family--managed-file-transfer)
17. [The Snow Family, and Its 2026 Reality](#the-snow-family-and-its-2026-reality)
18. [AWS Data Transfer Terminal](#aws-data-transfer-terminal)
19. [Choosing a Physical vs Network Transfer Path](#choosing-a-physical-vs-network-transfer-path)
20. [Network Foundations for a Migration](#network-foundations-for-a-migration)
21. [Modernization Beyond Rehosting: Refactor Patterns](#modernization-beyond-rehosting-refactor-patterns)
22. [Mainframe and VMware Modernization](#mainframe-and-vmware-modernization)
23. [Cutover Strategies and Minimizing Downtime](#cutover-strategies-and-minimizing-downtime)
24. [Rollback Planning — The Step Migrations Skip](#rollback-planning--the-step-migrations-skip)
25. [Cost During and After Migration](#cost-during-and-after-migration)
26. [Security During Migration](#security-during-migration)
27. [A Full Worked Example: Migrating a Three-Tier Application](#a-full-worked-example-migrating-a-three-tier-application)
28. [Migration Best Practices — The Consolidated Checklist](#migration-best-practices--the-consolidated-checklist)
29. [Part 17 CLI Cheat Sheet](#part-17-cli-cheat-sheet)
30. [Common Mistakes and Interview Traps](#common-mistakes-and-interview-traps)
31. [Worked Practice Problems](#worked-practice-problems)
32. [Summary and What's Next](#summary-and-whats-next)

---

## Why This Part Exists

Part 12 introduced the 6 R's and Migration Hub at a survey level, appropriate for a capstone chapter
covering many topics briefly. This part is where migration gets the depth its actual exam weight
deserves: Application Discovery Service and the Agentless Collector for knowing what's actually being
migrated, AWS Transform (2026's rebranded, agentic migration platform) and its MGN rehosting engine for
actually moving compute, and a full, currency-checked treatment of the data-movement services — including
two genuinely important 2026 changes worth knowing specifically: the Snow Family closing to new customers,
and Application Migration Service's rebrand to AWS Transform MGN.

## The 6 R's, in Real Depth

| R | What it means | Effort | Typical use |
|---|---|---|---|
| **Rehost** | "Lift and shift" — move as-is, no code changes | Lowest | Fastest path off a data center, especially under time pressure (a lease expiring) |
| **Replatform** | Small, targeted optimizations during the move (e.g., a self-managed DB to RDS) without a full re-architecture | Low-Medium | Quick wins where the destination platform removes real operational burden |
| **Repurchase** | Replace with a SaaS/COTS alternative | Varies | A legacy CRM/ERP replaced by a SaaS equivalent rather than migrated at all |
| **Refactor / Re-architect** | Redesign for cloud-native patterns (serverless, microservices) | Highest | Long-term strategic applications where the architecture itself is the bottleneck |
| **Retire** | Decommission — the application has no real remaining users | Lowest (but requires confirmation) | Routinely discovered during Application Discovery Service's own inventory phase |
| **Retain** | Leave in place — not migrating this cycle | None | Compliance-bound workloads, or applications with a pending replacement already planned |

## Choosing a Migration Strategy Per Application

The single most common exam and real-world mistake: applying one strategy uniformly across an entire
portfolio. A real migration portfolio is a **mix**, decided per application based on business criticality,
technical debt, remaining useful life, and available migration timeline — a legacy internal tool nearing
end-of-life is a Retire or Rehost candidate; a core revenue-generating platform with years of remaining
life is a much stronger Refactor candidate, since the investment pays off over a longer horizon. AWS's own
guidance (and SAP-C02's own framing) treats this as a portfolio-level decision exercise, not a single
architectural choice applied everywhere.

```mermaid
quadrantChart
    title Migration Strategy by Business Value vs Technical Complexity
    x-axis Low complexity --> High complexity
    y-axis Low business value --> High business value
    quadrant-1 Refactor / Re-architect
    quadrant-2 Replatform
    quadrant-3 Retire or Rehost
    quadrant-4 Repurchase with SaaS
    "Legacy internal tool": [0.2, 0.15]
    "Self-managed DB workload": [0.35, 0.55]
    "Core revenue platform": [0.75, 0.9]
    "Commodity CRM/ERP": [0.6, 0.3]
```

## The Migration Readiness Assessment: Before the 6 R's

Before applying the 6 R's to any specific application, most real migration programs run a **Migration
Readiness Assessment (MRA)** first — a structured evaluation across business, process, and technical
readiness dimensions (executive sponsorship, operating-model maturity, skills gaps, security/compliance
posture), producing a prioritized roadmap rather than jumping straight to per-application strategy
decisions. This maps directly onto AWS's own **Cloud Adoption Framework (CAF)**, which organizes readiness
across six perspectives: Business, People, Governance, Platform, Security, and Operations — a genuinely
common SAP-C02 reference point worth recognizing by name, since a question framed around "organizational
readiness" rather than a specific service is often testing CAF awareness specifically.

## Application Discovery Service — Knowing What You Actually Have

Part 12 mentioned Application Discovery Service briefly. The full picture: it runs in two collection
modes — an **agent-based** collector installed on individual servers for detailed, per-process
performance and dependency data, and the **Agentless Collector** (below) for environments where installing
software on every source server isn't practical. Both feed data into **Migration Hub**, building the
actual, evidence-based inventory a migration plan should be built from — replacing the all-too-common
starting point of an outdated spreadsheet nobody has updated in two years. Retiring workloads discovered to
have zero real traffic, mentioned in Part 12, is a direct, immediate output of this discovery phase.

## The Agentless Collector

For VMware-heavy environments specifically, the **Agentless Collector** deploys as a single virtual
appliance inside the on-premises data center and discovers an entire vCenter's worth of VMs — hundreds of
servers — without installing anything on each individual VM. As of late 2024/2025, it also discovers
**on-premises network connections** (which servers actually talk to which other servers, and over which
ports), directly answering the dependency-mapping question that used to require painful manual interviews
with application owners who often don't fully know their own system's dependencies. This network-dependency
data is exactly what feeds wave planning below — a server can't safely move to a different wave than the
dependencies it actively talks to, without at minimum accounting for the resulting cross-wave latency.

## Migration Evaluator — Building the Business Case

Before committing resources to a migration program, **Migration Evaluator** (a free AWS service, distinct
from AWS Transform's newer agentic assessment features) analyzes existing on-premises infrastructure usage
data — server utilization, existing licensing, current run-rate cost — to produce a directional TCO
comparison between staying on-premises and moving to AWS, typically presented to the actual budget-holding
stakeholders who need a business case before authorizing a migration program at all. Where Application
Discovery Service answers "what do we have and how does it depend on other things," Migration Evaluator
answers the earlier, business-facing question: "is this worth doing, and roughly what will it cost."

## Landing Zone Prerequisites

A migration shouldn't land workloads into a single, undifferentiated AWS account. Part 1's multi-account
landing zone (Organizations, OUs, a security-audit account, a shared-networking account) should exist
**before** the first production workload migrates, not be retrofitted afterward — retrofitting account
structure under a live workload is meaningfully more disruptive than building it first. AWS Control Tower
(Part 1) is the standard accelerator for standing this up quickly, and it's common for a migration program
to invest its first weeks entirely in landing-zone setup before touching a single application, precisely
because everything else in this part assumes that structure is already in place.

## Migration Hub — The Central Tracking Surface

**Migration Hub** aggregates discovery data and tracks migration progress across every tool in this part —
MGN rehosting status, DMS database migration status, Application Discovery Service inventory — from one
dashboard, regardless of which specific tool is doing the actual work for a given application. This is the
single-pane-of-glass answer to "what's our overall migration status" across a portfolio of potentially
hundreds of applications moving through different strategies simultaneously, avoiding the need to check
each underlying service's own separate console for a portfolio-level status view.

## AWS Transform — Agentic Migration and Modernization

The most significant 2026 development in this space: **AWS Transform**, an agentic AI-powered migration
and modernization platform covering Windows, VMware, mainframe, and .NET workloads. Rather than a person
manually running discovery, building a wave plan, and configuring network connectivity step by step, AWS
Transform's agents automate large parts of that lifecycle directly — analyzing discovered application
dependencies, business priorities, and technical constraints to propose optimized migration waves, then
handling landing-zone setup, network creation, and the actual rehosting or containerization work. As of
2026, it also offers **agentic assessment capabilities** — what-if cost scenarios, customizable
assumptions, and multi-format TCO analysis — automating what used to be a heavily manual, consultant-driven
business-case exercise.

> [!NOTE]
> AWS Transform still exposes a traditional, human-driven console path for teams that want direct control
> over replication and cutover timing rather than delegating those decisions to an agent — the agentic
> workflow is an acceleration option layered on top of the same underlying migration engines, not a
> replacement requiring an all-or-nothing choice.

## AWS Transform MGN — Rehosting, Revisited

Confirmed as of June 2026: **AWS Application Migration Service (MGN) was rebranded to AWS Transform MGN**,
reflecting its role as the replication engine powering AWS Transform above. Functionally, it's still the
same rehosting mechanism Part 12 introduced — any documentation, exam material, or older tutorial still
calling it "Application Migration Service" or plain "MGN" is describing the same underlying service under
its prior name, not a different product. It retains its compliance certifications (FedRAMP High, HIPAA,
PCI DSS, ISO, SOC) and remains available across every commercial region plus GovCloud.

## How MGN Actually Works: Continuous Replication and Cutover

```mermaid
sequenceDiagram
    participant Src as Source Server
    participant Agent as MGN Replication Agent
    participant AWS as AWS (staging area)
    participant Target as Target EC2 Instance

    Agent->>Src: Installed on source (physical, VM, or another cloud)
    Agent->>AWS: Continuous, block-level replication
    Note over AWS: Staging area kept in sync in near real time
    Note over AWS: Test launches performed against staging, non-disruptively
    AWS->>Target: Cutover: launch fully converted, native EC2 instance
    Target-->>Src: Source can be decommissioned once cutover confirmed
```

The key property worth internalizing: replication is **continuous and block-level**, running for days or
weeks before the actual cutover — meaning the source system keeps running normally, fully unmodified, right
up until the moment of cutover, and a **test launch** can validate the converted target instance boots and
runs correctly without ever disrupting the still-running source. This is what makes MGN-based rehosting
genuinely low-risk compared to a one-shot, all-at-once cutover: any problem discovered during a test launch
gets fixed and re-tested with zero production impact, since the real cutover hasn't happened yet.

## Wave Planning

A large migration portfolio doesn't move in one shot — it moves in **waves**, grouped by dependency
(applications that talk to each other move together, or in adjacent waves with a defined cutover order),
risk tolerance (lower-risk, non-critical applications often go first, both to build team confidence and to
surface process gaps before higher-stakes applications follow), and team capacity (only so many
applications can be actively cut over and validated at once without overwhelming the team doing it). AWS
Transform's agentic wave-planning capability, above, automates a first-pass version of this grouping
directly from discovered dependency data — a genuine time savings over building the same groupings by hand
from a dependency spreadsheet.

## Database Migration Service, Revisited for Heterogeneous Migrations

Part 6 introduced DMS for straightforward database migration. Its full relevance to this part: DMS
supports both **homogeneous** migrations (same engine, e.g., on-premises PostgreSQL to RDS PostgreSQL —
straightforward, minimal schema translation needed) and **heterogeneous** migrations (a different engine
entirely, e.g., Oracle to Aurora PostgreSQL) — the latter being a genuinely common, high-value
modernization move (escaping expensive commercial database licensing) but requiring real schema and code
translation the source and target don't share.

## DMS Deep Dive: Full Load, CDC, and Full Load + CDC

DMS replication tasks run in one of three modes, and choosing correctly matters for both migration speed
and cutover downtime: **Full Load** copies existing table data once, with no ongoing replication — the
fastest option for a table that can tolerate a full stop during the copy, and appropriate only for genuinely
small, low-change tables. **CDC (Change Data Capture)** replicates only ongoing changes from a defined
starting point, assuming an initial full copy already exists via another means. **Full Load + CDC**, the
standard choice for a production cutover, does the full copy first and then seamlessly continues with CDC
from the exact point the full load captured — giving the source database an unbroken replication stream
right up to the actual cutover moment, the database-specific instance of the same "keep the source live
until the last possible second" principle already established for MGN.

## The Schema Conversion Tool

For heterogeneous migrations, **AWS Schema Conversion Tool (SCT)** automates the schema translation step —
converting table definitions, stored procedures, and functions from the source engine's dialect to the
target's — and flags what it **can't** automatically convert (proprietary stored-procedure logic with no
direct equivalent, for instance) for manual rework. DMS then handles the actual data movement and
**ongoing replication** during the cutover window, so the source database keeps accepting writes right up
until the final switch — the same "keep the source live until the last possible moment" principle MGN
applies to compute, applied here to databases specifically.

## Moving Data at Scale: The Decision Framework

Before covering each data-movement service individually, the actual decision they collectively answer:
**how much data, over what network bandwidth, in how much time** decides whether an online (network) or
offline (physical) transfer path makes sense at all. The classic back-of-envelope math: a sustained 1 Gbps
connection realistically moves roughly 10 TB per day accounting for real-world overhead — a petabyte-scale
migration over that same link would take months, easily justifying a physical alternative if enough data
were involved. (Given the 2026 Snow Family changes below, that physical alternative today points
increasingly toward AWS Data Transfer Terminal rather than a device shipped to the customer's own site.)

## AWS DataSync — Online, Automated Data Transfer

**DataSync** automates online transfer between on-premises storage (NFS, SMB, a self-managed object store)
and AWS storage (S3, EFS, FSx), or between two AWS storage services, handling network optimization,
scheduling, data integrity verification, and **incremental** transfers automatically — re-running a
DataSync task after the first full copy only moves what's actually changed, the same delta-based efficiency
principle familiar from `rsync`. It requires a DataSync **agent** deployed on-premises (a VM image) for
on-premises sources, communicating outbound to the DataSync service, avoiding the inbound-firewall-hole
problem a naive transfer approach might otherwise require.

## DataSync Enhanced Mode for Cross-Cloud Transfers

A genuinely new 2025/2026 capability worth knowing specifically: DataSync's **Enhanced mode** supports
cross-cloud transfers (AWS to/from another cloud provider) **without requiring a DataSync agent** at all —
removing a real deployment step for the increasingly common multi-cloud migration or ongoing
data-synchronization case, where installing and maintaining an agent VM in a third-party cloud environment
was previously the friction point. This is directly relevant to any organization migrating away from
another cloud provider entirely, or maintaining a permanent multi-cloud data pipeline post-migration.

## AWS Transfer Family — Managed File Transfer

**Transfer Family** provides fully managed SFTP, FTPS, and FTP endpoints backed by S3 or EFS — for the
specific, common case of external partners or legacy systems that only speak one of those protocols and
can't be changed to call an S3 API directly. This isn't a bulk-migration tool in the same sense as
DataSync or MGN; it's an **ongoing integration** service, commonly kept running well past the migration
itself to preserve a partner integration that depends on SFTP specifically, without forcing that partner
to adopt a new protocol on the organization's own migration timeline.

## The Snow Family, and Its 2026 Reality

Worth stating with full currency accuracy, since this is a real, significant, and recent change: **AWS
closed the Snow Family to new customers on November 7, 2025**. The Snowcone devices and earlier-generation
Snowball devices were already discontinued in November 2024 (support for existing customers continuing
through November 2025); as of the 2025 closure, only the **Snowball Edge Storage Optimized (210 TB)**
device remains available, and **only to existing customers** — a brand-new AWS customer today cannot order
any Snow Family device at all. AWS's own stated direction is winding the family down in favor of online
transfer (DataSync) and physical drop-off locations (AWS Data Transfer Terminal, below). Any exam
material, tutorial, or mental model still treating "order a Snowball" as a routine, universally-available
large-data-migration option is describing a capability that, for a new customer, simply no longer exists.

## AWS Data Transfer Terminal

The service actually replacing Snowball's role for new customers: **AWS Data Transfer Terminal** is a
physical, secure facility (expanding through 2026 — Seattle, Phoenix, London, Paris, Sydney, Tokyo, San
Francisco, Los Angeles, New York, Munich, among the confirmed locations) where a customer physically brings
their own storage hardware and connects it to high-throughput network infrastructure (at least dual 100G
fiber) on site, transferring data directly over that connection rather than shipping a device back and
forth. This is a meaningfully different model than Snowball's "AWS ships you a device, you fill it, you
ship it back" — here, the customer's own hardware never leaves their possession, and the transfer happens
at terminal-grade network speed in one visit rather than over days of shipping transit in each direction.

## AWS Storage Gateway — A Bridge, Not Just a One-Time Transfer

Distinct from the one-time or scheduled transfer tools above, **Storage Gateway** provides ongoing, hybrid
storage connectivity — an on-premises appliance (virtual or physical) presenting AWS storage through a
familiar on-premises protocol. **File Gateway** presents an NFS/SMB share backed by S3; **Volume Gateway**
presents iSCSI block storage backed by EBS snapshots (in either cached or stored mode, trading local
storage footprint against latency); **Tape Gateway** presents a virtual tape library backed by S3/Glacier,
letting an existing backup application keep believing it's writing to physical tape. This is the right tool
specifically for a **long, gradual** migration or a genuinely permanent hybrid architecture, distinct from
DataSync's one-time-or-scheduled-batch model — an application that can't be fully cut over yet keeps
working against what looks like local/on-premises storage, while that storage is transparently backed by
AWS underneath, with no big-bang cutover moment required at all.

## Choosing a Physical vs Network Transfer Path

| Data volume | Available bandwidth | Recommended path |
|---|---|---|
| A few TB | Decent bandwidth (100+ Mbps) | DataSync over the network — simplest, no travel required |
| Tens to hundreds of TB | Limited bandwidth | AWS Data Transfer Terminal, if a location is reasonably accessible |
| Petabyte-scale, one-time | Any | Data Transfer Terminal (multiple visits/hardware units), or engage AWS directly for a large-scale migration engagement |
| Petabyte-scale, existing Snowball customer | Any | Snowball Edge Storage Optimized, if already an eligible existing customer |

For most organizations without an existing Snow Family relationship, DataSync and Data Transfer Terminal
are now the two real options — the decision tree has genuinely changed shape from what older migration
guidance describes.

## Network Foundations for a Migration

A migration's data-movement plan is only as good as the network path underneath it. Direct Connect (Part
4) is the standard choice for a sustained, high-volume, ongoing migration effort — a dedicated, predictable-
bandwidth private connection avoids both the variability of internet-based transfer and, for a
long-running multi-month migration, can be materially cheaper than paying internet data-transfer rates for
the full volume moved. A Site-to-Site VPN (Part 4) is a reasonable, faster-to-provision fallback for a
smaller migration or while a Direct Connect circuit is still being provisioned (which itself commonly takes
weeks).

## Modernization Beyond Rehosting: Refactor Patterns

For applications chosen for Refactor rather than Rehost, the concrete architectural patterns are exactly
what earlier parts of this series already cover — this part's job is connecting them to the migration
context specifically: **strangler fig** (incrementally routing traffic for individual features from a
legacy monolith to new, cloud-native services behind the same API Gateway, Part 13, until the monolith is
eventually fully replaced, never a single risky big-bang rewrite), **decomposition into microservices** on
ECS/EKS/Lambda (Part 7), and **database modernization** alongside the application layer (moving off a
commercial engine to Aurora, Part 6, often bundled with the same migration wave as the application
refactor since the two are frequently coupled).

## Mainframe and VMware Modernization

Two specific, heavily SAP-C02-relevant modernization categories worth naming directly: **mainframe
modernization** (AWS Transform's own stated focus area) typically involves automated code analysis and
transformation of COBOL/PL/I workloads toward modern languages and cloud-native runtimes, a genuinely
different discipline from a standard application rehost given mainframe workloads' unique batch-processing
and transaction-integrity characteristics. **VMware modernization** covers organizations moving off
on-premises VMware — either rehosting VMs as EC2 instances via MGN, or, for organizations wanting to keep
a VMware-compatible operating model temporarily during a longer transition, running on **VMware Cloud on
AWS** as an intermediate step before a fuller cloud-native refactor.

## Cutover Strategies and Minimizing Downtime

The actual cutover moment — the point where production traffic moves from source to target — benefits from
the exact same deployment-strategy vocabulary already covered in Parts 7 and 14: a **DNS-based cutover**
(Route 53, Part 8, with a low TTL set well in advance) shifting traffic once the target is validated, a
**blue/green** cutover keeping the source fully intact as an instant rollback target, or, for a database,
a carefully sequenced **read-replica promotion** (Part 6) minimizing the write-downtime window to the
smallest possible cutover gap. None of this is new mechanism — it's applying tools this series already
taught, at the specific, higher-stakes moment a migration's cutover represents.

## Rollback Planning — The Step Migrations Skip

The single most common real-world migration failure isn't a bad migration — it's a migration with **no
tested rollback path** when something goes wrong post-cutover. Because MGN/DMS's continuous replication
keeps the source system fully intact and running right up until cutover, the source remains a legitimate
rollback target for a defined window after cutover — but only if that window, and the actual mechanics of
reverting DNS/traffic back to it, were planned and tested **before** cutover, not improvised during an
incident. Treat "how do we get back to the source system if this goes wrong" as a mandatory planning
question for every wave, not an afterthought only considered once something has already broken.

## Cost During and After Migration

Two distinct cost phases worth separating: **during** migration, a workload often runs in both source and
target simultaneously for a period (the whole point of continuous replication), meaning a temporary, real
cost overlap should be budgeted for explicitly rather than surprising a finance stakeholder mid-project.
**After** migration, Part 16's full cost-optimization toolkit applies immediately — a freshly rehosted
workload, moved as-is with minimal changes by design, is very often running oversized or on the wrong
purchasing model, making the first Compute Optimizer/Cost Explorer review post-migration a near-guaranteed
source of quick wins.

## Security During Migration

Migration introduces its own temporary attack surface worth treating deliberately, not as an afterthought:
replication agents (MGN, DataSync) need appropriately scoped IAM roles and network paths (Part 2, Part 4)
rather than broad, temporary "make it work" permissions left in place after the migration completes; data
in transit during replication should be encrypted (both MGN and DataSync encrypt in transit by default);
and a migrated workload's security posture — security groups, IAM roles, encryption at rest — should be
explicitly reviewed against this series' Part 9 baseline rather than assuming a lift-and-shift preserved
whatever security configuration existed on-premises, since an on-premises network's implicit trust
boundaries (a flat internal network, for instance) rarely translate safely into a cloud VPC without
deliberate reconstruction.

## A Full Worked Example: Migrating a Three-Tier Application

A mid-sized organization migrating an on-premises three-tier application (web tier, application tier,
Oracle database) to AWS:

1. **Discovery**: The Agentless Collector runs against the VMware environment hosting all three tiers,
   surfacing CPU/memory utilization history and, critically, the network dependency data confirming which
   other internal systems the application tier actually talks to.
2. **Strategy selection**: The web and application tiers, both stateless and low-complexity, are chosen for
   **Rehost** via AWS Transform MGN; the Oracle database, given its licensing cost, is chosen for
   **Replatform** to Aurora PostgreSQL via DMS + SCT — a mixed-strategy portfolio decision, not a single
   choice applied uniformly.
3. **Wave planning**: Given the discovered dependency, the application tier and database are grouped into
   the same wave (their tight coupling makes an isolated cutover of just one of them risky); the more
   loosely coupled web tier gets its own, earlier wave to validate the MGN process on lower-risk traffic
   first.
4. **Data movement**: The application's file-storage volumes migrate via DataSync over a newly provisioned
   Direct Connect circuit, running incrementally for two weeks before cutover; the Oracle-to-Aurora schema
   conversion runs through SCT, with the handful of proprietary stored procedures SCT couldn't auto-convert
   flagged for manual rework by the DBA team.
5. **Cutover**: MGN test launches validate the converted web/app-tier instances non-disruptively while the
   source keeps serving production traffic; DMS ongoing replication keeps Aurora in sync with Oracle right
   up to the final cutover window, minimized to a low-traffic maintenance period.
6. **Rollback readiness**: The source VMware environment is deliberately kept running and untouched for two
   weeks post-cutover, with a tested, documented DNS-revert procedure — not needed in this case, but
   confirmed rehearsed before cutover, not assumed.
7. **Post-migration**: Compute Optimizer (Part 15) flags the rehosted instances as meaningfully over-
   provisioned within the first week, exactly as expected for an as-is lift-and-shift; a right-sizing pass
   and a Savings Plan purchase (Part 16) follow once the new steady-state usage pattern is confirmed stable.

## Migration Best Practices — The Consolidated Checklist

- Run Application Discovery Service (agent-based or Agentless Collector) before finalizing any migration
  plan — a plan built on an outdated spreadsheet routinely misses critical dependencies.
- Choose a migration strategy per application, not one strategy for the entire portfolio.
- Group applications into waves by actual discovered dependency, not by convenience or org-chart boundary.
- Keep the source system fully intact and running until cutover is confirmed successful — continuous
  replication exists specifically to make this possible with minimal risk.
- Plan and test the rollback path for every wave before cutover, not after something breaks.
- Budget explicitly for the temporary cost overlap of running source and target simultaneously during
  migration.
- Review a freshly migrated workload's security posture against this series' Part 9 baseline rather than
  assuming a lift-and-shift preserved appropriate controls.
- Run a right-sizing pass immediately after migration — an as-is rehost is very often oversized by design.
- Confirm current Snow Family eligibility before including it in a migration plan — it's closed to new
  customers as of November 2025.

## Part 17 CLI Cheat Sheet

| Task | Command |
|---|---|
| Start Application Discovery Service data collection | `aws discovery start-data-collection-by-agent-ids --agent-ids <id>` |
| List discovered servers | `aws discovery describe-agents` |
| Get Migration Hub application state | `aws migrationhub-config describe-home-region-controls` |
| Install the MGN replication agent (Linux) | `wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/linux/aws-replication-installer-init.py && python3 aws-replication-installer-init.py --region <region>` |
| Launch an MGN test instance | `aws mgn start-test --source-server-i-ds <id>` |
| Finalize an MGN cutover | `aws mgn start-cutover --source-server-i-ds <id>` |
| Create a DMS replication task | `aws dms create-replication-task --replication-task-identifier <name> --source-endpoint-arn <arn> --target-endpoint-arn <arn> --migration-type full-load-and-cdc --table-mappings file://mappings.json` |
| Create a DataSync task | `aws datasync create-task --source-location-arn <arn> --destination-location-arn <arn>` |
| Start a DataSync task execution | `aws datasync start-task-execution --task-arn <arn>` |
| Create a Transfer Family server | `aws transfer create-server --protocols SFTP --identity-provider-type SERVICE_MANAGED` |

## Common Mistakes and Interview Traps

| Mistake | Why it's wrong | Correct approach |
|---|---|---|
| Applying one migration strategy across an entire portfolio | Different applications have wildly different risk/value/effort profiles | Choose per application, based on business value, technical complexity, and remaining useful life |
| Building a migration plan from an outdated inventory spreadsheet | Missed dependencies surface painfully mid-migration instead of during planning | Run Application Discovery Service (agent-based or Agentless Collector) first |
| Treating a rehosted workload's initial sizing as final | An as-is lift-and-shift is very often oversized by design | Run a right-sizing pass (Compute Optimizer, Part 15) immediately post-migration |
| Assuming a Snowball device is a routine option for a new customer | The Snow Family closed to new customers on November 7, 2025 | Confirm current eligibility, or default to DataSync/Data Transfer Terminal |
| Skipping rollback planning until something actually breaks post-cutover | An untested rollback plan under real incident pressure is where migrations turn into outages | Plan and test the rollback path for every wave before cutover |
| Treating a lift-and-shift as security-neutral | On-premises implicit trust boundaries rarely translate safely into a cloud VPC unmodified | Explicitly review security posture against Part 9's baseline after any migration |

## Worked Practice Problems

**Problem 1:** A team is migrating 200 TB of data from an on-premises data center with a 500 Mbps internet
connection and a hard 30-day deadline. Would DataSync over that connection meet the deadline, and if not,
what's the current (2026) recommended alternative?

*Answer:* No — 500 Mbps realistically moves roughly 5 TB/day accounting for overhead, meaning 200 TB would
take around 40 days, past the 30-day deadline. Since the organization has no existing Snow Family
relationship (the family closed to new customers in November 2025), the current recommended alternative is
AWS Data Transfer Terminal — physically bringing storage hardware to a terminal location and transferring
over its high-throughput on-site network connection, completing in a fraction of the time a constrained
internet link would take.

**Problem 2:** A migration team wants to validate that a rehosted EC2 instance boots correctly and passes
application health checks before committing to a production cutover, without any risk to the still-running
source system. What MGN capability provides this, and why is it safe?

*Answer:* MGN's test launch capability. It's safe because MGN's replication is continuous and the staging
area is separate from the actual cutover action — launching a test instance from the replicated staging
data doesn't touch, pause, or otherwise affect the source system, which keeps running and replicating
normally throughout the test. Only `start-cutover` actually finalizes the migration.

**Problem 3:** A heterogeneous database migration (Oracle to Aurora PostgreSQL) needs several complex
stored procedures translated, and the team discovers AWS Schema Conversion Tool can't automatically
convert some of them. What's the correct response, and why doesn't this mean DMS/SCT are the wrong tools
for this migration?

*Answer:* SCT flags what it can't auto-convert specifically so the team can manually rework just those
specific pieces, rather than either blocking the whole migration or silently producing an incorrect
translation. This is expected, normal behavior for a heterogeneous migration involving proprietary
database-specific logic — SCT and DMS still handle the overwhelming majority of the schema translation and
all of the actual data movement/ongoing replication automatically; the manual rework is a bounded, known
gap, not a sign the tooling is unsuited to the migration.

## Summary and What's Next

Migration is a portfolio decision exercise as much as a technical one — the 6 R's applied per application
based on business value and complexity, discovered through Application Discovery Service rather than
assumed from a stale inventory, and tracked centrally through Migration Hub. AWS Transform and its MGN
rehosting engine (the 2026 rebrand of Application Migration Service) provide continuous, low-risk
replication and test-before-cutover safety; DMS and SCT do the equivalent for heterogeneous database
migrations. And two real, current-as-of-2026 shifts are worth carrying forward specifically: the Snow
Family's closure to new customers, replaced by DataSync and AWS Data Transfer Terminal, and MGN's rebrand
under the AWS Transform umbrella — both easy to get wrong from stale training data or an older tutorial,
and both squarely testable on SAP-C02's heaviest-weighted domain.

**Part 18** moves from moving data to actually deriving value from it at scale: Glue, Kinesis, EMR,
Redshift in depth, Lake Formation, Athena, MSK, and QuickSight — the full data-engineering toolkit this
series has only touched in passing until now, and all of DEA-C01's exam scope.