Lift and Shift to AWS - Which Migration Tool Works Best

Lift and Shift to AWS - Which Migration Tool Works Best

The phrase “lift and shift” suggests one simple action: pick the machine up and drop it in the cloud. In practice, migrating to AWS gives you several paths to the same destination. They differ in how much automation you get along the way, and in whether you rehost onto EC2 at all or relocate an entire platform. Devopsity, an AWS professional services firm, runs these migrations end to end, from assessment through to delivery, so this article is written from real projects rather than a brochure.

The short answer

For a clean lift and shift to AWS, the recommended rehost engine is AWS Transform MGN (formerly AWS Application Migration Service, MGN). It is the tool that physically replicates machines onto EC2 with minimal change. The rest of the decision comes down to your source:

Put differently: MGN is the rehost engine almost every time; the real decision is how much AWS Transform automation you wrap around it, and whether you land on EC2 at all.

Four paths to lift and shift on AWS

AWS Transform MGN - the default rehost engine

AWS Transform MGN is the tool AWS recommends for rehosting applications to AWS. It installs a lightweight replication agent on the source machine and replicates disk blocks to AWS continuously, with no downtime during replication. When you are ready, you launch test instances, validate, and then cut over with a short switchover window.

Why it is the default choice for lift and shift:

• It works with any source - VMware, physical servers, other hypervisors, even machines from another cloud. Block-level replication does not need to understand what is on the disk.
• Minimal change - the machine lands on EC2 as it was. That is precisely the definition of rehost.
• CloudEndure absorbed - the earlier CloudEndure Migration tool was folded into MGN, so there is no need to reach for a separate product today.

MGN is the answer when you are migrating a scattered set of machines with no single hypervisor in common.

AWS Transform for VMware - the automation layer on top of MGN

If the source is a large VMware estate, running MGN alone is not the whole job. The hours in a VMware project are consumed by the phases before replication: discovering what actually runs in the estate, mapping dependencies between machines, grouping them into migration waves, and translating the network configuration. AWS Transform for VMware automates exactly those stages with AI agents, keeping a human in the decision loop, and performs the move itself through MGN.

This is why, in practice, the most common pattern for VMware is not “MGN or Transform”, but MGN plus Transform for VMware - the agentic planning layer on top, the proven replication engine underneath. We cover how AWS Transform changes migration economics in our article on AWS Transform and AI automation.

A boundary worth noting: AWS Transform can also convert code (for example .NET from Azure) and refactor mainframe workloads. That is no longer lift and shift, it is replatform or modernisation. If you are looking for code conversion, see the separate article on AWS Transform and .NET conversion from Azure to AWS. In a clean lift and shift, the code stays untouched.

VMware Cloud on AWS - when vSphere should stay vSphere

VMware Cloud on AWS (VMC) is a different philosophy: instead of rehosting each VM onto native EC2, you relocate the entire vSphere stack onto dedicated hardware in AWS and keep managing it the way you managed it on-premises (vCenter, vSAN, NSX), typically using HCX for the move itself. Nothing changes in how the team works, only the location.

It is a strong option when you want to exit your own data centre without re-architecting and without retraining the team, or when you have a hard deadline and do not want the risk of a VM-by-VM migration. But it carries two caveats we always raise with clients:

• Economics after Broadcom. Following Broadcom’s acquisition of VMware, the VMC licensing and commercial model has been subject to change. For many new migrations, rehosting to native EC2 via MGN works out cheaper over a longer horizon, because you are not paying for the VMware layer.
• It is not modernisation. VMC keeps you on vSphere. If the goal is to get off VMware altogether, VMC is a stepping stone, not the finish line.

A full comparison of the VMware exit routes (VMC versus rehost to EC2), with costs and funding, is in our VMware to AWS migration guide.

Manual rehost and third-party tools - when they make sense

You can always import a machine image (VM Import/Export) or rebuild a server by hand and redeploy. For a few machines, with a team that knows what it is doing, that can be enough. The problem is scale: manual rehost has no continuous replication, so the cutover window is longer, and coordinating many machines turns into a spreadsheet and a prayer. The third-party tools that once filled this gap (such as CloudEndure) have been absorbed into MGN, so today there is rarely a reason to reach beyond native AWS services.

