SAP-C03 Migration Strategies: Discovery, Wave Planning, AWS Transform MGN, DMS, DataSync and Modernization

A migration strategy is the treatment you assign to each application after the portfolio assessment, and AWS names seven of them, the 7 Rs. You choose per application, not per estate: the same programme usually rehosts most servers to meet a deadline, replatforms the pieces where a managed service removes real work, refactors the few systems that block the business, and retires or retains the rest.

The deciding factors are the constraints a scenario states. A fixed exit date with a small team points to rehosting the bulk of servers and optimizing later; refactoring hundreds of servers before a deadline is the classic wrong move. Replatforming fits alongside rehosting when the change is small and low-risk, for example moving a self-managed open-source database to the same engine on a managed service when everything the database uses is supported there and the application needs only a new connection string. Licensing goals (stop paying for a commercial database or Windows Server) usually push a workload towards replatforming or refactoring rather than rehosting, because rehosting carries the licence with it.

Discovery collects the facts a migration plan needs: what servers exist, how heavily they are used, and which ones talk to each other. An inventory alone (an RVTools export, a CMDB, interviews with application owners) lists machines but misses runtime dependencies, so a wave plan built from it fails when an unlisted dependency, such as a shared service that nobody documented, breaks a migrated application. Collect utilization and server-to-server network connection data before you build move groups.

The current AWS tooling for this is AWS Transform, an agentic migration and modernization service that covers discovery, dependency mapping, wave planning, assessment, landing zone and network setup, and rehosting. Its discovery tool is deployed in vCenter (as a virtual appliance) and collects inventory, performance utilization and network connections without installing agents on each guest.

Closed services. AWS Migration Hub and Migration Hub Refactor Spaces closed to new customers on 7 November 2025, and AWS Application Discovery Service (including its Agentless Collector) is no longer open to new customers. AWS points new customers to AWS Transform for all three. Existing customers keep access, but a design for a company new to AWS migration services should not depend on them. AWS Application Migration Service has been renamed AWS Transform MGN; it is the same service and API.

Planning waves from dependency data

A migration wave is a group of applications and servers that are moved and cut over together, and good waves are built from dependency groups: an application, the database it queries and anything else it calls synchronously. Keep a chatty, latency-sensitive dependency group in one wave. Splitting it leaves some components in AWS and some on premises, and every synchronous call then crosses AWS Direct Connect or VPN, adding round-trip latency to each query. An application that issues hundreds of queries per transaction becomes unusable that way, even if only for a few weeks.

• Start with a pilot wave of low-dependency, low-criticality applications to prove runbooks, tooling and the team before business-critical systems move. Do not start with the highest-value application.
• Size a wave by moving unrelated servers, not by splitting a dependency group. If a wave is too big to test and cut over in one window, reschedule its independent machines into other waves.
• Move shared foundations first. Identity and name resolution are dependencies of every application. Before the first application wave, deploy domain controllers for the existing Active Directory domain in AWS (as an additional AD site) and forward the domain's DNS queries to them with Amazon Route 53 Resolver rules, so migrated servers keep authenticating if the Direct Connect link fails. AD Connector does not meet that requirement, because it is a proxy that sends every request to on-premises domain controllers; a new AWS Managed Microsoft AD domain is a different domain that every server would have to rejoin.
• Do not group by operating system or by tier (all databases first, applications later): both split dependency groups across the hybrid link.

AWS Transform MGN (formerly AWS Application Migration Service) rehosts physical, virtual and cloud servers onto Amazon EC2 by continuous block-level replication. You install the AWS Replication Agent on each source server; MGN launches lightweight replication servers in a staging area subnet you choose, which write the replicated data to low-cost EBS volumes. MGN rehosts x86 Windows and Linux servers; it cannot rehost an IBM z/OS mainframe.

Registration and data replication use different ports, so the source network must allow both outbound rules; the agent starts every connection, so nothing needs to connect inward to the source servers.

Keeping replication private. By default replication servers get a public IP address and data travels over the internet. The replication settings change this:

• Use private IP for data replication sends data to the replication servers' private addresses, over Direct Connect or VPN.
• Do not create a public IP for replication servers keeps them unreachable from the internet.
• For a data centre with no internet access at all, create an interface VPC endpoint for MGN and an interface VPC endpoint for Amazon S3 in the VPC reached through Direct Connect, and install the agent with the --endpoint and --s3-endpoint parameters pointing at them. A gateway endpoint for S3 cannot be used from on premises, and a NAT gateway does not give an isolated data centre an internet path. The staging subnet still needs to reach MGN, EC2 and S3 (through endpoints when it has no internet route).

Only these network settings decide the path replication data takes. Other replication settings, such as bandwidth throttling and the encryption of the staging EBS volumes, change how much link capacity is used or how data is protected at rest, not the route.

Each source server in MGN moves through these lifecycle states: Not ready (initial sync still running), Ready for testing, Test in progress, Ready for cutover, Cutover in progress, Cutover complete and Disconnected. Archiving is not a state: it is a housekeeping action that removes a server from the active list once cutover is complete. Two sets of settings shape what launches:

