Migration & Modernization

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
2. The 6 R's, in Real Depth
3. Choosing a Migration Strategy Per Application
4. The Migration Readiness Assessment: Before the 6 R's
5. Application Discovery Service — Knowing What You Actually Have
6. The Agentless Collector
7. Migration Evaluator — Building the Business Case
8. Landing Zone Prerequisites
9. Migration Hub — The Central Tracking Surface
10. AWS Transform — Agentic Migration and Modernization
11. AWS Transform MGN — Rehosting, Revisited
12. How MGN Actually Works: Continuous Replication and Cutover
13. Wave Planning
14. Wave Planning, Visually
15. Database Migration Service, Revisited for Heterogeneous Migrations
16. DMS Deep Dive: Full Load, CDC, and Full Load + CDC
17. The Schema Conversion Tool
18. Moving Data at Scale: The Decision Framework
19. AWS DataSync — Online, Automated Data Transfer
20. DataSync Enhanced Mode for Cross-Cloud Transfers
21. AWS Transfer Family — Managed File Transfer
22. The Snow Family, and Its 2026 Reality
23. AWS Data Transfer Terminal
24. AWS Storage Gateway — A Bridge, Not Just a One-Time Transfer
25. Estimating Transfer Cost, Not Just Time
26. Choosing a Physical vs Network Transfer Path
27. Multi-Region Considerations During Migration
28. Network Foundations for a Migration
29. When a Refactor Is the Wrong First Move
30. Modernization Beyond Rehosting: Refactor Patterns
31. Mainframe and VMware Modernization
32. Containerization as a Lightweight Refactor
33. Testing a Migrated Application
34. Cutover Strategies and Minimizing Downtime
35. Licensing During Migration
36. Organizational Readiness: People and Process, Not Just Technology
37. Observability From Day One of the Target Environment
38. Rollback Planning — The Step Migrations Skip
39. Cost During and After Migration
40. Security During Migration
41. Modernizing the Data Layer Alongside the Application
42. Compliance and Data Residency During Migration
43. A Closing Note: Migration Is a Program, Not a Project
44. A Full Worked Example: Migrating a Three-Tier Application
45. A Note on Communication During a Migration Program
46. Migration Best Practices — The Consolidated Checklist
47. Part 17 CLI Cheat Sheet
48. Common Mistakes and Interview Traps
49. Worked Practice Problems
50. Summary and What's 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#

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.

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.

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#

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.

Wave Planning, Visually#

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.

Estimating Transfer Cost, Not Just Time#

The decision framework above focused on time; cost is the other half worth quantifying before committing to a path. Online transfer over the internet bills standard data-transfer-out rates (Part 16) for the volume moved, which can be genuinely significant at multi-terabyte scale; Direct Connect (Part 4) reduces that per-GB cost for sustained, high-volume transfer at the expense of the circuit's own provisioning lead time and fixed cost; and AWS Data Transfer Terminal bills per visit/session rather than per GB, which can make it materially cheaper than either online option purely on data-transfer-cost grounds once volume is large enough — a genuine reason to prefer it even when bandwidth alone wouldn't otherwise force the decision. Running this comparison explicitly, rather than defaulting to whichever path is most familiar, is itself a Part 16-style cost-optimization exercise applied to the migration's data-movement phase.

Choosing a Physical vs Network Transfer Path#

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.

Multi-Region Considerations During Migration#

For an organization whose source environment already spans multiple physical data centers, or whose target architecture is multi-region from day one (Part 12), migration planning needs to account for where each wave lands, not just when. A common, sensible pattern: migrate to a single primary region first, fully validate and stabilize there, and only then build out the secondary region's DR/multi-region posture (Pilot Light, Warm Standby, or Active-Active, Part 12) — attempting both the migration itself and a full multi-region architecture simultaneously multiplies the number of moving parts a team has to validate at once, without a corresponding reduction in risk.

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).

When a Refactor Is the Wrong First Move#

