AWS Application Migration Service: Planning Replication, Testing and Cutover

An application rehost can look straightforward on an architecture slide: replicate a server, launch it in AWS and switch traffic. The operational reality is less forgiving. An incomplete dependency map, an untested route, a stale launch setting or unclear rollback authority can turn a short migration window into a business interruption.

AWS now calls the service AWS Transform MGN; AWS Application Migration Service is the former name. The current service provides continuous block-level replication, automated machine conversion and orchestrated test and cutover launches for supported source servers. Those capabilities reduce manual work, but they do not replace workload planning, application validation or business approval.

This guide explains how enterprise teams should use AWS migration services to plan replication, testing and cutover. It focuses on the evidence required before a workload is marked ready, not on a console-only sequence.

Direct buyer answers

What is AWS Application Migration Service called now? AWS states that AWS Application Migration Service is now AWS Transform MGN. The current capability rehosts physical, virtual or cloud servers as native Amazon EC2 instances.

How does AWS Transform MGN reduce downtime? It continuously replicates source-server blocks to a staging area while the source remains in service. Teams can launch test instances, keep replication active and schedule the final traffic and data transition for an approved window.

What must be tested before cutover? Test the application, data, identity, network paths, integrations, monitoring, backup, recovery, performance and operating runbooks. Technical launch success alone is not business acceptance.

Start with a rehost decision, not a tool decision

AWS Transform MGN is designed for rehosting. That matters because the service moves server workloads into EC2 with limited source changes; it is not a substitute for deciding whether rehost is the right path. Some applications may be retired, retained, repurchased, replatformed or refactored instead. The portfolio decision should precede agent installation or replication configuration.

A rehost candidate should have a named business owner, target account and Region, dependency record, outage tolerance, recovery requirement, licensing position and post-cutover operator. The team should also know which servers form one business application. Migrating a web tier without its identity service, scheduler or file transfer path may produce technically healthy instances that cannot serve users.

Group servers into migration waves by dependency and business readiness. A wave should have a single runbook, clear entry criteria and an approval owner. Avoid grouping systems only by operating system or data-center rack; those categories rarely describe how the business process behaves.

How replication works in AWS Transform MGN

AWS Transform MGN uses a replication configuration to copy source-server blocks into a staging area in the target AWS account and Region. The staging resources are not the production target. They support continued replication and provide the data used when MGN launches test or cutover instances.

Before adding source servers, configure the replication template. AWS documentation states that template changes apply to newly added servers but do not automatically change servers already present in the console. That creates a control point: record the approved template version, compare existing-server settings and treat exceptions as deliberate decisions.

Replication planning should cover:

• target account, Region, staging subnet and network route;

• bandwidth capacity, firewall rules and approved endpoints;

• encryption, access permissions and logging responsibilities;

• storage choices and temporary-resource cost ownership;

• agent-based or supported agentless approach, where applicable;

• lag, backlog and health thresholds that block testing;

• pause, resume and stop procedures, including their cost and data effects.

AWS distinguishes pausing from stopping replication. Pausing keeps replication resources and billing active, while stopping replication removes associated snapshots, volumes and replication servers and stops billing. The runbook should use those terms precisely so an operator does not select a destructive action when the intent was only to pause activity.

Treat launch settings as controlled configuration

Launch settings determine how test and cutover instances are created. They include the target subnet, instance type, licensing choices and other EC2 launch-template settings. Configuration should be reviewed per server group rather than copied without checking application needs.

The review should confirm instance sizing, network interface placement, security groups, IAM role, storage mapping, tags, hostname behavior, boot requirements, license treatment and post-launch actions. If the test environment uses different routes, DNS or credentials from production, document the difference and how the team will validate the final path.

A useful approval record is a server-to-launch mapping: source identifier, target account, subnet, EC2 type, storage, operating-system note, security groups, application wave and configuration owner. This becomes the reference when test results differ from the intended production design.

Build a test plan that proves the application works

AWS recommends launching a test instance before cutover and its current guidance says to test at least two weeks before the planned migration. A test launch creates AWS resources in the customer account and therefore incurs the relevant resource charges. Replication continues while the launched test instance is evaluated.

The test plan should use production-like routes and representative load where practical. It should define expected results before the test begins. Otherwise, teams often record that an instance booted and call the migration successful while application, data and operating gaps remain open.

Use five evidence groups:

• Application: services start, user journeys work, jobs run and interfaces respond.

• Data: record counts, timestamps, transactions and file checks reconcile within approved tolerance.

