Written by Maxime Roth Fessler, DevOps & Backend Developer at TrackIt
Organizations running workloads on VMware may choose to migrate certain virtual machines to Amazon EC2 to reduce reliance on on-premises infrastructure, lower licensing costs, or integrate more deeply with native AWS services. When this type of migration is required, making the process efficient, secure, and repeatable becomes critical. Manual approaches can introduce delays and inconsistencies, particularly at scale. Infrastructure as Code (IaC) enables automation and standardization across environments.
The following sections outline two migration paths:
- Manual Image-Based Migration: Exporting the VMware VM to a raw disk image, importing it into AWS as a custom AMI, and provisioning the EC2 instance using Terraform.
- AWS Application Migration Service (MGN): Using MGN to handle continuous block-level replication from the source VMware environment and performing an orchestrated cutover to EC2.
These two approaches offer practical options for handling a range of migration scenarios—from isolated workloads to scalable pipelines. Each method supports building a repeatable, cloud-ready process, depending on the level of control or automation required.
Contents
Choosing Between VM Import/Export and AWS MGN
Migration requirements vary significantly, and selecting the appropriate approach depends on the specific use case. The VM Import/Export method is well-suited for scenarios involving a small number of highly customized virtual machines, where full control over the disk image or the creation of a reusable AMI catalog is important. This method offers transparency and precision throughout the migration process.
In contrast, AWS Application Migration Service (MGN) is designed for large-scale lift-and-shift projects where minimizing downtime, reducing manual effort, and streamlining replication are key priorities. It is particularly effective when migrating dynamic systems with frequent data changes or configuration drift, where image-based workflows may not be practical.
Understanding the trade-offs between these approaches helps ensure the chosen method aligns with both operational goals and technical requirements.
Prerequisites and Environment Setup
Before starting the migration, access to the VMware hypervisor hosting the virtual machine is required. This may include environments such as vSphere, ESXi, or VMware Workstation, where the VM and its virtual disk can be exported.
On the AWS side, access to the AWS Management Console is necessary to create the required resources and manage IAM permissions. Additionally, ensure that both Terraform and the AWS CLI are installed and properly configured on the local machine or development environment.
With the tooling and permissions in place, the environment is ready for preparing and migrating the virtual machine to Amazon EC2.
Migrating with a Raw Image: Full Control with VM Import/Export
This migration approach involves converting a VMware virtual machine into a raw disk image and importing it into AWS using EC2 VM Import/Export. It provides full control over the virtual machine image, enabling preparation and customization prior to upload.
Once converted, the image is uploaded to an Amazon S3 bucket and registered as a custom Amazon Machine Image (AMI) using the AWS CLI. EC2 instances can then be launched from the AMI and managed through Terraform alongside other infrastructure resources.
Although this method requires more manual effort upfront, it offers a high degree of flexibility and visibility, making it well-suited for targeted workloads or use cases that involve building reusable AMI catalogs.
Prerequisites For Preparing a Raw Disk Image
Before uploading a raw disk image to AWS, the virtual machine must be properly configured for operation in a cloud environment. A provisioning agent such as cloud-init should be installed to automate first-boot tasks, including configuring SSH access, setting the hostname, and enabling networking.
The default user account must have a valid shell, appropriate login permissions, and a correctly configured home directory. SSH access should be enabled and secured using public key authentication.
The disk layout should follow a standard partitioning scheme, ideally using the ext4 filesystem. Complex setups—such as encrypted volumes, software RAID, or unsupported logical volume configurations—should be avoided to reduce the risk of boot failures in EC2. The image must include kernel modules and drivers required for virtualized EC2 hardware, particularly virtio and NVMe.
The root filesystem should be directly accessible. If logical volume managers (LVM) are used, compatibility with EC2 must be explicitly configured and tested, as unsupported LVM setups can prevent the instance from booting correctly.
Once the virtual machine is prepared, it must be converted to a raw disk image, the format required by AWS VM Import/Export. Since VMware exports disk images in VMDK format, a conversion step is necessary. The following command using qemu-img performs the conversion:
| qemu-img convert -f vmdk input.vmdk -O raw output.raw |
Ensure that qemu-img is installed (typically available via the qemu-utils package on most Linux distributions), and run the conversion on a system with sufficient disk space to accommodate large image files. As a final step, remove any temporary mounts, loop devices, or environment-specific metadata that could cause issues when the image is deployed to EC2.
Preparing the IaC Configuration
After converting and preparing the virtual machine image, the next step involves provisioning the required infrastructure using Terraform. Begin by cloning the Terraform repository provided for this project.
Within the repository, a sample.tfvars file provides a reference for the input variables needed. Use this file as a guide to create a custom terraform.tfvars file, populating it with environment-specific values such as the AMI name, instance type, VPC configuration, and other relevant parameters.
The raw disk image should be placed in the root directory of the Terraform project to ensure it can be located and uploaded to the appropriate Amazon S3 bucket during execution.
With the configuration files in place, run the terraform init command to initialize the working directory and download the required provider plugins. This initialization step sets the foundation for deploying the custom virtual machine image to Amazon EC2 using Infrastructure as Code.
Deploying The Stack
To begin deployment, run the following command to generate an execution plan:
| terraform plan -out=”plan.out” |
Then apply the plan using:
| terraform apply “plan.out” |
During this phase, Terraform will trigger the import of the raw image into AWS as a custom AMI. The progress of the import task can be monitored using the AWS CLI:
| aws ec2 describe-import-image-tasks –import-task-ids <your_id> |
Continue polling this command until the import completes and an AMI ID becomes available.
Once the AMI has been successfully created, update the Terraform variables by setting deploy_vm = true and assigning the new AMI ID to the vm_custom_ami_id field in the terraform.tfvars file. Then re-run the plan and apply steps:
| terraform plan -out=”plan.out”terraform apply “plan.out” |
This will provision an EC2 instance based on the custom virtual machine image.
While this Terraform configuration provides a functional starting point for automating the deployment of a raw VM image to EC2, it is intended as a baseline. Adjustments may be necessary depending on factors such as network architecture, security policies, tagging requirements, or AMI lifecycle management practices. Reviewing and modifying the code to suit specific project or organizational needs is recommended. Treat this configuration as a foundation that can be iterated on, not a final implementation.
Migrating with AWS MGN: Automated Replication to EC2
The second migration approach uses AWS Application Migration Service (MGN), a fully managed solution that automates the lift-and-shift of physical or virtual machines to Amazon EC2. In contrast to the raw image method, MGN continuously replicates the source machine in the background, maintaining near-real-time synchronization until the final cutover is initiated.
This approach is particularly effective for minimizing downtime and supporting dynamic workloads with frequent changes. AWS MGN automatically adjusts machine configurations for compatibility with EC2 by updating drivers, network settings, and instance types—eliminating the need for manual reconfiguration.
The following section outlines how to use AWS MGN with the AWS CLI to initiate replication, configure launch settings, and perform the final cutover to EC2. This method provides a streamlined alternative for scenarios where direct control over the VM image is not a priority.
Installing the AWS MGN Agent
To initiate replication with AWS Application Migration Service (MGN), the AWS Replication Agent must be installed on the source machine. Begin by creating an IAM role with the managed policy AWSApplicationMigrationAgentInstallationPolicy, which grants the minimum permissions required for the agent to communicate with AWS services.
Next, navigate to the AWS Application Migration Service section in the AWS Management Console and select “Add server.” Follow the setup wizard to specify the operating system (Linux or Windows) and choose whether to replicate all disks or only selected volumes. Excluding non-essential or temporary disks can help reduce replication time and storage requirements.
The agent requires temporary AWS credentials to authenticate. These credentials can be generated using the AWS CLI by assuming the previously created IAM role:
| aws sts assume-role \ –role-arn arn:aws:iam::your_account_id:role/your_role_name \ –role-session-name ReplicationAgentSession |
The response will return temporary credentials (AccessKeyId, SecretAccessKey, and SessionToken). These values should be entered into the corresponding fields on the “Add server” page in the AWS Console to authorize the agent.
After authentication, download and install the agent as instructed. Once installed, the server will appear in the MGN console and begin background replication to AWS, synchronizing data in near real time in preparation for launch and cutover.
Testing and Cutover with AWS MGN
After initial replication is complete and the machine’s status in the AWS MGN console updates to “Ready for testing,” a test launch can be initiated. This launches a temporary EC2 instance in an isolated environment based on the replicated image. The test instance allows validation of the operating system boot process, service availability, and network accessibility (e.g., SSH or RDP). This step helps confirm the integrity of the root volume and the correct functioning of cloud-specific components such as ENIs and drivers.
Once the test environment behaves as expected, the test can be marked as successful in the MGN console.
When the final migration is ready, initiate a cutover launch. This deploys the production EC2 instance with the desired configuration and stops further replication. Prior to cutover, it is important to verify data integrity, validate application functionality, and confirm post-boot configurations.
Launch templates can be customized in advance to specify instance type, VPC/subnet, security groups, and other parameters to ensure compatibility with the target environment. After cutover validation, the source system can be decommissioned, and the new EC2 instance managed as part of the production infrastructure.
Post-Migration: Infrastructure Management Best Practices
Once workloads have been successfully migrated and are running in Amazon EC2, the focus shifts to ongoing operations and maintainability. Extending Infrastructure as Code (IaC) practices beyond the migration phase can help ensure consistency, scalability, and traceability.
Terraform can be used to manage the full lifecycle of infrastructure resources, including auto-scaling groups, CloudWatch alarms, and backup policies configured through AWS Backup. For environments migrated using AWS MGN, consider reverse-engineering the deployed EC2 instances into Terraform configurations to enable version control and future automation.
Conclusion
Migrating virtual machines from VMware to Amazon EC2 presents both technical and operational challenges, but with the appropriate tools and methodologies, the process can be made efficient and repeatable. The VM Import/Export method offers flexibility and granular control, while AWS Application Migration Service (MGN) provides a streamlined, fully managed alternative with continuous replication and minimal downtime.
Selecting the right approach depends on specific requirements such as workload complexity, customization needs, and operational scale. Incorporating automation—whether through the AWS CLI or Infrastructure as Code solutions like Terraform—enhances consistency, reduces manual effort, and establishes a strong foundation for ongoing cloud operations.. A forthcoming article will explore the technical implementation in detail through a step-by-step, hands-on guide.
About TrackIt
TrackIt is an international AWS cloud consulting, systems integration, and software development firm headquartered in Marina del Rey, CA.
We have built our reputation on helping media companies architect and implement cost-effective, reliable, and scalable Media & Entertainment workflows in the cloud. These include streaming and on-demand video solutions, media asset management, and archiving, incorporating the latest AI technology to build bespoke media solutions tailored to customer requirements.
Cloud-native software development is at the foundation of what we do. We specialize in Application Modernization, Containerization, Infrastructure as Code and event-driven serverless architectures by leveraging the latest AWS services. Along with our Managed Services offerings which provide 24/7 cloud infrastructure maintenance and support, we are able to provide complete solutions for the media industry.