Lesson 282 · AWS Learning Path

AWS 282: AWS Transform migration planning and execution

Anil Jalela · Published Apr 3, 2026 · 11 min read

Why this lesson matters

Discovery describes a source estate; execution changes a production system. Between them, an architect must decide scope, application boundaries, move groups, wave order, target accounts and networks, launch settings, tests, approval authority, rollback, and decommissioning. A generated wave plan accelerates this work, but does not transfer accountability to an AI agent.

AWS Transform can guide discovery, planning, landing-zone and network preparation, server rehosting, testing, and cutover. For rehosting it orchestrates AWS Transform MGN, which continuously replicates source-server blocks and launches EC2 test or cutover instances. The safe model is human-approved automation: machines prepare and execute repeatable operations; accountable owners accept assumptions and irreversible gates.

Outcomes

By the end, you can:

• distinguish application groups, move groups, waves, jobs, strategies, runbooks, and cutovers;
• convert AWS281 evidence into an explainable wave plan;
• select an AWS Transform job type and state current service boundaries;
• define landing-zone, network, identity, replication and target-launch prerequisites;
• review an inventory file without accepting generated values blindly;
• follow replication, test, cutover, finalization and archive states;
• design entry, exit, approval, rollback and decommission gates;
• diagnose stalled or unsafe execution from evidence;
• model migration execution cost and cleanup; and
• produce a three-wave execution dossier without creating AWS resources.

Current service boundary

AWS Migration Hub stopped accepting new customers on November 7, 2025. Existing customers can continue ongoing projects, while new projects should start in AWS Transform. Do not erase Migration Hub from architectural knowledge: older exams, estates and integrations can still reference it. State whether a scenario is new or already enrolled.

AWS Transform migration jobs can combine these steps: discovery, migration planning, target-account connection, landing-zone construction, network migration and server migration. Preset jobs include end-to-end, discovery/planning only, network only, landing-zone/network/server, and planning/server migration. Select only the steps required; do not rebuild an approved landing zone merely because a wizard offers it.

Current server execution supports rehost and, for assigned waves, a separate source-code containerization path. A seven-R portfolio decision from AWS280 does not mean every strategy is executed by one server-rehost workflow.

Planning terms

A move group expresses dependency; a wave expresses execution capacity and time. Never split a hard dependency merely to meet a server-count target, and never combine an entire portfolio because shared DNS or monitoring touches everything.

Four planning stages

AWS Transform planning is iterative, not a one-way wizard.

1. Scope and analyze: reconcile discovered inventory, exclusions, software, connections, quality gaps and migration candidates.
2. Group applications: apply technical and business rules, review generated boundaries, and correct shared or missing components.
3. Generate move groups: classify hard, soft, business, operational and compliance dependencies; decide what must move together.
4. Build waves: combine move groups according to priority, criticality, risk, timeline, team capacity and target readiness.

Re-uploaded discovery can merge new records and flag impacted groups. Therefore freeze a versioned plan for execution, but keep planning open for future waves. Record input version, rules, manual changes, approver and timestamp.

Build a defensible wave order

Score and explain, rather than automatically migrating low numbers first.

A common progression is pilot, simple production, moderate groups, then critical/complex groups. It is not universal. A pilot must exercise representative controls and failure paths, not just move an expendable idle server. Include maximum wave size and concurrency based on people, change windows, replication bandwidth, quotas and support capacity.

Job and multi-account constraints

At current documentation state:

• one migration job targets one AWS Region;
• multi-Region work requires separate projects/jobs;
• multi-account migration requires accounts in AWS Organizations;
• a wave targets one account, so applications targeting different accounts need separate waves; and
• replicated data flows from source to the selected target account and Region, not through another Region.

Confirm these limits at implementation time. Build a mapping of application to account, Region, VPC, Availability Zones, subnet, security groups, IP/DNS, KMS ownership, backup policy, logging and operations team. A wave is not ready if any generated target identifier points to an unapproved or missing resource.

Foundations before replication

The target must be operable before source agents send data:

