Skip to main content
By Ruben Zhang
Senior Cloud Solutions Architect

Migrating your existing workloads to cloud can be a daunting task and requires careful planning, skillful resources, and meticulous execution. In order to make cloud migration smoother, AWS has built proven approaches for migrating any workloads—application, database, storage, physical or virtual servers, or even an entire data center—to AWS from an on-premises environment such as VMware vSphere, Microsoft Hyper-V, or other public cloud like Microsoft Azure.

ECS Common Cloud Framework grounded in a commitment to people, process, and partnerships provides a structured mechanism for every step of your cloud adoption journey. Multi-server migration is a key component of this framework. To get a better understanding of this component, we will run through an Azure virtual machine to AWS migration process.

Multi-Server Migration Elements

Multi-server migration typically consists of two major elements: AWS migration tools and migration workloads. AWS migration tools help cloud practitioners discover, replicate, and deploy migration workloads.

AWS migration tools: For migrating servers, the migration tools consist of Server Migration Services (SMS) and AWS Migration Hub.

AWS SMS is an agentless service that supports auto-migration of multi-tier, multi-server application stacks to AWS. While server migration is accomplished by replicating a server as an Amazon Machine Image (AMI), application migration replicates all the servers in an application group as AMIs and launches them with CloudFormation templates in a coordinated fashion.

AWS Migration Hub is a central location that allows you to choose the tools that best fit your migration needs, such as AWS Database Migration Service (AWS DMS), AWS SMS, CloudEndure Migration, and a variety of other partner tools. AWS Migration Hub also provides key metrics for individual applications that allows you to track and monitor all cloud migrations from one single location (“hub”). AWS Migration Hub provides an excellent way to simplify an end-to-end solutions migration.

Migration workloads: Let’s assume a two-tier web application that includes one front-end web server and one back-end database server hosted on Microsoft Azure. AWS SMS migrates the web application as a group of servers and launches with CloudFormation template. Migration Hub tracks and monitors the application migration status.

Figure 1: Example of a two-tier web application migration from Microsoft Azure to AWS

Migration Connector

The AWS Migration Connector is the key component that establishes connection between Azure and AWS and acts as a pipeline for server replications. A single AWS SMS Connector appliance can only migrate virtual machines (VMs) under one Azure Subscription and one Azure Region. We use PowerShell scripts, CloudFormation templates, and other DevOps tools to build the CI/CD migration pipeline as illustrated in Figure 2 below.

Figure 2:  Microsoft Azure VMs to AWS EC2 instances migration process

Migration Walkthrough

The following sections provide a walkthrough of the steps required to use AWS SMS and AWS Migration Hub.

Step One: Download and Validate the Migration Connector Installation Script

AWS SMS provides a downloadable PowerShell script to deploy the connector in the Azure environment. The script is cryptographically signed by AWS. The script and hash files can also be downloaded from a publicly accessible AWS S3 bucket or through AWS Management console.

To download the scripts from the AWS Management console, log in and go to Server Migration Service, then choose download PowerShell setup script for Azure environment. The installation script and two hash files are:

  • aws-sms-azure-setup.ps1
  • aws-sms-azure-setup.ps1.md5
  • aws-sms-azure-setup.ps1.sha256

To validate the integrity and cryptographic signature of the Script File, run the following PowerShell cmdlets and compare the outputs with the downloaded hash files value.

  • Get-FileHash .\aws-sms-azure-setup.ps1 -Algorithm MD5
  • Get-AuthenticodeSignature .\ | Select *

Step Two: Deploy the Migration Connector in Azure

AWS SMS Connector is deployed in Azure as a virtual appliance. To simplify the process, create a PowerShell script (an example in Figure 3), and save it to the same folder where the Connector installation script is saved.

Figure 3: PowerShell scripts to deploy AWS Migration Connector