How we choose in practice

We reduce the decision to the migration source, not the tool’s price list:

1. One source, a single VMware hypervisor, large scale - MGN as the engine, AWS Transform for VMware as the planning layer.
2. Mixed sources (physical, different hypervisors, another cloud) - MGN on its own; Transform for VMware does not apply here.
3. You want to stay on vSphere - VMC, with eyes open about the post-Broadcom economics.
4. A few machines, a simple case - manual rehost can be enough, but cost the team’s time before you call it the cheapest.

Whichever path you take, lift and shift is usually the first stage, not the finish line. You move fast and unchanged, then optimise (rightsizing, managed services, modernisation) once you have landed in AWS. We cover how to pick a strategy in our guide to the 7 Rs of cloud migration, and real cost ranges in our AWS migration cost calculator.

Frequently asked questions

Which AWS migration tool is best for lift and shift?

For a clean lift and shift (rehost with no code change) the recommended engine is AWS Transform MGN - it replicates machines block-by-block onto EC2 and works with any source (VMware, physical, other hypervisors, another cloud). For a large VMware estate you add AWS Transform for VMware, which automates discovery, dependency mapping, and wave planning, then performs the move through MGN. If you want to keep the vSphere stack rather than rehost onto native EC2, the alternative is VMware Cloud on AWS. The choice depends on the migration source, not the destination cloud, because the destination is fixed as AWS. Devopsity, an AWS professional services firm, matches the path to your source and delivers the whole migration, from assessment through to cutover.

What is the difference between AWS Transform MGN and AWS Transform for VMware?

They are not competitors, they are two layers. AWS Transform MGN (formerly AWS Application Migration Service) is the replication engine that physically moves machines onto EC2. AWS Transform for VMware is the automation layer above it: agentic discovery of the vSphere estate, dependency mapping, wave planning, and network conversion. On large VMware projects they are usually used together - Transform plans, MGN moves.

When is VMware Cloud on AWS better than rehosting to EC2?

VMware Cloud on AWS (VMC) is better when you want to exit your own data centre without re-architecting and without retraining the team, or when you have a hard deadline and do not want the risk of a VM-by-VM migration. You keep vSphere (vCenter, vSAN, NSX) on hardware in AWS. Two caveats: after the Broadcom changes, VMC economics can be more expensive than rehosting to native EC2, and VMC is by definition not modernisation - you stay on VMware. If the goal is to get off VMware, VMC is a stepping stone, not the finish line.

Do I still need CloudEndure for lift and shift?

No. CloudEndure Migration was absorbed into AWS Application Migration Service (today AWS Transform MGN), so its replication capability is available natively in MGN. For a new lift and shift to AWS there is no reason to reach for a separate CloudEndure product.

Is lift and shift a good idea long term?

Lift and shift is usually the first stage, not the finish line. It lets you move to AWS quickly and without code changes, often under time pressure (a hosting contract ending, a VMware licence renewal). Once you have landed in AWS it pays to optimise: rightsizing, managed services, and where it is worth it, modernisation. A rehost with no follow-up optimisation can cost more than the environment you migrated from, so treat it as a start, not an end.

Next steps - a free migration assessment

Choosing a lift-and-shift tool starts with understanding the source. We assess your environment (what you are migrating, from which hypervisor, at what scale, with which dependencies) and come back with specifics: a recommended path (MGN on its own, MGN plus Transform for VMware, or VMC), a realistic timeline, and a projection of AWS MAP funding, which typically covers 70-80% of the partner cost.

We run migrations to AWS for organisations under genuine regulatory and availability constraints. Devopsity is an AWS partner and both advises on and delivers the whole migration, not just a plan on a slide.

Planning a lift and shift to AWS?

Book a free 30-minute call. We will match the path to your migration source and check whether the project qualifies for AWS MAP funding (typically 70-80% of the partner cost).

Book a migration assessment