• organization, accounts, SCPs, IAM Identity Center and break-glass access;
• VPCs, subnets, routes, DNS, hybrid connectivity, inspection and egress;
• security groups and temporary replication paths;
• KMS keys, secrets, certificates and service-linked roles;
• quotas, tagging, Config/CloudTrail, security monitoring and budgets;
• backup, patch, observability, incident and vulnerability processes;
• application dependencies and temporary source-to-target connectivity; and
• owners for target operations, cost and security findings.

AWS Transform can help build landing-zone and network artifacts, but generated changes require the same design review, change control and validation as human-authored infrastructure. Compare intended and actual state before workload cutover.

Configure migration defaults safely

AWS Transform can initialize MGN in target accounts and establish account-level replication and launch defaults. Defaults improve consistency but also amplify mistakes. Review:

• staging-area subnet, routing, security, encryption and replication-server types;
• bandwidth/throttling and whether initial sync fits the schedule;
• target instance recommendation method and excluded families;
• EC2 launch template, subnet, security groups, IP assignment and tenancy;
• OS licensing choice and architecture compatibility;
• EBS volume types, encryption, IOPS/throughput and delete behavior;
• tags, hostname, IAM role and post-launch actions; and
• whether test instances are isolated from production side effects.

Account defaults apply when source records are created, while server-level settings can override them. Capture effective settings per server, not just a screenshot of a default page.

Validate the migration inventory

Before AWS Transform loads records into MGN, it prepares a CSV/XLSX inventory. Review every editable and generated field: source identity, wave, application, target account/Region, instance type, subnet, security groups, IP, license and tenancy.

Perform these checks:

1. reconcile server count and immutable source identifiers to the approved move group;
2. reject duplicates, unknown systems and assets whose discovery window is inadequate;
3. verify target account/Region against residency and operating model;
4. resolve subnet/security-group IDs to names, owners and intended paths;
5. challenge right-sizing with representative percentiles and failover headroom;
6. validate licensing/tenancy with procurement and vendor specialists;
7. prove boot mode, architecture, disk and supported-OS compatibility;
8. confirm tags, backup, monitoring and security onboarding; and
9. hash and version the accepted file, changes and approval evidence.

A syntactically valid spreadsheet can still encode a production outage.

Replication lifecycle

For rehost waves, the workflow is:

approved inventory -> MGN records -> agent deployment -> initial block sync
    -> continuous replication -> ready for testing -> test launch
    -> application acceptance -> cutover launch -> verify -> finalize -> archive

AWS Transform can deploy replication agents through a connector using Systems Manager orchestration. Validate operating-system support, connector health, source privileges, network/DNS/TLS reachability, disk free space and endpoint/security policy before bulk deployment.

Initial sync duration depends on data volume, change rate and effective bandwidth. Continuous replication then sends changed blocks. Monitor lifecycle, lag, backlog, replication-server health, bandwidth and alerts per server. “Ready for testing” means replicated data can launch; it does not mean the application works.

Pausing stops progress temporarily. Stopping replication is consequential: restarting requires initial synchronization again. Define who may pause/stop and how schedule impact is communicated.

Test without damaging production

Testing can launch a full wave or selected server IDs. Isolate test instances so they cannot process production queues, send customer email, run duplicate schedulers, write to source databases or advertise production routes.

Use a signed test plan covering:

• boot and OS/service health;
• identity, DNS, certificates and secrets;
• inbound/outbound dependencies and denied-path tests;
• data integrity and application transactions;
• performance against measured thresholds;
• monitoring, logs, alarms, backup and restore;
• vulnerability/compliance controls;
• failover/restart/patch behavior; and
• operator runbooks and business-user acceptance.

Record test data, expected result, actual evidence, defect owner and retest. Terminate superseded test instances only after evidence is preserved and ownership is confirmed.

Cutover, rollback and finalization

Cutover is a controlled change, not simply “launch latest copy.” A runbook should include freeze, final synchronization, source stop/quiesce, lag threshold, cutover launch, target verification, DNS/route/load-balancer switch, smoke/business tests, observation and communication.

Define rollback before starting:

• latest safe decision time;
• conditions such as error rate, latency, integrity or unowned dependency failure;
• authority to declare rollback;
• treatment of writes made in the target;
• source restart and traffic restoration steps;
• DNS TTL/cache and connection-drain behavior; and
• proof that source and data are consistent after return.

Launching a cutover instance is not finalization. Finalize only after technical and business acceptance. Finalization stops source replication, removes agents and locks lifecycle state; AWS describes it as not easily undone. Archive source-server records later when evidence and retention requirements permit. Physical/virtual source shutdown and disposal are separate owner-approved actions.

Human approvals and separation of duties

AWS Transform routes deployment operations requiring approval to authorized workspace administrators. Platform tool roles do not replace organizational change authority. Map at least:

Preserve who requested, approved and executed each action. No person should self-approve every consequential gate for a critical workload.

Execution evidence and dashboards

Maintain one UTC timeline across AWS Transform job events, approvals, MGN states, replication metrics, EC2 events, application telemetry, tickets and communications. A summary report or dashboard is a view, not the system of record.

Minimum wave evidence includes plan/input version, source/target IDs, effective launch settings, agent results, sync/lag history, test instances/results, defects, approvals, cutover timestamps, traffic changes, acceptance, finalization, archive/decommission and actual cost. Redact account IDs, host data and credentials in learner artifacts.

Diagnose execution failures

Do not restart an AWS Transform job casually: current documentation warns that restarting a stopped job starts it from the beginning, although created artifacts can remain.

Cost and cleanup

Budget for discovery/assessment tooling, connector capacity, replication servers, staging EBS, snapshots, test/cutover EC2, data transfer, Direct Connect/VPN, NAT/endpoints, logs, backup, licenses, support, labor and source/target parallel run. Model failed tests and schedule delay, not only ideal cutover.

After acceptance, inventory test instances, abandoned volumes/snapshots, replication infrastructure, temporary rules, credentials, exports and logs. Remove each through its owning workflow after retention evidence. Confirm billing and security inventory. Do not delete the source merely because a cutover instance launched.

Hands-on workshop: three-wave dossier

Use AWS281's supplied portfolio and create:

1. a scope/exclusion register with evidence confidence;
2. application groups and classified dependency edges;
3. move groups with a written reason for every hard edge;
4. three waves, each targeting one account/Region, with capacity rationale;
5. target mapping for account, VPC/subnet, SG, instance/storage/license and operations;
6. a versioned inventory-review checklist;
7. entry/exit criteria for inventory, replication, test, cutover, finalize and decommission;
8. one detailed cutover/rollback runbook;
9. a RACI and approval matrix; and
10. a cost register and evidence index.

Inject three changes: a newly discovered database link, a target subnet with insufficient addresses, and a critical server whose lag exceeds the cutover threshold. Show which groups/waves change, who approves, and why execution stops or continues.

Knowledge check

1. Why are move groups different from waves?

Move groups express co-dependency; waves schedule one or more move groups within business and delivery constraints.

1. Does READY_FOR_TESTING prove migration success?

No. It indicates replication readiness for launch, not application, security, recovery or business acceptance.

1. When should cutover be finalized?

Only after defined technical and business acceptance, because finalization stops replication and is not easily undone.

1. Can one wave target several accounts?

Current AWS Transform guidance says one account per wave; separate waves are required for different target accounts.

1. Why can a test launch harm production?

Duplicate schedulers, consumers, messages or writes can occur if the test network and integrations are not isolated.

1. What should happen when new discovery changes a dependency group?

Reassess impacted groups/waves, version the plan and obtain the required approvals before execution.

Lesson acceptance

Pass only when the learner's dossier makes every grouping, target, gate, test, authority, rollback and cost reproducible from evidence. Reject plans that copy generated waves without rationale, mix accounts in one wave, treat replication readiness as acceptance, omit test isolation, finalize before approval, ignore target writes during rollback, or equate record archival with safe source decommissioning.

Official sources

• Build an AWS Transform migration plan
• AWS Transform migration jobs and limitations
• Migrate servers with AWS Transform
• AWS Transform VMware and server migration capabilities
• AWS Transform diagrams and reports
• AWS Migration Hub availability change