Run the script and log in to Azure. When completed, one F4 size Linux based VM is created in the subnet as you specified in the PowerShell script. After the provisioning, an on-screen output contains the Object ID of System Assigned Identity and Private IP (Figure 4). This information will be used to register the connector to the AWS SMS service.

Figure 4: Details of the AWS SMS Connector virtual appliance

Step Three: Configure (Register) the Connector

In this demo, the Connector is in the same subnet as the Bastion VM. Its IP address is To configure the Connector, browse from the Bastion VM and follow the on-screen instructions and register the Connector with an IAM user credential. If the IAM user does not have administrator access, it should have ServerMigrationConnector Inline policy attached and configured with additional policies, allowing SMS to access other AWS services and resources, including EC2, S3, and CloudFormation.

Figure 5: Providing IAM user credentials for registering SMS Connector to AWS

After the associated connectivity and authentication checks have passed, the SMS Migration Connector is active and healthy on both the Azure and AWS sides. The homepage of the SMS Connector provides the status of connectivity and the health of the SMS Connector in the Azure environment (Figure 6).

Figure 6: AWS SMS Connector home page

To verify the Migration Connector status in AWS, login to AWS Management Console, choose Server Migration Service, and open the Connectors page (Figure 7).

Figure 7: AWS SMS Connector status and specifications

Step Four: Replicate VMs Using AWS SMS

AWS SMS discovers the Azure VMs from the subscription and region under which the Connector is installed. On the AWS SMS console, start VMs replication by importing the server catalog, creating replication jobs and applications as described below:

  1. Import virtual machines inventory -> Login to AWS SMS, choose Connectors, Import Server Catalog. This will import all Azure VMs to AWS SMS.
  2. Create a replication job -> a replication job replicates a server to create an AMI on AWS. Within the AWS SMS console, select the server(s) to migrate and choose Create replication job. Follow the on-screen instructions to finish the job creation. The time that the initial replication task takes to complete depends on the available bandwidth and the size of the VMs. After the initial seeding replication, network bandwidth is minimized as the scheduled continuous replication only captures incremental changes occurring on the VMs.
  3. Create Applications -> When using AWS SMS, an application is created to group servers together. Within the AWS SMS console, choose Applications, Create new application, then group the servers based on application dependency. When the servers’ replication is completed, the AWS SMS can automatically launch all servers with the CloudFormation template or you can generate the CloudFormation template and launch it manually. Figure 8 shows a web application in which one group of two servers is created.

Figure 8: A SMS Application with one group of two servers

Step Five: Track the Application Migration Progress Using Migration Hub

Migration Hub can track the collective progress of applications migration.

1. Connect AWS SMS to Migration Hub -> navigate to Migration Hub in the AWS Management Console. Under Migrate, Tools, connect SMS so that the migration status sends to Migration Hub (Figure 9)

Figure 9: AWS SMS is connected to Migration Hub

2. Migration Hub Dashboard -> track application replication and migration status by switching to Dashboard. Figure 10 below shows that the web application has two servers completed with initial replication and scheduled incremental replication is in-progress.

Figure 10: Application replication and migration status

Step Six: Launch EC2 Instances

EC2 instances can be launched automatically at the end of the application replications with the CloudFormation template. Alternatively, you can generate the template from the application, then customize, update, and launch as needed. In this demo, we mapped the AMIs with the existing CloudFormation template and built the two-tier web application in AWS (Figure 1 and Figure 2).

This blog shows an example of successfully migrating VMs from Microsoft Azure to AWS. By deploying different Migration Connectors, the same solution can be used to migrate servers and applications from on-premises private cloud such as VMware vSphere and Microsoft SCVMM/Hyper-V, simplifying the multi-server migration process.

At ECS, we use a well-structured and customizable approach for cloud migration using the ECS Common Cloud Framework. This approach can be customized based on the source, target, and other technical requirements to meet your organization’s needs.

Does your organization need guidance on your cloud migration?

Close Menu

© 2023 ECS. All Rights Reserved.