AWS Application Migration Service

The preferred migration tool for BeCloud migration consultants is the AWS Application Migration Service. The AWS Application Migration Service makes it easy to move your applications from physical, virtual or cloud infrastructure without compatibility issues and performance disruption. With this service you can quickly migrate applications with minimal risk of failure. This is our default method for cloud migrations but occasionally we must deviate and adjust.

We recently had a migration job for migrating a legacy application from a legacy blade server solution to the AWS Cloud. The customer wanted to improve security, performance, agility and decrease costs by moving the application to the cloud. But there were a couple of challenges with this migration project. First, the hardware was running an older VMware ESXi environment. Second the server performance and bandwidth were severely limited. The only thing we had going for us was the main database server and corresponding application servers had a maximum of around 30 Gb of used space on each drive. We attempted utilizing the tried-and-true AWS Application management service. We installed the agent on the servers and started the migration process. On the DB server the drives copied quickly, and we thought this would be an easy affair. Turns out that once the drives were copied up the sync process could never finish. We tried everything, but the server performance was lacking, and the final sync could not be finalized. We started looking for alternate migration tools for this use case. We decided that VM Import would be the best way forward.

AWS VM import/export

VM Import/Export the VM Import allows you to bring VM’s including older ESX environments into AWS as ready-to-use instances. VM Import/Export has no additional charges except the standard Amazon EC2 and Amazon S3 charges. For you reference you can also import Vmware workstation, Microsoft Hyper-v and even Citirx Xen virtualization formats.

When you import your Microsoft Windows VM, AWS will provide the Windows Server license for your imported instance.  You cannot import a Windows instance that uses the bring your own license (BYOL) model directly.  Instead, you must import the VM as an AMI which is the method utilized in this article. In our case the on-premises Microsoft license key was reallocated to the on-premises environment.  Make sure you refer to your Microsoft license details for information on how this affects your infrastructure or contact one of our consultants for help with licensing concerns.  

VM Import/Export supports importing Windows and Linux instances into most instance types. In addition, you can run the import instance and import volume API's in North America, South America, Europe/Middle East/Africa, and Asia Pacific regions.

Step One: Prepare your server:

We made sure terminal services was enabled and that we knew the local admin password of the Windows based Database Server.

Step Two: Export the server:

We connected to the ESX server using the virtual infrastructure client. Yes, it was that old of an environment. We had a challenging time finding a copy of the required infrastructure client. We then exported the server into .ovf format by simply going to file export this older version didn’t directly support ova. Reading the documentation, we found that the .ova format was supported but there wasn’t anything on .ovf format in the documentation. There is an ovftool that claims to convert from .ovf to .ova. The .ovf format does export the drives as .vmdk which is also supported by the VIM Import/Export process, so we pressed on with plans to import the .vmdk files directly first, and if that did not work, we would attempt an .ova conversion.

Step Three: Setup the AWS CLI upload to S3:

This upload was straight forward we had no issues. Our architects let this run over night and when we came in the next morning the files had successfully uploaded to the S3 bucket. The only issue here looking back is to make sure your IAM role used for the AWS CLI has the necessary rights to create roles as well as S3 permissions. You will need this role creation capability later.

Step Four: Setup Required permissions:

This document https://docs.aws.amazon.com/vm-import/latest/userguide/required-permissions.html is a professionally written guide for how to set up the permissions for the required VM import role.

Step Five: Perform image import:

This document https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html in our case our format was vmdk instead of ova. On this step we had some issues with mistyping the S3Key that caused a clienterror:disk validation failed error. Once we corrected the syntax error in the containers.json file the image import process completed successfully.

Step Six: Monitor import task:

We utilized the aws ec2 describe-import-image-tasks --import-task-ids import-ami-youramiinstancenumber. If you are importing multiple windows disks, make sure that the boot drive device name is “/dev/sda1” *Note this could also be changed later if needed.

Step Seven: Build EC2 from resulting AMI 

On first attempt the server did not boot. But after a reboot the server started successfully, and we logged into the instance using the local admin account.

Conclusion:

We still prefer the AWS Application Migration Service using the service agent because when it works it is a seamless process. This VM import/export is another migration tool that works well especially if the agent does not work and/or you have legacy ESX infrastructure. Sometimes, we also prefer the VM import/export option over the Application Migration agent-less option. If you are planning or performing a migration, please don't hesitate to contact us for assistance.