Migrate servers

AWS Transform uses AWS Application Migration Service (Application Migration Service) to rehost your VMware servers to Amazon EC2. The migrate servers workflow guides you through setting up each migration wave, validating your server inventory, deploying replication agents, monitoring data replication, testing migrated instances, and performing final cutover. To read more about it, see What is AWS Application Migration Service? in the Application Migration Service User Guide.

Server migration is organized by waves. Each wave represents a group of servers that are migrated together. For each wave, you complete the following phases:

1. Prerequisites and migration execution defaults

2. Step 1: Set up migration wave

3. Step 2: Validate and confirm inventory

4. Step 3: Deploy replication agents

5. Step 4: Data replication

6. Step 5: Testing

7. Step 6: Cutover

Prerequisites and migration execution defaults

Prerequisites

Before starting rehost migration, ensure you have the following in place:

• Target accounts for migration – The AWS account IDs where you need your servers to be migrated. You can use AWS Transform landing zone or any other tools to set up your infrastructure.

• Network infrastructure in place – VPCs, subnets, and security groups deployed and configured. You can use AWS Transform network migration or any other tools to set up your network infrastructure.

• Inventory file – Prepared with server details, wave assignments, target account information, and Amazon EC2 instance type preferences. You can use AWS Transform migration planning to generate this file.

Important

Before starting rehost migration, verify that you have the networking resources and infrastructure in place to host your servers. You can use AWS Transform landing zone and network migration capabilities or any other tools for that.

Migration execution defaults

Before starting wave execution, you configure default settings that apply to all your target accounts. These defaults define how your Amazon EC2 instances are launched and how the general migration is configured. You can override these defaults at the wave level during wave setup.

Amazon EC2 recommendation preferences

AWS Transform provides Amazon EC2 instance type recommendations based on the utilization specification of your source VMs. You can configure your Amazon EC2 recommendation preferences to control how instance types are selected for your migrated servers.

For more information about generating Amazon EC2 recommendations, see Generating Amazon EC2 recommendations in AWS Migration Hub.

Note

You can modify the suggested Amazon EC2 instance types to include recommendations from the Migration Evaluator, AWS Optimization and Licensing Assessment (OLA), or an AWS Transform assessment job.

Default launch settings

To change default launch settings, go to the Application Migration Service console and apply the changes you want. For more information, see Launch settings in the Application Migration Service User Guide.

Step 1: Set up migration wave

In this phase, AWS Transform prepares the migration wave by configuring the target account, verifying service permissions, setting up resource tags, adding networking data to your inventory, and configuring replication and launch settings.

Migration mode and account configuration

AWS Transform supports two migration modes:

• Single-account migration – All servers in the wave migrate to the same target account configured in your connector.

• Multi-account migration – Servers migrate to different target accounts specified in your inventory file. For multi-account migrations, your inventory file must include an mgn:account-id column with the target account ID for each server.

AWS Transform confirms the target account configuration and verifies that Application Migration Service is initialized in each target account. If Application Migration Service is not yet initialized, AWS Transform provides instructions to complete the initialization. During initialization, Application Migration Service creates the required IAM service roles for replication and launch operations, including cross-account roles for multi-account migrations. To learn more about this requirement, see Initializing Application Migration Service with the console or Initializing Application Migration Service with the API in the Application Migration Service User Guide.

Resource tagging verification

After service permissions are confirmed, AWS Transform verifies that all required resources are properly tagged. The following tags are required:

• Source servers must have tags CreatedBy: AWSTransform and ATWorkspace: <workspace_id>.

• VPCs and subnets must have tags CreatedFor: AWSTransform and ATWorkspace: <workspace_id>. VPCs and subnets created by the AWS Transform network migration agent are automatically tagged with these tags.

If any resources are missing required tags, AWS Transform provides a link to the tagging page where you can apply the missing tags before continuing.

Note

VPCs and subnets created by the AWS Transform network migration agent are automatically tagged. If you set up your own VPCs and subnets, you must manually apply the following tags so that they appear in AWS Transform's list of available subnets:

• Key: CreatedFor Value: AWSTransform

