Amazon Web Services (AWS) recently announced the sunsetting of CloudEndure Migration and AWS Server Migration Service (AWS SMS), both used primarily for accelerating lift-and-shift (re-host) migrations to AWS. AWS Application Migration Service (MGN) simplifies and accelerates your re-host migrations to AWS. You can quickly migrate your virtual, physical, or cloud-based servers to AWS with minimal business disruption.

AWS MGN offers many benefits. You can operate it from the AWS Management Console, control permissions and access using AWS Identity and Access Management (IAM), and use AWS CloudTrail or Amazon CloudWatch for monitoring. We discuss these benefits in more detail in the following sections.

AWS MGN reduces time-intensive, error-prone manual processes by automatically converting your source servers from physical, virtual, or cloud infrastructure to run natively on AWS as Amazon Elastic Compute Cloud (Amazon EC2) instances. This streamlines your migration by letting you use the same automated process for a wide range of applications.

AWS MGN is the next generation of CloudEndure Migration, and it offers key features and operational benefits that aren’t available with CloudEndure Migration. Moreover, it consolidates some of the AWS SMS features. This post will provide details about AWS MGN and why you should embrace it in your cloud migration project.

AWS MGN migration flow

To migrate to AWS, first install the AWS MGN Replication Agent on your source servers (an agentless version is also available). Then, view and define replication settings in the AWS MGN console. AWS MGN uses these settings to create and manage a staging area subnet with lightweight Amazon EC2 instances. These act as replication servers that replicate data between your source servers and AWS.

When you launch test or cutover instances, AWS MGN converts your source servers to boot and run natively on AWS. After confirming that your launched instances are operating properly on AWS, you can decommission your source servers. Then, you can choose to modernize your applications by using AWS services and capabilities.

Architecture visualized. Figure explained further in post.

Figure 1: AWS MGN migration flow

Figure 1 represents how AWS MGN works. After launching test or cutover instances, AWS MGN converts your source servers to boot and run natively on AWS. Then, confirm that your launched instances are operating properly on AWS. Finally, you can decommission your source servers.

In the following sections, we will highlight the advantages of using AWS MGN as your migration tool.

AWS MGN integration with other services

AWS Management Console integration is a significant advantage of using AWS MGN. This provides seamless integration with other AWS services, such as AWS CloudTrail and Amazon CloudWatch for compliance and monitoring, and AWS IAM as the standard AWS authorization and authentication mechanism. AWS MGN lets the service control plane run in the AWS Management Console, within the same region that servers are being migrated to, so that each region is independent.

AWS MGN includes improvements for monitoring

AWS MGN, as an integrated AWS service, uses AWS CloudTrail as the centralized governance, compliance, and operational auditing solution. This lets you audit all actions during migration. Therefore, you can identify which user started a cutover activity or modified a launch template. In addition, you can determine when they installed an AWS MGN agent on a specific server. This makes sure that all of the activities related to AWS MGN Console, API, Command Line Interface (CLI), and SDK will be tracked and audited.

Automation

AWS MGN integrates with Amazon CloudWatch and Amazon EventBridge, so that whenever a Source server launch has completed, a Source server reaches the READY_FOR_TEST lifecycle state. Or, when the data replication state becomes Stalled, you can set up notifications and take action to maintain your migration progress. AWS CLI and SDK are also available for AWS MGN.

User management

AWS MGN provides full permission control via AWS IAM.

Set the appropriate permission level at AWS MGN in multiple ways by using AWS IAM, such as:

  • Set up a user with permissions to install AWS MGN replication agents
  • Allow read-only access to the AWS MGN console to monitor and track the migration
  • Give a user permission only to start the cutover process in a given Region
  • Limit a user to set up only the EC2 launch templates

EC2 launch templates

AWS MGN uses EC2 launch templates to define how to launch a Target machine for the selected source machine. EC2 launch templates have more options than the CloudEndure blueprint. Furthermore, every time a new property is available in EC2 launch templates, it makes it automatically available to be used by AWS MGN.

The EC2 launch template is created automatically for each Source server that is added to AWS MGN, as shown in Figure 2.

Dashboard screenshot. Figure explained further in post.

Figure 2: AWS MGN uses EC2 launch templates

Figure 2 represents the EC2 launch template. You can customize the launch template to change subnet, include or not include a public IP address, change the instance type, add additional EBS volumes, and more. Different EC2 launch templates can be used to define Target machines during the test or cutover phases.

Organize work with AWS MGN tags

AWS MGN can use tags to organize work. On the AWS MGN Migration dashboard, the Tags section shows any tags that have been assigned to the server. Define tags such as cost center, application owner, development or production environment, or even an expected cutover date or change management approval ticket number.

Manage tags dashboard. Figure explained further in post.

Figure 3: AWS MGN can use tags to organize work

Figure 3 shows how AWS MGN uses tags to organize work. You can add or remove tags, and use tags to search and filter your resources to have better visibility into your migration progress, or manage permissions more granularly using AW IAM.

Agentless migration

AWS MGN supports agentless replication from VMware vCenter versions 6.7 and 7.0 to the AWS Cloud. The agentless replication feature is intended for users who want to rehost their applications to AWS but choose not to install the AWS Replication Agent on individual servers due to company policies or technical restrictions. You can perform agentless snapshot replication from your vCenter source environment to AWS by installing the AWS MGN vCenter Client in your vCenter environment. More details on the AWS MGN Agentless migration architecture can be found on the MGN service documentation webpage.

Network access

AWS MGN can work without connection through the public internet, both from the source machine, the staging area, and the target network(s). For customers who prefer having a dedicated network connection or VPN tunnel for the migration, all of the required communication between the AWS MGN replication agents (or AWS MGN vCenter Client) to the AWS console or AWS MGN replication server can be managed by using AWS VPN or AWS Direct Connect.

AWS MGN service limits

AWS MGN service limits have also been increased when comparing to CloudEndure and AWS SMS. For more details, check the AWS MGN endpoints and quotas website.

Conclusion

In this post, we showed you how AWS MGN reduces manual processes, improves user management and monitoring, and accelerates your migration. As CloudEndure Migration and AWS SMS are nearing end-of-life, we recommend using AWS MGN for your migrations. AWS GovCloud (US) and China Regions are excluded from the current end-of-life plans, and CloudEndure Migration will continue to be available in these Regions in 2023.

Further reading

About the authors

Qun Han

Qun is a Sr Technical Account Manager at AWS.

Diego Dalmolin

Diego is a specialist for Migrations & Modernizations focused on accelerating cloud adoption and ensuring customer success leveraging AWS/Cloud for business outcomes. He has experience over 20 years in datacenter migrations, primarily with the infrastructure components, such as, networking, Microsoft, Linux, Virtualization and data. Diego is an AWS migration expert since 2016.