• Network and identity: DNS, certificates, authentication, outbound routes and partner connections work.

• Reliability: monitoring, alerts, backup, recovery, patching and capacity signals are visible.

• Operations: support teams can access the system, follow the runbook and escalate an issue.

Defects should have an owner, severity, retest result and disposition. The business owner should mark the wave ready for cutover only after mandatory tests pass and accepted exceptions are recorded. A screenshot of a running EC2 instance is not enough.

Write the cutover runbook before the migration window

The cutover runbook translates test evidence into a timed operating procedure. It should identify who announces the start, who pauses business activity, who checks replication health, who changes DNS or traffic routing, who validates the application and who can order rollback.

Before launching cutover instances, AWS guidance identifies three useful indicators: the server lifecycle is Ready for cutover, data replication is Healthy and the next action allows a cutover launch. Treat those service indicators as necessary but not sufficient. The business runbook must also confirm change approval, application freeze, stakeholder availability, monitoring coverage and rollback readiness.

The runbook should include:

• last acceptable replication lag and the time it is checked;

• source freeze or transaction-control method;

• launch order for tightly coupled servers;

• DNS, load-balancer, route or firewall changes;

• technical and business validation steps;

• go/no-go time, decision owner and evidence recorder;

• rollback triggers and the latest safe rollback point;

• communication checkpoints and source-retention period.

AWS documentation notes that new source changes continue to flow to the staging area, not to already launched cutover instances. That distinction matters during the decision window. The data team must state what happens to transactions created after the final target launch and before traffic is redirected.

A practical go/no-go checklist

Use the following gate immediately before the approved cutover action:

• Scope gate: every server in the wave and every dependency has an owner.

• Replication gate: health, lag and backlog meet the approved threshold.

• Configuration gate: target launch settings match the approved mapping.

• Test gate: mandatory technical and business tests have passed.

• Change gate: freeze, communications and support coverage are active.

• Rollback gate: trigger, authority, data method and return steps are understood.

• Evidence gate: the operator records status, timestamps and approvals.

If one mandatory gate fails, delay the cutover. A schedule commitment should not silently replace an unmet acceptance criterion.

Roll back or finalize with care

After a cutover launch, validate the target through SSH or RDP as appropriate, then perform application and business checks. AWS Transform MGN allows a cutover to be reverted to the Ready for cutover state so the team can correct issues and launch again.

Finalization is materially different. AWS states that finalizing changes the lifecycle to Cutover complete, stops replication, discards replicated data and terminates replication resources. Do not finalize immediately after a successful smoke test. Wait until the business owner accepts the system, monitoring is stable, data is reconciled and the agreed observation period has passed.

Source retirement is a separate governance decision. Keep the source according to the approved retention, audit and rollback plan; then remove it through the organization's normal change process.

Published evidence and evidence still needed

In a published KCF Technologies engagement, Info Services describes a phased lift-and-shift of an industrial IoT analytics platform to AWS. The public page names the source as on-premises infrastructure and the target as an AWS environment using EC2, Amazon S3, AWS WAF, VPC endpoints, Application Load Balancers and AWS Database Migration Service for continuous database replication. It also says application services moved in logical waves.

The case is relevant because it shows source-to-target scope, named services and a phased delivery pattern. The public page does not publish a delivery timeline, cutover duration, achieved downtime, migration-server count or a numeric result tied specifically to MGN. Those details must remain unavailable until Info Services approves supporting evidence. Do not infer that MGN was used solely because the engagement was a rehost.

Citation-ready evidence block

AWS Transform MGN, formerly AWS Application Migration Service, rehosts supported physical, virtual and cloud servers as Amazon EC2 instances. AWS documents continuous block-level replication, a staging area, EC2 launch-template settings, separate test and cutover launches, Healthy replication status before cutover and explicit revert or finalize actions. A buyer should require application acceptance, data reconciliation, network and identity validation, operating readiness and rollback authority in addition to those service states. Verification sources: the AWS Transform MGN product page and AWS Transform MGN user guide.

Conclusion: make the cutover an evidence decision

AWS Transform MGN can automate major parts of a server rehost, but migration control still belongs to the delivery team and business owner. The plan should connect the rehost decision, wave scope, replication configuration, launch settings, test evidence, cutover steps, rollback authority and finalization criteria.

Info Services provides AWS assessment, migration planning and workload delivery across the AWS environment. Request an AWS migration assessment to examine application groups, replication constraints, test evidence and cutover controls before a production wave is approved.