• General launch settings per server, including instance type right-sizing (Basic picks a type matching the source's CPU and RAM and overrides the instance type in the launch template; None turns that off so the template's type is used), Copy Private IP and start-instance-on-launch.
• The EC2 launch template MGN creates for each server, where you set the subnet, security groups, instance profile and instance type. MGN uses the template's default version.

Post-launch actions automate what engineers would otherwise do on every instance: MGN runs AWS Systems Manager documents through the SSM Agent on test and cutover instances, with predefined actions (for example installing the Amazon CloudWatch agent) and custom SSM documents (for example a hardening script). Settings belong in the launch configuration, not in the replication settings template, which governs only the staging area and replication servers.

Finalizing too early is costly: with replication stopped and the data discarded, launching again means reinstalling the agent and resyncing from scratch.

AWS Database Migration Service (DMS) migrates a database while the source stays online by combining a full load with change data capture (CDC): it copies the existing data, applies the changes made meanwhile, then keeps replicating until you cut over in minutes. A full-load-only task, a dump and restore, or a file copy of the data directory all need the source to stop accepting writes for the whole copy, so they fail a short-downtime requirement.

Native bulk load plus CDC-only. When a DMS full load would be too slow for a very large database, load the data with the engine's native tools (Oracle Data Pump, a SQL Server backup, pg_dump) from a consistent point, record that point (an Oracle SCN, a SQL Server or PostgreSQL LSN, a MySQL binary log position), and start a CDC-only DMS task from it. Because the CDC-only task starts at exactly the recorded point, every change after the native load is applied once and nothing is copied twice.

Things DMS does not do. DMS cannot use Amazon DynamoDB as a source (DynamoDB is a target only). DMS bidirectional replication has no conflict resolution, so it is not a way to keep two writable copies of a database in sync. Data validation compares rows between source and target and reports mismatches; it does not create objects or fix rows.

In a heterogeneous migration (for example Oracle or SQL Server to Aurora PostgreSQL) DMS moves data, not code: it creates only tables and primary keys (and in some cases unique indexes) on the target. Secondary indexes, foreign keys, views, stored procedures, functions and triggers come from DMS Schema Conversion (or the AWS Schema Conversion Tool), which converts the schema and code and applies it to the target before the data load. A target built by DMS alone runs slowly (no secondary indexes) and is missing its code objects.

Before choosing a target engine, run a DMS Schema Conversion assessment report against each candidate: it estimates how much of the schema and stored code converts automatically and lists the objects that need manual work. A DMS premigration assessment is different: it checks a replication task's settings and data types for problems before you run it.

Load order for a full load and CDC task:

1. Apply the converted tables and primary keys.
2. Disable foreign keys and DML triggers on the target during the full load (DMS loads tables in parallel, in no referential order, and triggers would fire on replicated rows and duplicate them). Create secondary indexes after the full load but before cached changes are applied, so CDC lookups are fast.
3. Re-enable foreign keys and triggers just before cutover. Batch optimized apply groups changes for throughput and does not preserve referential order, which is one more reason constraints stay off until cutover.

Large objects (LOBs)

Limited LOB mode truncates without failing the task, so check the largest LOB in each table before choosing a mode, and use data validation to confirm the result. DMS fetches LOBs in full and inline modes by looking up each row by its key, so these modes need a primary key or unique index on the source table, even for a full load only, and CDC replicates LOBs only for tables that have one. A table without such a key needs one added on the source.

AWS DataSync is the managed service for moving file and object data online: a DataSync agent (a VM on premises) reads from NFS, SMB, HDFS or self-managed object storage and writes to Amazon S3, Amazon EFS or Amazon FSx (Windows File Server, Lustre, OpenZFS, NetApp ONTAP). A task pairs a source and destination location and can be scheduled.

• Integrity: DataSync checks data in transit and can verify transferred data or the whole destination after the transfer.
• Incremental re-runs: later executions copy only what changed, so while users keep changing files you run scheduled incremental tasks and a short final sync at cutover.
• Bandwidth limit: each task can cap the bandwidth it uses, and the limit can be changed on a running execution. On a link shared with production, throttle during business hours and lift the cap after hours.
• Private connectivity: an agent is activated against one service endpoint type (public, FIPS, VPC or FIPS VPC). To keep agent-to-service traffic off the internet, activate the agent with a VPC service endpoint (AWS PrivateLink) in a VPC reached over Direct Connect or VPN. The public and FIPS endpoints are internet-facing.

Storage Gateway File Gateway and AWS Transfer Family give ongoing hybrid or partner access to storage; they are not bulk migration tools with verification and incremental sync. AWS Snowball Edge is no longer available to new customers (effective 7 November 2025), and AWS points them to DataSync, so do not plan an offline device transfer for a new account.

Replatforming moves a workload onto a managed service that takes over operational work (patching, backups, failover, scaling) while the application code stays the same or changes only in configuration.