Worth stating as a deliberate counterpoint to the refactor patterns below: choosing Refactor for an application's first migration touch is a genuinely common overreach. A team that hasn't yet operated anything in AWS is taking on both a full application redesign and a completely new operational environment simultaneously — two large, compounding sources of risk at once. The more common, lower-risk sequencing in practice: Rehost first (get the application running on AWS with minimal change, building real operational familiarity with the platform), then Refactor as a deliberate, separate follow-on project once the team has that experience — "migrate then modernize" rather than "modernize while migrating," even for an application that's ultimately headed toward a full re-architecture.

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.

Containerization as a Lightweight Refactor#

Between a pure Rehost and a full Refactor sits a genuinely common middle path: containerizing an application during migration without otherwise changing its architecture — packaging the existing application into a container image and running it on ECS/Fargate (Part 7) instead of a raw EC2 instance. AWS Transform's modernization capabilities include automated containerization assessment specifically for this pattern, identifying which discovered applications are realistic containerization candidates based on their current architecture. This captures a real, immediate operational win (Fargate's managed scaling and patching, Part 7) without requiring the deeper application redesign a full microservices refactor would — a genuinely good fit for an application with real remaining useful life, but not enough strategic importance to justify a full re-architecture investment.

Testing a Migrated Application#

A migrated application needs validation across several distinct layers before cutover is trusted, not just "it launches without erroring": functional testing confirming the application behaves identically to the source (the same test suites that already exist for the application, run against the migrated target); performance testing confirming the target meets the same latency/throughput characteristics — genuinely important since a rehosted instance's underlying hardware, network path, and storage performance characteristics can differ meaningfully from on-premises even at an equivalent instance size; and security validation against Part 9's baseline, already flagged above. MGN's test-launch capability and DMS's ability to validate replicated data against the source (via its own data-validation feature, which compares row counts and checksums between source and target) both exist specifically to make this multi-layer validation possible without ever touching the live source system.

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.

Licensing During Migration#

Part 16 introduced BYOL vs License-Included as a cost decision. During migration specifically, it's also a planning decision worth surfacing early: an on-premises commercial software license (a database engine, an OS) may or may not be legally portable to AWS depending on the vendor's own licensing terms — some licenses are tied to specific physical hardware and simply don't transfer to a cloud instance at all, regardless of AWS's own BYOL support. Confirming license portability with the actual software vendor, early in the discovery phase, avoids a nasty late-stage surprise where a migrated application is technically running but legally unlicensed — a genuinely common, easy-to-miss migration blocker that has nothing to do with the technical migration path itself.

Organizational Readiness: People and Process, Not Just Technology#

SAP-C02 explicitly tests migration as more than a technical exercise. A genuinely common real-world failure mode: a technically flawless migration that still fails because the operations team wasn't trained on the new AWS-native tooling before cutover, runbooks (Part 15) weren't updated to reflect the new environment, or on-call rotations weren't briefed on what "normal" looks like for a freshly migrated system. The CAF's People and Operations perspectives, mentioned above, exist specifically to catch this — a migration program's readiness checklist should include "is the team that operates this day-to-day actually ready," not just "does the infrastructure work."

Observability From Day One of the Target Environment#

A freshly migrated workload should never run its first days in production AWS without the observability stack (Part 10) already wired up — CloudWatch alarms, dashboards, and log aggregation configured before cutover, not added reactively after an early incident with no visibility into what actually happened. This is a genuinely common gap: a migration project's success criteria often focus entirely on "does the application run," leaving monitoring as an implicit afterthought rather than an explicit cutover prerequisite — treat "the same alerting coverage the source environment had, at minimum" as a hard gate before any wave's cutover is considered complete.

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.

Modernizing the Data Layer Alongside the Application#

A migration wave that includes both an application and its database is also the natural moment to reassess the data layer's architecture, not just its engine (already covered under Replatform above). A monolithic application's single large relational database is frequently a strong candidate for the same decomposition-into-purpose-built-stores pattern Part 6 covers — splitting a workload that's outgrown a single RDS/Aurora instance across DynamoDB (for high-throughput key-value access patterns), ElastiCache (for hot read paths), and a retained relational core (for genuinely relational, transactional data) — rather than simply replatforming the exact same single-database shape onto a managed AWS equivalent and carrying the original architecture's limitations forward unchanged.

