Migrating Virtual Machines from AWS to GCP using M2VM

Published in

Globant

12 min readDec 28, 2023

In this article, I will show you how to migrate virtual machines from Amazon Web Services (AWS) to Google Cloud Platform (GCP) with the M2VM tool. Throughout this guide, we will cover essential aspects of the migration process. We will begin by discussing the importance of proper preparation, including workload assessment and establishing a solid migration strategy. Next, we will explore the configuration of M2VM, ensuring that the tool is properly set up to initiate the migration process effectively. If you need to have the AWS and GCP environments interconnected through HA VPN, you can see the first part of this article (HA VPN Connectivity Between GCP and AWS).

Once the groundwork is laid out, we will dive into the core migration process using M2VM. We will discuss techniques to minimize downtime, monitor the migration progress, and handle any potential challenges that may arise during the migration. By following these best practices, businesses can ensure a smooth and efficient migration from AWS to GCP.

You can also use M2VM to migrate virtual machines from an on-premise environment (VMware) to GCP.

Preparation

Proper preparation is essential for a successful migration from Amazon Web Services (AWS) to Google Cloud Platform (GCP) using M2VM. This section emphasizes the importance of thorough preparation, including workload assessment and establishing a solid migration strategy. By investing time and effort into these crucial steps, businesses can minimize risks, optimize resources, and ensure a smooth migration process.

Workload assessment

Before initiating the migration process, it is crucial to conduct a thorough assessment of your workloads hosted in AWS. This involves understanding the architecture, dependencies, and performance requirements of each workload. By assessing the workloads, you can determine their suitability for migration, identify potential challenges, and plan accordingly.

Dependency analysis

During the assessment, it is essential to identify the dependencies between different workloads and resources. This includes examining network connections, database dependencies, and any other interrelated components. Understanding these dependencies is vital for planning the migration sequence and ensuring a seamless transition without disrupting critical business processes.

Resource optimization

As part of the preparation phase, consider optimizing your resources to align with the capabilities and services offered by GCP. Evaluate the performance requirements and cost implications of your workloads and make necessary adjustments. This may involve rightsizing instances, leveraging managed services in GCP, or restructuring your architecture to take advantage of GCP’s features.

Migration strategy

Establishing a solid migration strategy is crucial for a smooth transition. Define the objectives, timelines, and milestones of your migration project. Determine the appropriate migration approach, such as a lift-and-shift or re-architecting, based on the specific needs of your workloads. Develop a detailed plan that includes the sequence of migration, resource allocation, and fallback options in case of any unforeseen issues.

Testing and validation

Before migrating your production workloads, conduct thorough testing in a controlled environment. Create a testing plan that covers different scenarios and ensures that the migrated workloads function as expected. This testing phase allows you to identify and address any issues or performance bottlenecks before the final migration.

By prioritizing proper preparation, workload assessment, and establishing a solid migration strategy, businesses can lay a strong foundation for a successful migration from AWS to GCP using M2VM. These steps provide the necessary insights and understanding of your workloads, dependencies, and migration approach, ultimately leading to a smoother and more efficient migration process.

Overview of M2VM

M2VM is a tool that allows businesses to migrate virtual machines (VMs) from one cloud provider or on-premise environment to GCP. M2VM works by creating a replica of the source VM in the target cloud, transferring data from the source VM to the replica, and then synchronizing the data between the two VMs. This allows the target VM to be an exact copy of the source VM. This allows businesses to seamlessly migrate their workloads from one cloud or an on-premise environment (VMware only) to GCP with minimal downtime and disruption.

Architecture diagram

This guide will show you how to configure M2VM and migrate from an AWS environment to GCP. In our case, it will be a migration from AWS to GCP environment as follows:

Configuring M2VM Tool and Migrating VMs Between AWS and GCP

Now, we will detail the process of migrating Virtual Machines (VMs) from AWS to GCP) using the M2VM tool. This step-by-step guide will show you how to seamlessly transition your workloads between both cloud providers. From tool configuration to the actual migration, each phase is meticulously outlined, offering a clear and comprehensive pathway for a successful VM migration.

Create AWS migration user