• Key: ATWorkspace Value: workspace-id (find your workspace ID in the AWS Transform web app URL: https://.../workspace/workspace-id/job/job-id)

Add networking data to inventory

AWS Transform adds networking information from your network migration to the inventory file. This step maps your servers to the appropriate target subnets and security groups based on the network configuration generated during the migrate network phase.

Replication and launch settings

To change replication and launch settings, go to the Application Migration Service console and apply the changes you want. For more information, see Replication settings and Launch settings in the Application Migration Service User Guide.

IP assignment strategy

You choose how IP addresses are assigned to your migrated servers:

• Static IP – The source server's IP address is maintained. If CIDR transformation is required, AWS Transform automatically converts the IP address to match the new CIDR.

• Dynamic IP (DHCP) – Each server is assigned a new IP address from the subnet's IP pool.

Note

If you selected the MAP security groups mapping strategy during network migration, only static IP assignment is available. For more details, see Security groups mapping.

Step 2: Validate and confirm inventory

Before loading your server data into Application Migration Service, AWS Transform prepares the inventory file for your review. You can download the file in CSV or XLSX format, review the server configurations, and make changes if needed.

The inventory file includes details such as server names, operating systems, Amazon EC2 instance type recommendations, target subnets, security groups, IP assignments, and licensing options. Required fields include:

• Server information – Server name, VMID, and source specifications.

• Wave assignment – Migration wave grouping.

• Application grouping – Logical application associations.

• Target configuration – Target account, Region, and Amazon EC2 instance type.

• Network configuration – Target subnet and security groups.

You can modify the file to adjust Amazon EC2 configurations, change operating system licensing options (BYOL or License Included), and update tenancy settings.

After you review the inventory, you can either accept it as shown or upload a modified version. AWS Transform then loads the data into Application Migration Service, which creates source server records for each server in the wave.

Note

Do not remove columns or change column headers in the inventory file. AWS Transform requires the original file structure to process the data correctly.

Note

AWS Transform allows one import to a given target AWS account and target AWS Region at a time. If you work on more than one wave simultaneously, or if there is more than one migration job running with the same target account, you must wait for an import to finish before you can perform another import in a different wave or job.

You can control the operating system licensing options (BYOL or License Included) and tenancy by specifying the configuration in the inventory file columns mgn:launch:placement:operating-system-licensing and mgn:launch:placement:tenancy. For more information, see Import parameters in the Application Migration Service User Guide.

Step 3: Deploy replication agents

To begin replicating data from your source servers to AWS, you install the AWS Replication Agent on each source server. AWS Transform offers three installation methods:

• Organization tools – Use your organization's existing deployment tools (such as SCCM, Ansible, or Chef) to install agents across your servers. AWS Transform provides the installation commands with additional parameters for silent installation, including --no-prompt, --aws-access-key-id, --aws-secret-access-key, and --aws-session-token.

• MGN connector – Use an Application Migration Service connector to automate agent installation. The connector connects to source machines over SSH (Linux) or WinRM (Windows) and installs the replication agent automatically. Once configured, a connector can be reused across multiple waves and different target AWS accounts. For more information about the Application Migration Service connector, see Set up the MGN Connector in the Application Migration Service User Guide.

  Note

  Before using the MGN connector with AWS Transform, you must tag the connector's managed instance in AWS Systems Manager Fleet Manager with the following tags:

  • Key: CreatedFor Value: AWSTransform

  • Key: ATWorkspace Value: workspace-id

  To tag the managed instance, open the AWS Systems Manager console, navigate to Fleet Manager under Node Tools, choose the managed instance of your MGN connector, and apply the tags above. Find your workspace ID in the AWS Transform web app URL: https://.../workspace/workspace-id/job/job-id.

• Manual installation – Install the agent directly on each source server. This method requires direct access to each server but gives you full control over the installation process.

AWS Transform MGN connector setup

The AWS Transform MGN connector automates the deployment of replication agents to your source servers. The connector is a lightweight client deployed on a dedicated Linux machine in your on-premises environment. It connects to source servers over SSH (Linux) or WinRM (Windows) to install and configure replication agents, eliminating the need to manually coordinate across multiple AWS services.

How the connector works

The connector operates through the following components:

• Connector client – Deployed on a dedicated Linux machine in your environment.

• SSM Agent – Installed on the same machine to enable secure communication with AWS.

• SSM Hybrid Activation – Links the connector machine to AWS Systems Manager for secure command execution.

• Credentials management – Retrieves source server credentials from AWS Secrets Manager.

When you deploy agents, AWS Transform sends an SSM document to the connector machine. The connector then retrieves source server credentials from AWS Secrets Manager, establishes a connection to each source server, validates that the source server meets prerequisites, installs and configures the replication agent, and verifies successful installation.

Connector machine requirements

Requirement	Details
Operating system	Supported Linux operating system. For the full list, see MGN connector prerequisites in the Application Migration Service User Guide.
Network access	Must reach all source servers (Linux over SSH, Windows over WinRM)
Internet connectivity	Outbound HTTPS (443) to AWS endpoints (Systems Manager, Secrets Manager, Application Migration Service)
Disk space	Minimum 200 MB free
Permissions	Root or sudo access

Note

The connector must be installed on a Linux machine, but it can deploy agents to both Linux and Windows source servers.

Setup process

AWS Transform guides you through the following steps to set up the connector:

Step 1: Connector configuration

Provide a name for your connector, or use the auto-generated default name. The connector can be installed on the management account or on a delegated administrator account in Application Migration Service. For multi-account migrations, the connector can deploy agents to servers across member accounts.

Step 2: AWS resource setup

AWS Transform opens a setup page that runs in your browser using your AWS credentials. You must be logged in to the AWS Management Console with either your management account or your delegated administrator account. This must be the same account your AWS Transform target connector is connected to.

The setup page automatically creates the following resources:

• IAM roles (created idempotently — skipped if they already exist):

  • AWSApplicationMigrationConnectorManagementRole – Used during agent installation to access credentials.

  • AWSApplicationMigrationConnectorSharingRole_<ACCOUNT-ID> – Contains permissions for agent installation.

• SSM Hybrid Activation – 30-day expiration period. Links the connector machine to AWS Systems Manager and generates secure activation credentials.

Alternatively, you can download a CloudFormation template from the setup page to deploy the IAM roles yourself.

The setup page generates a one-line installation command with all necessary credentials and configuration.

Important

Keep the setup page open until installation is complete. Closing it will require restarting the process. All credentials exist only in your browser and are not stored by AWS Transform.

Step 3: Connector installation

Install the connector on a Linux machine in your environment:

1. Copy the installation link from the setup page.

2. SSH into your chosen Linux machine.

3. Paste and execute the installation command.

4. Wait for installation to complete (typically 2–3 minutes).

Step 4: Attach source servers

After installation, AWS Transform identifies all source servers that belong to the current wave and automatically attaches them to the Application Migration Service connector.

Step 5: Configure credentials

Provide AWS Secrets Manager ARNs for your source server credentials. AWS Transform offers three credential configuration options:

• Single secret for Linux servers – One shared secret containing SSH keys or username/password for all Linux source servers.

• Single secret for Windows servers – One shared secret containing username and password for all Windows source servers.

• Multiple per-server secrets – Different secrets per server or group of servers. Use this when servers have different credentials. AWS Transform generates a CSV file pre-populated with your server list. You fill in the secret_arn column for each server and upload the completed file.

Note

You can combine the Linux and Windows single-secret options if you have both server types with one shared secret each. The per-server secrets option is mutually exclusive with the single-secret options.

Credential secret format. To read more about it, see MGN connector credentials in the Application Migration Service User Guide:

{
  "WinConnectionProtocol": "HTTPS",
  "WinUserName": "windows_username",
  "WinPassword": "windows_password",
  "LinuxUserName": "linux_username",
  "LinuxPrivateKey": "linux_private_key",
  "LinuxHostKeyValidation": false
}

Agent deployment

Once credentials are configured and verified, AWS Transform deploys replication agents to your source servers. You can deploy to all servers in the current wave or select specific servers.

The deployment process for each server:

1. AWS Transform sends deployment commands to the connector via SSM.

2. The connector retrieves credentials from AWS Secrets Manager.

3. The connector connects to the source server using the configured credentials.

4. The connector validates that the source server meets all prerequisites required to run the replication agent.

5. The connector installs and configures the replication agent.

6. The connector verifies successful installation and connectivity.

You can monitor deployment progress in real-time with per-server status tracking, including the current installation step, elapsed time, and estimated time remaining. If any servers fail, AWS Transform displays the failure reason and offers retry options per server. Successfully deployed servers can proceed independently while failed servers are retried.

Connector reuse and lifecycle

When deploying agents for subsequent waves, you can reuse an existing connector or create a new one. AWS Transform lists all connectors configured in your account, showing the connector name, status (Active or Expired), attached server count, and Hybrid Activation expiry date.

• Active connector – The Hybrid Activation is still valid. AWS Transform verifies IAM roles for the new wave and proceeds to credential configuration. No new Hybrid Activation is needed.

• Expired connector – The SSM Hybrid Activation has expired. Expired activations cannot be renewed. You must select a different connector or create a new one.

SSM Hybrid Activations expire after 30 days. The activation is required only for installing the connector on the Linux machine. Once the connector is installed, you can continue to use it to install replication agents on source servers even after the activation expires. If you need to install the connector on a new machine after the activation has expired, you need to create a new connector through the setup process.

Manual agent installation

For manual installation, you first generate AWS credentials (temporary or permanent) and then install the agent on each source server.

Credential options:

• Temporary credentials (recommended) – Create an IAM role with the AWSApplicationMigrationAgentInstallationPolicy managed policy, then use aws sts assume-role to generate temporary credentials. To read more about it, see Agent installation permissions in the Application Migration Service User Guide.

• Permanent credentials – Create an IAM user with the AWSApplicationMigrationAgentInstallationPolicy managed policy and generate an access key.

Installation steps:

For Linux servers, download and run the installer:

wget -O ./aws-replication-installer-init \
  https://aws-application-migration-service-region.s3.region.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region region --user-provided-id server-identifier

For Windows servers, download and run the appropriate installer using PowerShell as Administrator:

Invoke-WebRequest -Uri "https://aws-application-migration-service-region.s3.region.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" `
  -OutFile "C:\AwsReplicationWindowsInstaller.exe"
C:\AwsReplicationWindowsInstaller.exe --region region --user-provided-id server-identifier

Important

The --user-provided-id parameter is required. Replace server-identifier with the exact value from the mgn:server:user-provided-id column in your inventory file. This identifier links the physical server to its Application Migration Service source server record.

For more information about agent installation, see Linux agent and Windows agent in the Application Migration Service User Guide.

After installation, AWS Transform verifies that all agents are successfully connected by checking that servers show a replication state of INITIATING or INITIAL_SYNC.

Note

AWS Transform does not support Application Migration Service agentless replication. For information about agentless replication, see Agentless replication overview in the Application Migration Service User Guide.

Note

You must install the replication agent on all servers in a wave. Disconnect and archive servers on which you don't install the replication agent. You can use the disconnect-from-service command to disconnect servers, and the mark-as-archived command to archive disconnected servers. The archiving command only works for source servers whose lifecycle state is DISCONNECTED.

For quotas related to replication, see Application Migration Service service quota limits in the Application Migration Service User Guide.

Step 4: Data replication

After the replication agents are installed, data replication begins automatically. AWS Transform uses continuous block-level replication to synchronize data from source servers to AWS.

The replication process consists of two phases:

• Initial sync – A complete copy of the source server data to AWS. Data is stored as EBS snapshots in the target account. Duration depends on data volume and network bandwidth.

• Continuous replication – Ongoing synchronization of changed blocks with minimal impact on source server performance. Maintains an up-to-date copy in AWS.

Replication servers are temporary Amazon EC2 instances deployed in the staging area subnet. They receive replicated data from source servers and are automatically managed by Application Migration Service. To read more about it, see Replication server settings in the Application Migration Service User Guide.

AWS Transform monitors the replication progress and provides status updates, including replication status, replication lag (the time difference between source and replicated data), and bandwidth usage.

During replication, each server progresses through the following states:

• Not ready – The server is undergoing the initial sync process and is not yet ready for testing.

• Ready for testing – The server has been successfully added and data replication has started. Test or cutover instances can now be launched.

Once all servers in the wave have progressed beyond the NOT_READY state, the data replication phase is complete and you can proceed to testing.

You can control replication for individual servers or the entire wave at any time:

• Pause replication – Temporarily pause replication for specific servers or the entire wave.

• Resume replication – Resume previously paused replication.

• Stop replication – Permanently stop replication. Stopped replication can be restarted, but it begins from the initial sync.

Step 5: Testing

After data replication is complete, you can launch test instances to validate your migrated servers before performing the final cutover. To read more about it, see Launch test instances in the Application Migration Service User Guide. AWS Transform supports two testing options:

• Full wave testing – Launch test instances for all servers in the wave.

• Selective testing – Launch test instances for specific servers that you select by providing their user-provided IDs from the inventory file.

AWS Transform launches Amazon EC2 instances from the replicated data and provides the instance IDs so you can connect to and validate the test instances. After testing, you can:

• Proceed to cutover if testing is successful.

• Launch new test instances to retest.

• Terminate test instances and address any issues before retesting.

Step 5b: Mark applications as ready for cutover

After testing is complete and you are satisfied with the results, mark your applications as ready for cutover. AWS Transform reviews the replication status of each application and resolves any replication alerts before allowing you to proceed. Only applications with a clean replication status can be marked for cutover.

Step 6: Cutover

Cutover is the final migration step where your production workloads are moved to AWS. To read more about it, see Launch cutover instances in the Application Migration Service User Guide. Similar to testing, AWS Transform supports full wave cutover or selective cutover for specific servers.

During cutover, AWS Transform launches Amazon EC2 instances from the latest replicated data and provides the instance IDs for each server. After verifying the cutover instances, you finalize the cutover, which stops the ongoing source machine replication.

The cutover process includes the following steps:

1. Launch cutover instances – AWS Transform launches Amazon EC2 instances for the selected servers. You can choose full wave cutover or selective cutover.

2. Verify cutover instances – Connect to the launched instances and verify they are functioning correctly.

3. Finalize cutover – Confirm the cutover to stop source machine replication. You can finalize all servers in the wave or select specific servers. Finalization stops replication agents from sending data, removes replication agents from source servers, and locks the server lifecycle state. This action cannot be easily undone. To read more about it, see Finalize cutover in the Application Migration Service User Guide.

4. Archive source servers (optional) – After finalization, you can mark source servers as archived to free up source server quota in your account.

Important

Finalizing cutover stops the ongoing source machine replication. Make sure you have verified your cutover instances before finalizing.

Note

Downtime occurs between source shutdown and cutover instance availability. Plan your cutover window accordingly.

Server lifecycle states

During migration, each server progresses through the following lifecycle states. To read more about it, see Source server lifecycle in the Application Migration Service User Guide.

• Not ready – The server is undergoing the initial sync process and is not yet ready for testing.

• Ready for testing – Data replication has started and test or cutover instances can be launched.

• Test in progress – A test instance is currently being launched.

• Ready for cutover – The server has been tested and is ready for cutover.

• Cutover in progress – A cutover instance is currently being launched.

• Cutover complete – The server has been cutover. All data has been migrated to the AWS cutover instance.

• Disconnected – The server has been disconnected from Application Migration Service.

You can ask AWS Transform about the status of your servers at any time during the migration. AWS Transform provides an interactive wave status table that displays all relevant server information including migration lifecycle, replication status, and recommended next steps. You can also ask in natural language, for example:

• What is the status of my servers?

• What's the status of my wave?

• What's the status of the step that I'm currently in?

During wave migration, you can ask AWS Transform to update or change the status of individual servers. For example, if 9 out of 10 servers in your wave passed the test phase but one failed, you can allow AWS Transform to continue moving the 9 servers into the next phase while re-running the test on the failed server.

Deployment approvals

Some migration operations require explicit approval before execution. When an operation requires approval, AWS Transform routes the request to authorized approvers through the Approvals tab. Only users with the Admin role in AWS Transform can approve deployment requests. Deployments proceed only after receiving confirmation.