Compliance and Data Residency During Migration#

For a regulated workload, migration planning needs to account for where data is allowed to be during the migration itself, not just its final resting place. A healthcare or financial workload subject to data-residency requirements (Part 9) needs its replication path — MGN's staging area, DMS's target endpoint, DataSync's destination — provisioned in a compliant region from the very first byte replicated, not just the final production environment; a staging area temporarily provisioned in the wrong region is itself a compliance violation, even if the final cutover target is correct. This is worth confirming explicitly during the discovery phase, before any replication traffic actually starts flowing, rather than discovered as a gap during a post-migration compliance audit.

A Closing Note: Migration Is a Program, Not a Project#

Worth ending on, since it changes how success gets measured: a genuinely large migration portfolio is better run as an ongoing program with a repeatable, improving process across waves, rather than a single monolithic project with one fixed end date. Each completed wave should feed lessons back into the next — a runbook gap discovered in wave 1's cutover gets fixed before wave 2, not silently repeated. This mirrors the same "iterate and improve" instinct behind the FinOps Inform-Optimize-Operate cycle from Part 16, applied here to the migration process itself.

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.

A Note on Communication During a Migration Program#

Worth stating plainly since it's easy to treat as purely a technical exercise: a migration program with real cutover windows affects real people — application owners, downstream integration partners, and end-users who need advance notice of a maintenance window. A wave's cutover plan should include a communication checklist alongside its technical one: who needs advance notice, how far in advance, and through what channel — the same stakeholder-communication discipline Part 11's incident-management material applies to unplanned outages, applied here to a planned, scheduled change instead. A technically perfect cutover that blindsides a downstream partner's own on-call team is still, from that partner's perspective, indistinguishable from an unannounced outage.

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.
• Confirm software license portability with the actual vendor early in discovery, not after a workload is already technically running on AWS.
• Stand up the multi-account landing zone (Part 1) before the first production workload migrates, not retrofitted afterward.
• Include the operations team's own readiness (training, updated runbooks, briefed on-call rotation) in the migration checklist, not just infrastructure validation.
• Use Storage Gateway for a genuinely gradual, long-running hybrid transition; use DataSync/MGN for a defined, time-bound cutover.
• Confirm replication targets (MGN staging, DMS endpoints, DataSync destinations) land in a compliant region from the first byte transferred for any regulated workload, not just the final production target.
• Migrate to a single primary region first for a multi-region target architecture, and build out the secondary region's DR posture only once the primary is fully stable.
• Evaluate containerization as a lightweight refactor option for applications with real remaining life but not enough strategic weight to justify a full re-architecture.

Part 17 CLI Cheat Sheet#

Common Mistakes and Interview Traps#

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.

Problem 4: A migration program discovers, during Application Discovery Service data collection, that a scheduled batch application's on-premises software license is explicitly tied to its current physical server's hardware ID and cannot legally run anywhere else, including a cloud instance. What's the correct response, and which R does this application likely become?

Answer: This isn't a technical migration problem to solve — it's a licensing/procurement problem that needs resolving with the vendor (a cloud-eligible license purchase or subscription change) before any technical migration path is even relevant. Depending on the vendor's own cloud licensing options and the application's remaining business value, this commonly resolves toward either Repurchase (replacing the application with a cloud-native or SaaS equivalent that doesn't carry the same licensing constraint) or, if the application is genuinely low-value, Retire — discovered licensing blockers are a frequent, legitimate reason an application's initial Rehost assumption gets revised during planning.

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. Everything covered here — discovery, strategy selection, wave planning, replication, cutover, and rollback readiness — composes directly with every earlier part of this series: the landing zone from Part 1, the networking from Part 4, the databases from Part 6, the observability from Part 10, and the cost discipline from Part 16 all show up again here, applied at the specific, higher-stakes moment a migration represents rather than as separate new material.

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.