This code snippet represents an AWS Identity and Access Management (IAM) policy specifically designed to grant necessary permissions to the M2VM tool during the process of virtual machine migration. Here’s an explanation of each section:

“Effect”: “Allow”: Indicates that the policy allows the specified actions.
“Action”: Lists the permitted actions, including operations related to describing EC2 instances, volumes, instance types, snapshots, creating tags, creating snapshots, and stopping instances. Additionally, it includes actions related to EBS (Elastic Block Store) snapshot management, such as listing snapshot blocks, listing changed blocks, getting snapshot blocks, deleting snapshots, and deleting tags.
“Resource”: “*”: Indicates that these actions are allowed on all resources within the account.
“Condition”: Defines additional conditions that must be met to allow certain actions.
“StringEquals”: Specifies that string comparisons should be made.
“aws:ResourceTag/m2vm-resource”: “snapshot”: Condition specifying that EBS-related actions are only permitted on resources tagged with “m2vm-resource” having the value “snapshot”. This helps restrict actions to specific resources identified by this tag.

This IAM policy provides the necessary permissions for M2VM to perform operations related to snapshot migration and EC2 instance stopping, ensuring a secure and controlled migration process.

Next, create a policy using the provided JSON in the AWS Console: IAM -> Policies -> Create policy -> JSON tab -> Paste JSON -> Review and Name -> Create policy. Create a policy using the following JSON:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeVolumes",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeSnapshots",
                "ec2:CreateTags",
                "ec2:CreateSnapshots",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ebs:ListSnapshotBlocks",
                "ebs:ListChangedBlocks",
                "ebs:GetSnapshotBlock",
                "ec2:DeleteSnapshot",
                "ec2:DeleteTags"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/m2vm-resource": "snapshot"
                }
            }
        }
    ]
}

Review the policy:

Create an IAM user

To implement the previously defined IAM policy effectively, it’s essential to create a dedicated user to whom this policy will be assigned. This user-policy association ensures controlled access and adherence to the specified permissions during the migration process. Let’s delve into the straightforward process of creating a user and linking the policy.

First, create the user:

Attach the previously created policy:

Store the access key ID and secret access key generated during this step for use at the time of the migration tool configuration.

Configuration for Migrate to Virtual Machines (M2VM)

The Migrate to Virtual Machines (M2VM) tool is paramount for a seamless transition from AWS to GCP. In this section, we’ll guide you through the essential steps to set up M2VM to transfer your virtual machines with precision and efficiency.

Enable Migrate to Virtual Machines API in GCP Console. Go to the navigation menu -> APIs & Services -> Library -> Search for “Migrate to Virtual Machines API” -> Enable:

Add the AWS source:

Documentation: Migrate to Virtual Machines from AWS source | Google Cloud.

Enter a name for the migration source, choose the region in both GCP (destination) and AWS (source), use the previously saved access and secret keys, and click CREATE:

If in the source environment in AWS, there are many virtual machines, we can use tags in the source so that only these VMs with tags are seen in M2VM like this:

Wait (up to 15 minutes, but it is usually less) until the source status is indicated as Active:

Test the Migration

For our migration test, we will use a basic environment where I have a single server with WordPress installed. However, in real environments, we will have a greater number of servers, applications, and dependencies that must be previously identified and evaluated to carry out adequate migration planning. Still, the procedure to migrate one or more is almost the same.

Before planning the migration, it is necessary to validate if the source operating systems are supported by the migration tool (M2VM); otherwise, the migration will fail. In the AWS source environment, we have a VM with WordPress already installed, which will be migrated to the GCP environment:

By checking the page published on the public IP address, we can validate that the server is running:

Now we will go to the GCP environment, from where we will be able to visualize the virtual machines available to migrate:

The migration process for an individual source VM unfolds in the following stages:

Onboard: Select the VMs to migrate and click on “ADD MIGRATIONS”:

2. Replicate: From the MIGRATIONS tab, select the VM and start the data replication from the source VM:

3. Configure VM target settings: Click on “EDIT TARGET DETAILS” and adjust settings for the migrated VM, including the project, instance type, memory, network, and more:

4. (Optional) Test-clone: Generate a duplicate of the source VM using the replication data and perform testing on GCP.

5. Cut-over: Transition to the source VM. This procedure involves halting the source VM, conducting a final replication, and generating the production instance based on the source VM. it is necessary to wait until the replica is in the Active (Idle) state to perform the Cut-Over:

Confirm Cut-Over:

After executing the Cut-Over, we can check in the source environment that the VM shuts down; this is part of the Cut-Over process:

Then, the snapshot is taken with the most recent data:

The snapshot is replicated at the destination (GCP), and the instance is created at the destination with the latest data:

You can see the details of the migration process at “SHOW MIGRATION DETAILS” link:

If it is necessary to do a rollback, you can cancel the Cut-Over process and turn on the source machine, which was just turned off but keeps the last data. Otherwise, you can wait until the migration process is finished.

Please note that during the Cut-Over process, there will be no service as the source server is down, and the migrated server will be up only when the migration process has finished.

If the migration is completed, the migration console should look like this:

When checking in the VM Instances console, the migrated VM should already be up and running:

VM migration status — Destination environment (GCP — M2VM)

Note: Do not forget to review the firewall rules necessary for the publication of the service or application to be migrated.

We can validate that the server was successfully migrated and the service is up and running again:

Public IP — WordPress page in target environment

6. Finalize: After a successful cut-over operation, tidy up all resources used during the migration process. Finalizing deletes all replication data and all other storage resources associated with a migrated VM.

Click on MIGRATION and then on “Finalize Replication”:

After the process finishes and is in Finalized status, we can clean up those migrations that have been completed. For this, we have to do the following: select the migration(s) to be cleaned up, and after selecting them, click on the “DELETE” button. This will only be deleted in the migration console (M2VM), but it will not delete the source VM (AWS), as it is only powered off.

The removal of the source VM will be manual and at the discretion of those in charge of the migration process:

It is a best practice to always perform a Test-clone in an isolated environment before performing the Cut-Over to check the behavior of the VM on the target (GCP) without affecting the service on the source machine.

The migration process for groups uses groups to perform bulk migration tasks on multiple VMs simultaneously. Groups streamline the process of planning and migrating multiple VMs so that you can perform migration in batches; for more information, visit the official documentation.

Best Practices For Migrations With M2VM

Here are some best practices for migrating workloads with M2VM:

Plan ahead: Plan your migration carefully before you start. Identify which workloads you want to migrate and which resources they depend on. Make sure that you have the necessary resources and expertise to complete the migration successfully.
Test before you migrate: Test your migration process in a test environment before you migrate your production workloads. This will help you identify any potential issues or problems and allow you to fix them before you migrate your production workloads.
Use a staging environment: Use a staging environment to stage your migration. A staging environment is a replica of your production environment where you can test your migration process and ensure that it works as expected before you migrate your production workloads.
Monitor the migration: Monitor the migration process closely to detect any issues. Use monitoring tools like Amazon CloudWatch or Google Cloud Monitoring to monitor the migration and alert you in case of any issues.
Have a rollback plan: Have a rollback plan in case the migration fails or causes unexpected issues. This allows you to roll back to the previous state and minimize the impact of the migration failure.

By following these best practices, you can ensure that your migration process with M2VM is successful and minimizes downtime and disruption to your production workloads.

Conclusion

In this series of articles, the ultimate goal was to have the AWS and GCP environments interconnected with each other to have a multi-cloud environment where we can migrate virtual machines from AWS to GCP. In the first part, we performed the interconnection of the AWS and GCP environments through an HA VPN. In the second part, we configured and used the M2VM virtual machine migration tool to perform the migration process.

By following recommended best practices, we can perform a VM migration process where enterprises can minimize the downtime to perform it. M2VM’s potential lies in its ability to facilitate the migration of virtualized workloads with a very intuitive graphical interface, allowing enterprises to take advantage of the advanced capabilities and scalability offered by GCP.

Migrating workloads from AWS to GCP with M2VM requires detailed planning, step-by-step execution as recommended in the product documentation, and adherence to recommended security best practices. By following the steps described in this article, enterprises can migrate from AWS and use the full potential and experience of GCP.