Blogs

Key Takeaway

• AWS Application Migration Service is AWS’s primary tool for lift-and-shift server migration, renamed AWS Transform MGN in June 2026 with no change to how it works.
• It continuously copies source servers to AWS in the background, keeping the two environments in sync so production cutover windows are typically minutes, not hours.
• No application changes needed. Physical servers, VMware VMs, Hyper-V VMs, and servers from other cloud environments all migrate in their current configuration.
• Asia Pacific (Malaysia) is a supported region, meaning migrations land on local AWS infrastructure without data leaving the country.
• VSTECS KU supports cloud migration projects using AWS MGN through its lift-and-shift and professional services teams.

Introduction

AWS Application Migration Service is what AWS recommends when businesses want to move servers to the cloud without rewriting their applications. The approach is lift-and-shift: replicate what you have on-premises to AWS, test it, and cut over.

The service (known by its shorthand AWS MGN) replaced the retired AWS Server Migration Service and was renamed to AWS Transform MGN in June 2026. The underlying technology is unchanged. Only the name changed.

What Does AWS Application Migration Service Do?

The service installs a lightweight agent on each source server. That agent starts copying the server’s disk data to AWS using block-level replication, a method that works at the raw storage level rather than file by file. This keeps the AWS copy continuously current rather than relying on periodic snapshots (one-time data captures made at fixed intervals).

Replication runs in the background. When the team is ready to cut over, the AWS copy is only seconds or minutes behind the source. That is what keeps cutover windows short.

It works across a range of source environments:

The server arrives in AWS running the same operating system and software as before, with no changes to the application or its configuration.

How Does AWS Application Migration Service Move Servers to AWS?

Stage 1: Agent Installation and Replication

Install the replication agent on each source server. It connects to AWS and begins copying disk data into a staging area (a temporary holding environment that the service sets up and manages automatically). Initial replication time depends on data volume and available bandwidth. Once the initial copy is complete, the staging area stays in sync with the source in near real time.

Stage 2: Test Cutover

Before any production traffic moves, teams launch a test copy of the migrated server in AWS. This runs the actual replicated data, so teams can verify the server starts correctly, applications behave as expected, and network connections work in the AWS environment.

The source server keeps running the whole time. Once testing is done, the test copy is shut down, and nothing in production is affected.

The test cutover is where problems with networking, credentials, or application behaviour show up. Skipping or rushing it means those same problems appear during the real cutover instead.

Stage 3: Production Cutover

Once testing passes, the replicated data converts to a live EC2 instance (AWS’s virtual server) in the target AWS region. Because replication has been running continuously, the cutover window is typically minutes. The source server shuts down, the final sync completes, and the AWS instance goes live.

Stage 4: Validation and Decommission

Teams verify the migrated server in AWS, confirm everything is running correctly, then decommission the source. Completed migrations can be archived within the service for tracking purposes.

Managing Large Migrations: Applications and Waves

When an environment has many servers, two grouping layers make the project manageable:

Applications bring related servers together. A web server, application server, and database server that form one system can be grouped and cut over as a unit, so dependent servers always move together.

Waves sequence migrations in batches. Teams move and validate one group of servers before starting the next. This keeps the scope contained if something goes wrong during cutover and gives teams time to confirm stability before committing the next batch.

Mapping which servers depend on each other should happen before wave planning, not during. Moving a web server before its database is in AWS will cause failures that are straightforward to prevent but time-consuming to fix mid-migration.

VMware Migration to AWS Using AWS MGN

The replication agent installs on the VM’s own operating system, so it works on VMware virtual machines without needing access to the VMware host layer or any special VMware licences. The VM replicates to a standard EC2 instance in AWS.

For teams doing VMware migration to AWS, this is the path that moves workloads entirely off VMware onto native AWS infrastructure, using standard AWS management tools post-migration.

What to Prepare Before Starting a Cloud Migration with AWS MGN

Dependency mapping is the step most teams underestimate. Servers that share data or connections need to move together. Finding those relationships after replication has already started wastes time and can force replanning mid-project.

How VSTECS KU Supports Cloud Migration to AWS

Asia Pacific (Malaysia) is a supported target region for AWS Transform MGN, so migrations land on local AWS infrastructure and data stays in-country.

VSTECS KU’s lift-and-shift migration service covers the full process: environment assessment, agent deployment, replication monitoring, test cutover validation, production cutover, and post-migration checks.

For businesses that want help scoping the project, planning waves, or sizing AWS instances before starting, VSTECS KU’s professional services team can work through the environment assessment and migration plan before any replication begins.

Frequently Asked Questions

1. What is AWS Application Migration Service?

AWS Application Migration Service (AWS MGN) installs a replication agent on source servers, continuously copies their disk data to AWS, and enables low-downtime cutover to AWS EC2 instances. No application changes are needed: servers arrive in AWS running the same software as before.

2. What changed when AWS MGN was renamed AWS Transform MGN?

Only the name. AWS renamed the service in June 2026. The migration technology, APIs, and service behaviour are unchanged. It can be used directly through its own console or as part of the broader AWS Transform workflow.

3. How short are cutover windows with AWS Application Migration Service?

Because replication runs continuously, the source server and its AWS copy stay closely in sync. Production cutover windows are typically minutes: the time to finalise the last data sync and launch the EC2 instance.

4. Can AWS MGN migrate VMware virtual machines?

Yes. The agent installs on the VM’s own operating system, so VMware migration to AWS through this service works without needing VMware host access or specific VMware licensing. The VM becomes a standard EC2 instance in AWS.

5. What is wave planning and why does it matter for large migrations?

Wave planning divides servers into migration batches. Teams migrate and validate one wave before starting the next. For large cloud migration projects, this prevents all servers from moving at once and gives teams time to confirm each batch is stable before proceeding.

For Malaysian businesses planning a cloud migration using AWS Application Migration Service, VSTECS KU’s team can manage the process from scoping through to post-migration checks. Contact the team through the professional services page to get started.