Leaving commercial database licences

A company that wants to stop paying for commercial database licences moves to an open-source-compatible engine such as Aurora PostgreSQL. License Included RDS for Oracle or SQL Server still pays for the licence, inside the instance price. The question is how much application change you can afford:

• Full conversion: convert schema and code to PostgreSQL with DMS Schema Conversion, change the application's SQL and drivers, and move the data with DMS. It needs development time.
• Babelfish for Aurora PostgreSQL: Aurora PostgreSQL also understands T-SQL and the SQL Server wire protocol (TDS) on its own endpoint (port 1433 by default). An application whose SQL Server driver and T-SQL cannot change for now connects to that endpoint, so most stored procedures run as they are. Check compatibility first with the Babelfish Compass assessment of the exported DDL.

The Babelfish load order matters. Run the exported DDL through the TDS endpoint to create the tables and primary keys; load the data with DMS (an Aurora PostgreSQL target endpoint is preferred); then create views, procedures, triggers and foreign keys through the TDS endpoint. Letting DMS create the tables gives them PostgreSQL types instead of the T-SQL types Babelfish expects, and creating triggers and foreign keys before the load causes the same problems as in any DMS load.

Refactoring a monolith is done incrementally with the strangler fig pattern: a facade in front of the monolith sends the paths of extracted capabilities to new services and everything else to the monolith, so clients keep one hostname and each capability moves (and can move back) on its own.

• Behind an ALB: add listener rules for the migrated path (for example /search) that forward to a weighted pair of target groups, so you can shift traffic gradually and return it to the monolith in minutes. Route 53 weighted records split whole hostnames, not paths, and are slowed by DNS caching.
• For an API: an Amazon API Gateway REST API sends new resources to AWS Lambda and a {proxy+} resource to the monolith, reaching an on-premises monolith over Direct Connect through a VPC link to a load balancer in the VPC (a Network Load Balancer with IP targets pointing on premises, or an Application Load Balancer). Migration Hub Refactor Spaces used to provide this facade but is closed to new customers.
• Add an anti-corruption layer that translates between the monolith's model and the new service's model so the new service does not inherit the legacy data model.

Splitting the data

Each extracted service owns its database. When legacy modules must keep reading data the new service now owns, propagate changes from the new store, for example DynamoDB Streams to a Lambda function that updates the legacy tables. Dual writes in the request path leave the two stores inconsistent when one write fails, and DMS cannot read from DynamoDB.

• Transactional outbox: when a service must both commit data and publish an event, write the event to an outbox table in the same database transaction and let a relay publish new outbox rows. Any design that publishes outside that database transaction can lose an event or publish one for data that was never committed.
• Saga: a business transaction spanning services that own separate databases runs as a sequence of local transactions, orchestrated for example by a Step Functions Standard workflow, with a compensating action (refund, release seat) for each step that runs when a later step fails. A saga accepts that each service commits on its own and restores consistency through compensation, instead of locking every service into one distributed transaction.

Where serverless fits

Typical refactors: cron jobs move to EventBridge Scheduler, one scheduler that can invoke Lambda for short jobs and run an ECS task on Fargate for jobs longer than 15 minutes. Large uploads go straight to Amazon S3 with presigned URLs (so file content never passes through API Gateway or your own servers), and an S3 event notification starts processing. A process that waits days for a person runs in a Standard workflow paused on a task token until the approval tool returns the decision, with no polling. Large payloads go to S3 and only a reference travels in a message.

Legacy modernization moves the workloads that cannot simply be rehosted, and AWS Transform is the current AWS tooling for both mainframe and .NET code.

Mainframes. AWS Transform for mainframe analyses COBOL, JCL, CICS, Db2 and VSAM assets, generates documentation of the code, decomposes it into business domains and refactors those domains to Java while preserving the business logic. It pauses for human approval of the domain decomposition and the wave plan, so architects can approve boundaries and move one domain at a time instead of converting everything at once. Both AWS Mainframe Modernization runtime experiences (the managed runtime and self-managed) are closed to new customers, so do not design a new customer's modernization around them. MGN cannot rehost z/OS, and moving only the data with DMS leaves the COBOL logic to be rewritten by hand.

.NET Framework applications. AWS Transform for .NET ports .NET Framework applications (for example ASP.NET MVC) to cross-platform .NET, runs builds and unit tests on the result, and lets the applications run on Linux, for example in containers on Amazon ECS, without Windows Server licences. It cannot transform native Win32 DLLs. Any target that still runs .NET Framework needs Windows Server, so the Windows licence goes away only once the code is ported to cross-platform .NET.

Databases. Commercial-database modernization (Babelfish or full conversion to Aurora PostgreSQL) is covered in the replatforming section above.

Task 4.1 covers moving and modernizing workloads. Recovering them after a disaster (AWS Elastic Disaster Recovery, multi-Region failover) is Task 4.2, and backup governance and chaos engineering are Task 4.3.