How to migrate VMware and physical servers to AWS
Rehost servers to Amazon EC2 with AWS Transform MGN (formerly AWS Application Migration Service): install the replication agent, test, cut over and finalise.
Your migration plan
This moves VMware VMs, Hyper-V VMs and physical servers onto Amazon EC2 (virtual servers in AWS) as they are, without rebuilding them. AWS Transform MGN (formerly AWS Application Migration Service) puts a small replication agent on each server, keeps a copy of its disks up to date in AWS, and lets you test as often as you like before a short cutover. The time is driven by how long the first full copy takes over your internet link, so start agents well before each wave's cutover date.
One method for every VMware, Hyper-V or physical server, with continuous replication and test launches that do not stop it.
Other options and when to use them
- Move databases to Amazon RDS or Aurora: A database server would be easier to run as a managed engine. Treat each one as its own project.
- Amazon Elastic VMware Service: You must keep vSphere tooling or appliances but want to leave your data centre. VMware licensing still applies.
- Restore from backup into EC2: A server can take an outage and you want no replication running in AWS before cutover.
Build the AWS network and firewall rules first, prove the method on a pilot server, then replicate and cut over applications in waves, with databases and critical systems last. Each step depends on the one before: agents cannot replicate until the staging subnet and ports exist, and a server only works in AWS if the servers it depends on are reachable.
- Region, VPC, subnets, security groups and firewall rules (TCP 443 and 1500)Replication needs the staging subnet and both ports from day one, and test launches need a separate subnet.
- Shared services that every server needs: DNS and domain sign-in reachable from AWSA migrated server must still find DNS and its domain controllers after cutover, through a VPN, Direct Connect or a domain controller built in AWS.
- Pilot: one or two low-risk servers, replicated, test-launched and cut overMeasures how long the first copy takes over your link and shows the launch settings each server needs.
- Agents installed for each wave well before its cutover dateThe first full copy of every disk sets the earliest date a wave can cut over.
- Application waves: each application's web, app and database servers togetherSplitting an application between your data centre and AWS adds delay on every call between its tiers.
- Databases and critical systems last, or moved separately to RDSThey have the shortest outage windows, so they move once the process and timings are proven.
- Finalise, archive and decommission after each rollback windowFinalising stops replication for good, so it waits until owners sign off. Archiving frees the quota for the next wave.
Built-in and third-party tools treat these differently. Tick each one off once you have decided.
Download this checklist (Excel)How each tool handles it
Built-in methodAWS Transform MGN: the installer asks which disks to replicate. On Linux the root disk is always replicated. A disk added or reconnected later is not picked up until you rerun the installer, and it then copies from the beginning.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Run the installer without --no-prompt and type only the disks you want.
AWS docs: Installing the AWS Replication Agent on Linux serversHow each tool handles it
Built-in methodMGN: the agent copies disks from inside the operating system, and AWS's documentation does not mention VMware snapshots. The snapshots MGN describes are its own, taken in AWS when it launches test and cutover instances.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Consolidate old snapshots anyway, so the source has steady disk performance while the first copy runs.
AWS docs: AWS Transform MGN FAQHow each tool handles it
Built-in methodMGN: before each test or cutover launch, a conversion server changes the bootloader, injects the drivers EC2 needs and installs AWS cloud tools on the boot disk. The first Windows boot in AWS can take up to 45 minutes while Windows adjusts to the new hardware.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Wait for the first boot to finish before judging a test launch, and check EC2 status checks pass.
AWS docs: AWS Transform MGN FAQHow each tool handles it
Built-in methodMGN: AWS does not document its conversion removing VMware Tools. AWS's own blog uses a custom post-launch action (a script MGN runs on the new instance) to uninstall VMware Tools, and post-launch actions can also install the Systems Manager agent.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Add the removal script as a post-launch action before the first test launch, so every test shows the final state.
AWS blog: Migrate VMware VMs to Amazon EC2 with the AWS Replication AgentHow each tool handles it
Built-in methodMGN: finds the boot mode on the source and launches with the same one. Changing it may stop the instance booting. UEFI works only on Nitro instance types (most current EC2 types), must be chosen for any UEFI server using your own licence, and is not supported on CentOS 6 and RHEL 6.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Check each UEFI server's chosen instance type is a Nitro type before its test launch.
AWS docs: Boot mode (AWS Transform MGN)How each tool handles it
Built-in methodMGN: Instance type right-sizing picks a type that matches the source hardware and, when on, overrides the type in the EC2 launch template.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Check the instance type on the test instance before cutover, not only in the template.
AWS docs: Configuring launch settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: with Copy private IP on, MGN checks the test or cutover instance uses the same private IP as the source (IPv4 only). Otherwise the instance gets a new address in the subnet you set in the launch template.Veeam Backup & Replication (Restore to Amazon EC2)Not stated in Veeam's documentation: test it in your pilot.Tip: Search application settings for hard-coded IP addresses during inventory, and lower DNS TTLs (how long other systems cache a record) a few days before cutover.
AWS docs: Configuring launch settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: OS licensing in the launch settings chooses whether to bring your own licences (BYOL, using Windows Server licences you already own) to the new instance. Microsoft's rules limit when BYOL is allowed on AWS. Launch settings changed after a launch apply only to new launches.AWS License Manager (license type conversion)Converts an existing Windows Server instance between BYOL and licence included without relaunching. Moving to BYOL needs your own KMS (licence activation) server.Tip: Get your Microsoft licensing partner to confirm BYOL rights in writing before the first test launch.
AWS docs: Configuring launch settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: Transfer server tags copies custom tags you set on the source server in MGN to the test and cutover instances.Tip: Tag source servers in MGN with owner and cost centre before launch, so every instance is tagged from the start.
AWS docs: Configuring launch settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: the replication template sets the staging subnet, the replication server instance type (t3.small by default), the EBS disk type (gp3 by default) and the encryption key for staging disks.Tip: Set the replication template before the first agent installs, then check one source server's replication settings match it.
AWS docs: Replication settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: Throttle bandwidth in the replication template limits replication traffic, and Use private IP sends it over a VPN or Direct Connect (a private link to AWS). The temporary credentials for manual agent installs expire after one hour.AWS MGN connectorChecks prerequisites and installs the agent on registered source servers from the MGN console. Up to 500 source servers per connector.Tip: Throttle during business hours and lift the limit overnight while the first copy runs.
AWS docs: Replication settings (AWS Transform MGN)How each tool handles it
Built-in methodMGN: replicates continuously at block level. Test launches run from replicated data without stopping replication. At cutover you stop the application, wait for replication lag to reach zero and launch. Until you finalise you can revert; Finalize cutover removes replication and uninstalls the agent, and cannot be undone.Veeam Backup & Replication (Restore to Amazon EC2)Restores VM backups as EC2 instances with no replication running in AWS. Changes after the last backup are not included, so shut down the source and take a final backup first.Tip: Keep the source VM powered off but intact until the rollback window closes.
AWS CLI reference: finalize-cutover
- 1
Plan the landing
Before you install anythingShow the detailed steps (4) →Watch out: MGN's default quota is 150 source servers replicating at once in each AWS Region. Archived servers do not count.
Ways around it
- Request an increase in Service Quotas before the first wave, and archive servers once they are finished.
- 2
Set up MGN
Watch out: Teams often open only port 443, and servers then sit in initial sync.
Ways around it
- Get both firewall rules in place before you install any agents.
- If the default endpoints cannot be opened, use VPC endpoints with the installer's endpoint options.
Show the detailed steps (3) →Watch out: The first copy sends every block of every disk, which competes with users on a shared link.
Ways around it
- Turn on Throttle bandwidth in the replication template during business hours.
- Use a VPN or Direct Connect (a private link to AWS) for large estates.
- 3
Install the agents
Well before each wave's cutoverWatch out: The temporary credentials expire after one hour, so a long batch install fails part way.
Ways around it
- Generate fresh credentials for each batch of servers, or script the install.
Tools that can do it
- AWS MGN connectorChecks prerequisites and installs the agent on registered source servers from the MGN console. Up to 500 source servers per connector.
Show the detailed steps (4) →Watch out: MGN replicates only disks found at install time. A disk added or reconnected later starts again from the beginning.
Ways around it
- Rerun the installer to add the disk, and allow time for its full sync.
- 4
Test in AWS
Watch out: Instance type right-sizing overrides the instance type you set in the EC2 launch template.
Ways around it
- Decide per server whether to use right-sizing, and check the type on the test instance.
Show the detailed steps (3) →Watch out: MGN: a changed OS licensing choice only applies to new launches, so changing it after cutover normally means relaunching the instance.
Ways around it
- Confirm BYOL rights before the first test launch.
Tools that can do it
- AWS License Manager (license type conversion)Converts an existing Windows Server instance between BYOL and licence included. Moving to BYOL needs your own KMS (licence activation) server.
- 5
Cut over
In the planned change windowWatch out: Unless you use Copy private IP, instances get new addresses, which breaks hard-coded IPs, licence servers and firewall rules.
Ways around it
- Decide per server whether to copy the private IP, and update DNS rather than clients.
Watch out: Once users write data on EC2, rolling back means copying those changes back to the source.
Ways around it
- Until you finalise, revert to Ready for cutover in MGN, power the source back on and revert DNS.
Turn this phase into dated tasks with the cutover planner
Check your DNS records before and after the change
Show the detailed steps (3) → - 6
Finalise and clean up
After the rollback window and sign-offWatch out: Finalising removes replication and uninstalls the agent, so you cannot launch a new cutover from it.
Ways around it
- Set a rollback window in the runsheet, such as one business cycle, and finalise only after it.
Show the detailed steps (2) →Watch out: MGN: every server still replicating keeps replication servers and staging EBS disks running in your AWS account, billed as normal EC2 and EBS use.
Ways around it
- Move each wave from first sync to cutover in a planned window, then finalise and archive promptly.
Tools that can do it
- Veeam Backup & Replication (Restore to Amazon EC2)For servers that can take an outage: restores VM backups as EC2 instances with no replication running in AWS. Take a final backup after shutting down the source.
- Every server in the wave has a cutover instance that passes EC2 status checks with all its disks.
- Names resolve to the new instances and every application owner has signed off.
- Each instance has a successful AWS Backup job, Systems Manager management and CloudWatch alarms.
- Source VMs are powered off, servers are finalised and archived, and no replication servers remain.
Tools named in this plan are independent third-party products, not endorsed by the platform vendor and not paid placements. Check the tool's own documentation and run a pilot first.
Detailed steps
Open a part when you reach it in the plan. Each step says where to go, what to do and what you should see.
About this migrationWhat it covers, limits at a glance
AWS Transform MGN replicates whole disks from source servers into a staging area in your AWS account, then launches EC2 instances from the replicated data when you test or cut over. It works the same way for VMware VMs, Hyper-V VMs and physical servers because the agent runs inside the operating system.
AWS renamed AWS Application Migration Service to AWS Transform MGN on 8 June 2026. The CLI namespace is still aws mgn and the installer download buckets still use the old service name.
1What you need before step one
| Need | Details | Where to get it |
|---|---|---|
| AWS account admin | Administrative permissions to initialise AWS Transform MGN the first time and permission to create IAM roles. | AWS Management Console, https://console.aws.amazon.com |
| Agent installation role | An IAM role with the AWS managed policy AWSApplicationMigrationAgentInstallationPolicy, used for temporary credentials. | Install the AWS Replication Agent, step 2 |
| AWS CLI v2 (optional but used below) | For assume-role credentials and the aws mgn commands in this guide. | Install the AWS CLI, or use AWS CloudShell |
| Source server access | Local Administrator on Windows; root or sudo on Linux. | Your server team |
| Network path | Outbound TCP 443 from sources to the MGN endpoint and the S3 buckets AWS lists, and TCP 1500 from sources to the replication servers in the staging subnet. | Your firewall team; AWS docs: Network requirements |
| Target VPC | Production, test and staging subnets in the target Region. | Amazon VPC console |
| Templates | Application inventory and dependency map, Migration wave plan, Cutover runsheet. | Templates linked at the end of this guide |
2Plan the account, Region and network4 steps
- 1
Pick the Region
Where: AWS General Reference: AWS Transform MGN endpoints and quotas page (docs.aws.amazon.com/general/latest/gr/mgn.html), then the Region selector at the top right of the AWS Management ConsoleCheck that MGN is available in the Region you want. In Australia it is available in Asia Pacific (Sydney)
ap-southeast-2and Asia Pacific (Melbourne)ap-southeast-4. Choose the Region closest to your users that meets your data residency, latency and service availability needs. Check that the instance types you need exist in that Region.aws ec2 describe-instance-type-offerings --location-type region --region ap-southeast-2 --filters Name=instance-type,Values=m6i.largeYou should see: The Region is listed on the MGN endpoints page, and the command returns the instance types you plan to use. - 2
Build the target VPC
Where: Amazon VPC console in the target Region: Your VPCs > Create VPCCreate the VPC, subnets, security groups and routing for production, plus a separate subnet for test launches and a staging subnet for the MGN replication servers. The staging subnet needs outbound access to MGN and the Amazon EC2 endpoint over TCP 443, through an internet gateway with public IPs or a NAT gateway.
You should see: The VPC shows production, test and staging subnets, each with a route table you have checked. - 3
Check quotas
Where: Service Quotas console in the target Region: AWS services > search for Application Migration ServiceThe default quota is 150 active source servers per Region, which you can raise through Service Quotas. A single job can contain up to 200 source servers. Request an increase before the first wave if your estate is larger.
You should see: The active source servers quota shows a value at least as large as your biggest concurrent wave. - 4
Decide on tracking
Where: Your Migration wave plan templateAWS Migration Hub stopped accepting new customers on 7 November 2025. Existing customers can keep using it. AWS recommends AWS Transform for new portfolio discovery and wave planning; you can also track waves in MGN itself.
You should see: The wave plan names the tool you will use to track each server's state.
3Initialise MGN and set replication defaults3 steps
- 1
Initialise the service
Where: AWS Management Console > Region selector > your target Region > search "MGN" > AWS Transform MGN > Get started. Or a terminal with the AWS CLIChoose Get started in the console, or run the CLI command below. This creates the service roles MGN needs. The full click path is in install the AWS Replication Agent, step 1.
aws mgn initialize-service --region ap-southeast-2You should see: The console shows the replication settings template form (first run), and the Source servers page is available in the navigation. - 2
Set the replication template
Where: AWS Transform MGN console: the replication settings template form shown at Get started (later, the replication template page in the console navigation, Edit)Select the Staging area subnet, the Replication server instance type (t3.small by default), the EBS volume type (gp3 by default) and the encryption key. Keep Always use AWS Transform MGN security group ticked. Under Data routing and throttling, choose Use private IP if data will flow over a private connection (Site-to-Site VPN or Direct Connect), and Throttle bandwidth if the source link is shared. Choose Create template.
You should see: The replication template is saved, and new source servers inherit these settings. - 3
Open the network path
Where: Your on-premises firewall or proxy, and the security groups on the staging subnetAllow outbound TCP 443 from each source server to the MGN endpoint (
https://mgn.<region>.amazonaws.com) and the S3 buckets AWS lists, and TCP 1500 from each source server to the replication servers in the staging subnet. If you cannot open the default endpoints, use VPC endpoints and the installer's--endpointand--s3-endpointoptions.Test-NetConnection mgn.ap-southeast-2.amazonaws.com -Port 443You should see: Test-NetConnection reports TcpTestSucceeded : True from a source server.
4Install the AWS Replication Agent4 steps
Generate temporary credentials for the installation (an IAM role with the MGN agent installation policy), then install the agent on each source server. Agent-based replication is AWS's recommended method; agentless vCenter replication is no longer available for new deployments. The AWS Replication Agent how-to has every click.
- 1
Generate temporary credentials
Where: A terminal on your admin PC with the AWS CLI signed in to the target account (install the AWS CLI)Assume the agent installation role and copy AccessKeyId, SecretAccessKey and SessionToken from the output. AWS notes these credentials expire after one hour.
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MGN_Agent_Installation_Role --role-session-name mgn_installation_session_roleYou should see: JSON with a Credentials block containing AccessKeyId, SecretAccessKey, SessionToken and Expiration. - 2
Linux servers
Where: Linux source server, terminal as a user with sudoDownload the installer for your Region and run it with root privileges. Pass credentials through environment variables so they do not appear in the process list.
--no-promptreplicates all disks.wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/latest/linux/aws-replication-installer-init export AWS_ACCESS_KEY_ID=<access-key-id> export AWS_SECRET_ACCESS_KEY=<secret-access-key> export AWS_SESSION_TOKEN=<session-token> chmod +x aws-replication-installer-init sudo -E ./aws-replication-installer-init --region ap-southeast-2 --no-promptYou should see: The installer confirms the disks were identified, installs the agent and prints the source server ID. - 3
Windows servers
Where: Windows source server: right-click Start > Windows PowerShell (Admin). Optionally generate the command first in AWS Transform MGN console > Source servers > Add serverDownload
AwsReplicationWindowsInstaller.exefor your Region and run it as Administrator. AWS recommends PowerShell over Command Prompt because pasting the secret key in Command Prompt causes signature errors. Enter the Region, access key ID, secret access key and session token when prompted, then press Enter to replicate all disks.Invoke-WebRequest -Uri "https://aws-application-migration-service-ap-southeast-2.s3.ap-southeast-2.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" -OutFile .\AwsReplicationWindowsInstaller.exe .\AwsReplicationWindowsInstaller.exeYou should see: The installer identifies the disks, installs the agent and reports the source server ID. - 4
Confirm the server appears
Where: AWS Transform MGN console > Source servers, or a terminal with the AWS CLIFind the server by hostname and wait while it completes initial sync.
aws mgn describe-source-servers --region ap-southeast-2 --query "items[].{id:sourceServerID,host:sourceProperties.identificationHints.hostname,state:dataReplicationInfo.dataReplicationState}"You should see: The server is listed and moves through initial sync until Migration lifecycle shows Ready for testing and Data replication status shows Healthy.
5Configure launch settings4 steps
- 1
Review the general launch settings
Where: AWS Transform MGN console > Source servers > select the server name > Launch settings tab > General launch settings > EditChoose Instance type right-sizing (it overrides the instance type in the EC2 launch template), Start instance upon launch, Copy private IP and Transfer server tags. To set defaults for servers you add later, use Launch template in the left navigation and choose Edit.
You should see: The Launch settings tab shows your choices. AWS notes that changes apply only to test or cutover instances launched after the change. - 2
Review the EC2 launch template
Where: Same Launch settings tab > EC2 launch template > ModifyFor each server set the instance type, subnet, security groups, private IP, IAM instance profile and tags. Use separate subnets for test and cutover launches, and make sure the version you edit is the one MGN will use.
You should see: The EC2 launch template shows the subnet, security groups and instance type you chose. - 3
Licensing
Where: Same Launch settings tab > General launch settings > Edit > OS LicensingChoose whether Windows instances use AWS-provided licences or bring your own licence (BYOL), based on your Microsoft licensing rights. Check AWS and Microsoft licensing guidance before choosing BYOL.
You should see: OS Licensing shows the option your licensing partner confirmed. - 4
Post-launch actions
Where: AWS Transform MGN console: the post-launch settings for the server (or the account post-launch template)Use post-launch actions to install the SSM agent, run validation scripts or remove software that only applies on premises.
You should see: The actions you need are switched on and will run on the next test launch.
6Launch test instances3 steps
- 1
Start the test
Where: AWS Transform MGN console > Source servers > tick the server > Test and Cutover > Launch test instancesCheck that Migration lifecycle is Ready for testing and Data replication status is Healthy, then launch and choose Launch when prompted. Replication continues while the test runs.
aws mgn start-test --source-server-ids s-1234567890abcdef0 --region ap-southeast-2You should see: The Alerts column shows Launched for the server, and a new instance appears in the EC2 console in the test subnet. - 2
Validate
Where: Amazon EC2 console > Instances > the test instance > Connect (Session Manager, RDP or SSH)Connect to the test instance, check services, run application tests and confirm monitoring and backup agents work. Record the results in your test plan.
You should see: All application tests pass on the test instance, or you have a list of fixes to make in the launch settings. - 3
Mark ready for cutover
Where: AWS Transform MGN console > Source servers > tick the server > Test and Cutover > Mark as "Ready for cutover"Mark the server ready and clean up the test instance. Replication keeps running until cutover.
You should see: Migration lifecycle shows Ready for cutover.
7Cut over and finalise3 steps
- 1
Stop the application and launch cutover instances
Where: The source server (stop the application), then AWS Transform MGN console > Source servers > tick the server > Test and Cutover > Launch cutover instancesIn the change window stop application writes on the source, wait for replication lag to reach zero, then launch the cutover instance and choose Launch when prompted.
aws mgn start-cutover --source-server-ids s-1234567890abcdef0 --region ap-southeast-2You should see: Migration lifecycle changes to Cutover in progress and Alerts shows Launched. - 2
Switch traffic
Where: Your DNS host, load balancers and firewallsUpdate DNS, load balancers and firewall rules to point at the new instances, then run acceptance tests.
nslookup app01.contoso.comYou should see: The name resolves to the new instance's IP address and acceptance tests pass. - 3
Finalise the cutover
Where: AWS Transform MGN console > Source servers > tick the server > Test and Cutover > Finalize cutover, or a terminal with the AWS CLIFinalising removes the replication resources within 90 minutes, sends the agent an uninstall command and sets the lifecycle state to CUTOVER. It does not terminate the launched instances. Only run it once you no longer need to roll back. Then archive the server so it no longer counts towards the active quota.
aws mgn finalize-cutover --source-server-id s-1234567890abcdef0 --region ap-southeast-2 aws mgn mark-as-archived --source-server-id s-1234567890abcdef0 --region ap-southeast-2You should see: The server shows a lifecycle state of CUTOVER and, after archiving, no longer appears in the active Source servers list.
8Optimise and decommission2 steps
- 1
Set up operations
Where: AWS Backup console (Backup plans), AWS Systems Manager (Patch Manager), Amazon CloudWatch (Alarms) and AWS Billing (Cost allocation tags)Configure AWS Backup, patching through Systems Manager, CloudWatch alarms and cost allocation tags for every migrated instance.
You should see: Each instance is in a backup plan, shows as a managed node in Systems Manager and has at least one CloudWatch alarm. - 2
Decommission sources
Where: vSphere Client (or Hyper-V Manager), your backup console and the CMDBOnce the rollback window closes, remove source VMs from vCenter and backup jobs, release licences and update the CMDB.
You should see: The source VMs no longer appear in vCenter or backup jobs, and the CMDB lists the EC2 instance IDs.
Expert notes
The detail behind the plan: options compared, and what experienced engineers check first. Tap any item.
Compare all the ways to do this3 options
Rehost with AWS Transform MGN (agent-based)
Medium effortBest for: Most VMware, Hyper-V and physical servers moving to EC2
- The same method for every source, because the AWS Replication Agent runs inside the operating system
- Continuous block-level replication and unlimited test launches that do not stop replication
- An agent on every server, and TCP 1500 as well as 443 to open
- Agentless vCenter replication is no longer available for new deployments
Replatform databases to Amazon RDS or Aurora
Medium effortBest for: Database servers where a managed engine removes patching and backup work
- Native backup and restore, or AWS DMS with change data capture for low downtime
- AWS runs the engine, backups and patching
- Engine features and versions need checking against RDS
- A separate project per database, alongside the server waves
Keep vSphere with Amazon Elastic VMware Service
High effortBest for: Estates that must keep VMware tooling or appliances but want to leave their data centre
- Runs VMware Cloud Foundation on EC2 bare metal in your own VPC
- VMs move without converting them
- You still need VMware Cloud Foundation licensing; confirm the terms with AWS and Broadcom
- You manage the VMware environment yourself or through an AWS Partner
Rehost with AWS Transform MGN unless you have a reason not to: it handles VMware, Hyper-V and physical servers the same way. Move databases to RDS or Aurora as their own waves where a managed engine fits. Consider Amazon EVS only if you must keep vSphere, and compare that against renewing on-premises in the VMware alternatives guide.
Open TCP 1500 as well as 443Saves time
AWS says source servers send replicated data to the replication servers in the staging subnet over TCP 1500, and talk to the MGN endpoint over TCP 443. Teams often open only 443 and the server sits in initial sync.
Ask the firewall team for both rules before installing agents, and allowlist the S3 buckets AWS lists for your Region. Test 443 with Test-NetConnection from one source server first.
Size initial sync against your linkSaves time
Initial sync copies every block of every replicated disk. On a shared internet link this competes with users, and on a slow link it sets the earliest date of each wave.
Add up the disk sizes per wave, start agents well before the cutover date, and set Throttle bandwidth in the replication template during business hours if the link is shared. Use a VPN or Direct Connect with Use private IP for large estates.
Leave out disks you do not needCost lever
Every replicated disk adds staging storage and sync time. Scratch, page file or old backup disks rarely need to move.
Run the installer without --no-prompt and type only the disks to replicate. On Linux the root disk is always replicated. Remember that adding a disk later means rerunning the installer and a full sync of that disk.
Install agents shortly after creating credentialsSaves time
AWS notes the temporary credentials from assume-role expire after one hour. A batch install that takes longer fails part way through.
Generate credentials per batch of servers, or script the install with fresh credentials for each batch. Delete the installation role when all agents are installed.
The MGN connector automates deployment of the replication agent across your inventory from the MGN console, so you do not have to race one-hour credentials with manual installs on each server.
- AWS MGN connectorChecks agent installation prerequisites and installs the replication agent on registered source servers. AWS documents up to 500 source servers per connector.
Right-sizing overrides your instance typeCost lever
AWS says Instance type right-sizing overrides the instance type in the EC2 launch template. Teams set a carefully chosen size in the template and then launch something else.
Decide per server: use right-sizing for a first pass, or turn it off and set the instance type from your assessment. Check the type on the test instance before cutover.
Test as often as you need: it does not stop replicationReduces risk
Test launches run from replicated data while replication continues, so there is no reason to skip a second test after fixing launch settings.
Run at least one full application test per server, fix launch settings, and launch a fresh test (AWS says new settings only apply to newly launched instances). Terminate old test instances so they do not keep running.
Finalise only after the rollback windowReduces risk
Finalising removes the replication resources and uninstalls the agent. After that, a fresh sync is the only way back to a replicating state.
Set a rollback window in the cutover runsheet (for example one business cycle), keep the source powered off but intact, and finalise and archive only after sign-off.
Staging resources keep costing until you finaliseCost lever
Replication servers and staging EBS volumes run for every replicating server. Servers left replicating for weeks after cutover add cost for no benefit.
Move each wave from first sync to cutover in a planned window, finalise and archive servers promptly, and check the staging subnet for leftover replication servers. Check the vendor's current pricing for EC2 and EBS in your Region.
For servers that can take an outage, restoring from backup avoids continuous replication altogether: there are no replication servers or staging volumes running in AWS between the first sync and cutover. The trade-off is downtime, because changes after the last backup are not included.
- Veeam Backup & Replication (Restore to Amazon EC2)Restores VM backups as EC2 instances, and Veeam lists migrating on-premises workloads to the cloud as a use case. Shut down the source and take a final backup before the restore.
Decide on Windows licensing before the first launchCost lever
The OS Licensing choice decides whether AWS bills for Windows licences or you bring your own. Changing your mind later means relaunching instances.
Confirm with your Microsoft licensing partner whether BYOL applies, then set OS Licensing in the launch template before any test launch.
AWS License Manager can change the licence type of an existing Windows Server instance instead of relaunching it. AWS lists instances launched from your own imported VM, which includes servers migrated with MGN, as eligible in both directions.
- AWS License Manager (license type conversion)Converts Windows Server between BYOL and license included. Moving to BYOL needs Windows configured to activate against your own KMS server, and your Microsoft licensing terms still apply.
Plan new IP addresses and hard-coded namesUser impact
Unless you use Copy private IP, instances get new addresses. Applications with IPs in config files, licence servers and firewall rules break after cutover.
Search application config for IP addresses during inventory, decide per server whether to copy the private IP, and update DNS rather than clients wherever possible.
Check it worked, or roll back
Full validation checklist8 checks
Run these before you declare the migration complete. Record the results in the data validation report.
| Check | How to check | What good looks like |
|---|---|---|
| Every server in the wave reached cutover | Run | Every server in the wave shows a launched cutover instance and none is stuck in initial sync or showing a stalled replication state. |
| Instances pass status checks and boot all disks | In the Amazon EC2 console > Instances, check Status checks for each cutover instance, then connect with Session Manager, RDP or SSH and check every replicated disk is mounted. | All status checks pass and every disk in the source inventory is present with the right size. |
| Instance type, network and IP are as planned | Compare each instance's type, subnet, security groups and private IP in the EC2 console with the EC2 launch template you set in the launch step. | Every instance matches the launch template; right-sizing did not pick a type you did not expect. |
| DNS and load balancers point at the new instances | Run | Names resolve to the new addresses and every target is healthy. |
| Applications and integrations pass acceptance tests | Run the tests in your Cutover runsheet with each application owner, including scheduled jobs, outbound email and calls to other systems. | All tests pass and each owner signs off. |
| Operations tooling covers every instance | Check AWS Systems Manager > Fleet Manager for the SSM agent, AWS Backup > Jobs for a completed backup, and CloudWatch > Alarms for each instance. | Each instance is managed by Systems Manager, has a successful backup and has alarms in OK state. |
| Windows licensing is as intended | In the EC2 console > the instance > Details, check the platform details, and on the instance run | Licensing matches the OS Licensing choice (AWS-provided or BYOL) and Windows shows as activated. |
| The source server no longer receives traffic | In vSphere Client check the source VM is powered off, and check your firewall or load balancer logs for any traffic to its old address after cutover. | The source is powered off and no client still connects to the old address. |
Rollback planIf it goes wrong
Roll back if
- A cutover instance fails status checks or will not boot and cannot be fixed in the window
- Acceptance tests fail on a critical application after traffic switches
- Data on the cutover instance is missing changes from before the stop (replication lag was not zero)
- Performance on EC2 is far below the baseline and a different instance type does not fix it
Point of no return
Until you choose Finalize cutover, you can revert: MGN keeps replicating and the source is intact. Finalising removes the replication resources, sends the agent an uninstall command and sets the lifecycle to CUTOVER, so you cannot launch a new cutover from that replication. Once users write to the EC2 instance, rolling back also means copying those changes back to the source. Deleting the source VM is the final point of no return.
- 1
Stop the application on EC2
Where: The cutover instance (Session Manager, RDP or SSH)Stop the application services so no more data is written to the cutover instance, and note anything users wrote after cutover.
You should see: The application no longer accepts requests on EC2. - 2
Revert the cutover in MGN
Where: AWS Transform MGN console > Source servers > tick the server > Test and Cutover > Revert to "ready for cutover"Select Revert and choose whether to delete the cutover instance. Only do this before Finalize cutover.
You should see: Migration lifecycle shows Ready for cutover and replication continues. - 3
Power on the source server
Where: vSphere Client > the VM > Actions > Power > Power OnStart the source VM and its application services in the order your runsheet gives.
You should see: The source VM boots and the application responds on its original address. - 4
Revert DNS and network changes
Where: Your DNS host, load balancers and firewallsPoint records and load balancers back at the source, and reverse firewall changes made for the cutover.
You should see:nslookup app01.contoso.comreturns the source address and application tests pass. - 5
Copy back post-cutover data
Where: The application or database on the cutover instance, before you delete itIf users wrote data on EC2, export it and apply it to the source, or get the data owner to accept the loss in writing.
You should see: The source holds every change made since cutover, or the gap is signed off. - 6
Record what cannot be undone
Where: Your Rollback plan and Cutover runsheetNote that Finalize cutover removes the replication and cannot be reverted, and that a deleted source VM cannot be recovered without a backup. Finalise and decommission only after the rollback window and sign-off.
You should see: Finalise and decommission dates are after the rollback window.
Agree the triggers and who decides before the go / no-go meeting. Use the rollback plan template.
Common problems and fixes6 errors
Agent installer fails to add the aws-replication user to sudoersCause: The Linux installer must add its aws-replication user to sudoers and cannot.
Fix: Run the installer as root or with sudo, and check that sudoers is not locked down by configuration management.
Server stuck in initial syncCause: The source cannot reach the replication servers, MGN endpoint or S3 through the firewall or proxy.
Fix: Open the required outbound access, or use VPC endpoints with the --endpoint and --s3-endpoint installer options.
Installer prompts for an AWS session tokenCause: You are using temporary credentials (access key starting ASIA).
Fix: Provide the session token, or set AWS_SESSION_TOKEN before running the installer.
Replication of an EC2 instance fails to startCause: MGN does not support replicating EC2 instances launched with AWS Marketplace product codes.
Fix: Rebuild the workload on a supported AMI and migrate the data separately.
Newly attached disk is not replicatedCause: MGN replicates only disks identified at installation.
Fix: Rerun the agent installer to add the disk, then wait for its initial sync.
Cannot add more source serversCause: You reached the active source server quota for the Region.
Fix: Archive finished servers or request a quota increase in Service Quotas.
Frequently asked questions
Is AWS Application Migration Service still available?
Yes. AWS renamed it AWS Transform MGN in June 2026. It is the same replication service, and the CLI commands remain under aws mgn.
Is MGN available in my Region?
Check the AWS service endpoints list for your Region. For example, MGN endpoints exist in Asia Pacific (Sydney) ap-southeast-2 and Asia Pacific (Melbourne) ap-southeast-4 in Australia.
Do I need to install an agent on VMware VMs?
Yes for new deployments. AWS says agentless vCenter replication is no longer available for new deployments and recommends agent-based replication.
Does a test launch stop replication?
No. Replication continues during testing, so you can test as many times as needed before cutover.
Should I still use AWS Migration Hub?
Only if you are an existing customer finishing a project. Migration Hub closed to new customers on 7 November 2025 and AWS recommends AWS Transform for new projects.
What about the costs of MGN?
MGN and the EC2, EBS and data transfer resources it uses are billed under AWS pricing. Check the vendor's current pricing pages for the Region you choose.
Official sources
12 official pages this guide is based on
Vendors change limits and features, so confirm details on the source before you rely on them. Last checked 4 Nov 2026.