How to Migrate Azure virtual machine workloads to the Google Cloud Platform (GCP)?

35 min readFeb 25, 2024

Reference Architecture

Create an Azure source

Introduction

Migrate to Virtual Machines lets you migrate your Azure virtual machines (VMs) from your Azure account to Compute Engine instances.

Prerequisites for Azure Side.

Enable the VM Migration API on your host project using https://console.cloud.google.com/apis/library/vmmigration.googleapis.com.
Review the supported operating systems that support migrating VMs from an Azure source.
Review Migrating VMs with Migrate to Virtual Machines: Getting started documentation. This document provides insight into the overall structure of Migrate to Virtual Machines, including important concepts and reference information that helps you migrate your workload efficiently and effectively.

Migrate your workload from an Azure source

Before initiating your migration with Azure as a source, set up your Azure environment by completing the following tasks:

Register your app in the Azure portal.
Create a custom role to be accessed by the Migrate to Virtual Machines service.
Assign the custom role to an app.
Create an Azure source using Google Cloud.

Register your app

To register your app, follow these steps:

In the Azure portal, go to the App Registration page, and click New registration.
To add new client credentials, click Add a certificate or secret.
To add a new client secret, click + New client secret and enter a description and expiry date for the client secret.
Click Add.

Your client secret is now ready. Ensure that you copy your client secret value. You will need it later when you set up the source.

Create a custom role

To migrate your Azure workload, create a custom role and assign it to the app you registered in the Register your app step.

To create a custom role, use the following steps:

In the Azure portal, go to the Subscriptions page and select your Azure subscription.
Copy the Subscription ID by clicking on it.
Save following JSON template and replace SUBSCRIPTION_ID with the Subscription ID you copied in

Step 2:

  {
  "properties": {
        "roleName": "Minimum M2VM permissions role",
        "description": "This role contains the bare minimum of Azure IAM permissions to support M2VM flow",
        "assignableScopes": [
              "/subscriptions/<code><var>SUBSCRIPTION_ID</var></code>"
        ],
  "permissions": [
              {
              "actions": [
                    "Microsoft.Resources/subscriptions/resourceGroups/write",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/delete",
                    "Microsoft.Compute/virtualMachines/read",
                    "Microsoft.Compute/virtualMachines/write",
                    "Microsoft.Compute/virtualMachines/deallocate/action",
                    "Microsoft.Compute/disks/read",
                    "Microsoft.Compute/snapshots/delete",
                    "Microsoft.Compute/snapshots/write",
                    "Microsoft.Compute/snapshots/beginGetAccess/action",
                    "Microsoft.Compute/snapshots/read",
                    "Microsoft.Compute/snapshots/endGetAccess/action"
              ],
              "notActions": [],
              "dataActions": [],
              "notDataActions": []
              }
        ]
  }
  }

For more information about the permission details, see permission details.
In the Azure portal, go to the Access control (IAM) page.
To add a custom role, click + Add.
Click Start from JSON and then click Select file to upload the JSON file you created in Step 3.
To review your inputs click Review + Create, and then to create the custom role click Create.

Assign the custom role to an app

To assign a custom role to an app, follow these steps:

In the Azure portal, go to the Access control (IAM) page.
Click + Add and then click Add role assignment.
Search for the custom role you created in Create a custom role by typing m2vm, and select it.
Click Next.
Click + Select members and search for the app name you registered in Register your app and click Select.
To review and assign the custom role to your app, click Review + Assign.

Create an Azure source

After you have registered your app, added your secret, and set its permissions, create an Azure source in the Migrate to Virtual Machines service.

To create an Azure source, follow these steps:

In the Google Cloud console, go to the Migrate to Virtual Machines page.
Select the Sources tab.
From the Add source list, select + Add Azure source.
Enter your source details on the Create Azure source panel.
Caution: You cannot edit the GCP region or Azure location fields after creating your source. If you need to edit these fields, we recommend that you wait 24 hours before revoking the credentials you replaced in order to not interrupt an ongoing replication cycle.
The following table describes the parameters for Azure source details.
ParameterDescriptionName (mandatory)A string that identifies the source. The string must conform to Compute Engine naming conventions. You cannot update this field after creating your source.Google Cloud region (mandatory)The region in Google Cloud that you want to migrate your instances to. You cannot update this field after creating your source.
For more information, see locations documentation.Azure location (mandatory)The region in Azure (for example, centralus) from which you want to migrate VMs. The inventory displayed in the Migrate to Virtual Machines console only includes VMs from this Azure location. You cannot update this field after creating your source.
Note: It is recommended that you choose the region from the drop-down list options, or copy the region from your Azure console JSON View and paste it into the source detail field to avoid typos. If there is a typo in the region, the source doesn’t become active, and you have to create a new source. You can see the status of the source in the console.Subscription ID (mandatory)Part of the user credentials. You cannot update this field after creating your source.Client ID (mandatory)Part of the user credentials.Tenant ID (mandatory)Part of the user credentials. You cannot update this field after creating your source.Client Secret (mandatory)This is the value which you saved when you created the client secret.
Note: You cannot retrieve this value from the Azure portal or the Google Cloud console once it is set. You can update this value with a new secret in case you update the credentials.Customer managed encryption key (Preview)The key you want to use to protect your data in Google Cloud. By default, Google Cloud automatically encrypts data when it is at rest using encryption keys managed by Google. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) to encrypt and decrypt your data at rest. These encryption keys are created, managed, and owned by you.Optional: User tags for migration resourceThe Migrate to Virtual Machines service creates snapshots of your VM disks to migrate them to Google Cloud.
If you would like to have a custom tag associated with these resources, specify them here. This can help you identify all resources created by Migrate to Virtual Machines in your Azure environment. Snapshots also already have tags as detailed in Snapshots.
All snapshots are automatically created under one resource group when the source is created. The resource group name can be seen on the Source Details page.
Click Create. A notice detailing your new source appears.
Wait (up to 15 minutes but usually less) until the Source status is indicated as Active.

Verify your inventory to ensure that there are instances that correspond to the tags (and/or security groups) that you specified when you created your source.

As part of source creation, your project is automatically added as a target project.

Prerequisites form the GCP Side.

To ensure a successful migration of Virtual Machine, make sure you have met the following prerequisites.

System Prerequisites

Google Cloud requirements

Currently Azure as a source in Migrate to Virtual Machines (v5) is in preview. To participate in the preview of this feature, send a request to the email address: m2vm-azure-preview@google.com. Ensure that you include the project-id (where the VM Migration API is enabled) and a username, for all users that need access.
Identify Host and Target project (Migrate to Virtual Machines uses the following types of projects):
Host Project (required)
Use the host project to control the migration process and optionally to host the Compute Engine instances running your migrated workloads. You must create and configure a host project as described below.
Target Project (optional)
A target project defines the destination project for a Compute Engine instance running your migrated VM. Your host project can be used as a target project. If you want to migrate VMs to additional projects, you must add them as target projects to Migrate for Compute Engine.

Choose or create a Google Cloud project to be as a Host project. You must have owner permissions on the Google Cloud project.

Note: It would be good practice to keep the Host and Target project separate. After you finish these steps, you can delete the project, removing all resources associated with the project.

Enable the Google Cloud APIs on the Host ProjectNameTitlevmmigration.googleapis.comMigrate to Virtual Machines APIservicemanagement.googleapis.comService Management APIservicecontrol.googleapis.comService Control APIiam.googleapis.comIdentity and Access Management (IAM) APIcloudresourcemanager.googleapis.comCloud Resource Manager APIcompute.googleapis.comCompute Engine API

You can ensure that the APIs are enabled through the Google Cloud Console UI:

Go to APIs & Services > select on Enabled APIs & Services
Click on Enable APIs and Services

Search for APIs and enable it

Make sure API Enabled as shown below (A green checkmark indicates that the API is enabled)

Additionally, you can enable APIs via gcloud commands:

You can use the gcloud commands in the Cloud Shell or you can download the gcloud CLI tool and install it on your local machine as follows:
Install and initialize the Cloud SDK

#Ensure that you have set the default project to the host project. Replace PROJECT_ID with the project ID of your host project:
$ gcloud config set project PROJECT_ID
#Run below cmd to enable required services on the host project:
$ gcloud services enable vmmigration.googleapis.com servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

Identity and Access Management includes two predefined roles that you can use to control access for users in your organization:
VM Migration Administrator
VM Migration Viewer

Migration Prerequisites

Identify and configure the target project (Optional)

You must identify the Google Cloud project that you want to use as the target project:

In the Google Cloud console, on the project selector page, select or create a Google Cloud project to use as a target project.
Note the name and ID of the selected project.
Enable the following services on the target project:

NameTitleservicemanagement.googleapis.comService Management APIservicecontrol.googleapis.comService Control APIiam.googleapis.comIdentity and Access Management (IAM) APIcloudresourcemanager.googleapis.comCloud Resource Manager APIcompute.googleapis.comCompute Engine API

To enable the required services using gcloud use below commands:

Ensure that you have set the default project to the target project. Replace PROJECT_ID with the project ID of your target project:

# Set the Project
$ gcloud config set project PROJECT_ID
#Enable APIs
$ gcloud services enable servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

Set required permissions

For a user to be able to add a target project, and to configure the details of the Compute Engine instance on the target project, that user requires the necessary Identity and Access Management (IAM) roles and permissions.

Because you perform these actions in the Google Cloud console, the user account that requires these permissions is the account that you use to log in to the Google Cloud console:

To add a target project to Migrate to Virtual Machines, the user account you use to log in to the Google Cloud console requires the permissions described below:
The role vmmigration.admin on the host project
The role resourcemanager.projectIamAdmin on the target project
To add these roles:
Determine the email address of your user account. In the Google Cloud console, you can see all users in your project on the IAM page:
Grant your user account the vmmigration.admin role on the host project:

$ gcloud projects add-iam-policy-binding HOST_PROJECT_ID --member=user:USER_EMAIL_ADDRESS --role=roles/vmmigration.admin

Grant your user account the resourcemanager.projectIamAdmin role on the target project:

$ gcloud projects add-iam-policy-binding TARGET_PROJECT_ID --member=user:USER_EMAIL_ADDRESS --role=roles/resourcemanager.projectIamAdmin

To configure the target details of the Compute Engine instance running on the target project, the user account you use to log in to the Google Cloud console requires permissions to access data in the target project, such as networks, instance types, and more. See below:
The role compute.viewer and the role iam.serviceAccountUser on the target project
To add this role:
Determine the email address of your user account. In the Google Cloud console, you can see all users in your project on the IAM page:
Grant your user account the compute.viewer role and the iam.serviceAccountUser role on the target project:

$ gcloud projects add-iam-policy-binding TARGET_PROJECT_ID --member=user:USER_EMAIL_ADDRESS --role=roles/compute.viewer

$ gcloud projects add-iam-policy-binding TARGET_PROJECT_ID --member=user:USER_EMAIL_ADDRESS --role=roles/iam.serviceAccountUser

(Shared VPC environment only) Grant your user account the compute.viewer role on the Shared VPC host project:

$ gcloud projects add-iam-policy-binding VPC_HOST_PROJECT_ID --member=user:USER_EMAIL_ADDRESS --role=roles/compute.viewer

Depending on how you configure IAM for your environment, you might configure a single user to perform both actions, or configure two separate users.

Add the target project

After you have configured the target project, and assigned the necessary roles to the user account, you can add it to Migrate to Virtual Machines.

To add a target project to Migrate to Virtual Machines:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Targets tab. A list of projects already added appears.

Click on Add.
Select one or more projects.

**Note:** If your user account does not have the necessary permissions to add the project, a warning icon, warning, appears next to the project name. Hover over the icon to see the associated error message. See Set permissions to add a target project to add the necessary permissions, then retry this step.

Select Add.

Configuring permissions for a Shared VPC (Optional)

Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network so that they can communicate with each other securely and efficiently using internal IPs from that network.

When you use Shared VPC, you designate a project as a Shared VPC host project and attach one or more service projects to it. The VPC networks in the Shared VPC host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.

Note: Both Migrate to Virtual Machines and Shared VPC use the term host project. For Migrate to Virtual Machines, you use the host project to perform migrations. For Shared VPC, you use the host project to define the VPC network.

Using Shared VPC with Migrate to Virtual Machines

When your Migrate to Virtual Machines environment uses a Shared VPC, you must ensure that you have configured permissions correctly so that you can deploy a migrated VM to the Compute Engine target project.

For example, you have the following environment:

Project A — Migrate to Virtual Machines host project
Project B — Shared VPC host project and subnet definitions
Project C — Migrate to Virtual Machines target project and Shared VPC service project

In this example, you define a Shared VPC in Project B. Project B is referred to as the Shared VPC host project.

You then migrate a VM to a Compute Engine instance in Project C, the Migrate to Virtual Machines target project, where Project C accesses the Shared VPC. In this example, Project C is referred to as the Shared VPC service project. You must have already configured Project C to function as a service project of Project B, as described in Provisioning Shared VPC, before you deploy the Compute Engine instance.

However, before you can deploy the Compute Engine instance, you must also ensure that the Migrate to Virtual Machines default service account on Project A has the required permissions. Specifically, Migrate to Virtual Machines requires the compute.networkUser role on the subnetworks in the Shared VPC host project.

The following section describes how to configure the Migrate to Virtual Machines default service account.

Configuring the Migrate to Virtual Machines default service account

A default service account is created on the host project during the creation of the first migration.

To deploy a Compute Engine instance to a target project that accesses a Shared VPC, you must add the compute.networkUser role on the subnetworks in the Shared VPC host project to the Migrate to Virtual Machines default service account. You have two options for how you add this role:

Assign the Migrate to Virtual Machines default service account to be a Service Project Admin with access to only some of the subnets in the Shared VPC host project. This option provides a granular means to define Service Project Admins by granting them the compute.networkUser role for only some subnets in the Shared VPC host project. See Service Project Admins for some subnets for the steps to this procedure.
Allow the Migrate to Virtual Machines default service account to be a Service Project Admin with access to all subnets in the Shared VPC host project. In this case, you grant the role of compute.networkUser for the Shared VPC host project to the Migrate to Virtual Machines default service account. The default service account then has access to all of the currently defined and future subnets in the Shared VPC host project. The procedure below shows the steps to this method.

To configure the Migrate to Virtual Machines default service account for access to all subnets in the Shared VPC host project:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Targets tab. At the top of the page is an information box showing the email address of the Migrate to Virtual Machines default service account in the form: service-HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com
Copy the email address.
Use that email address to grant the compute.networkUser role on the Shared VPC host project to the Migrate to Virtual Machines default service account:

$ gcloud projects add-iam-policy-binding VPC_HOST_PROJECT_ID \ 
--member=serviceAccount:service-M4CE_HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com \
   --role=roles/compute.networkUser

Configuring permissions on target project service account (Optional)

Migrate to Virtual Machines creates a default service account when you enable the Migrate to Virtual Machines API on the host project.

To be able to assign the service account used to run a Compute Engine instance on a target project, you must add the necessary permissions to the Migrate to Virtual Machines default service account.

About the service account used to run a Compute Engine instance

Before you can test-clone or cut-over a VM, you must configure the target details of the Compute Engine instance used to host the migrated VM. For both a test and a production environment, configure the target details for the Compute Engine instance to specify:

Google project
Number of CPUs
Amount of memory
Disk size

For example, you have the following environment:

Project A — Migrate to Virtual Machines host project
Project B — Compute Engine target project

By default, the Compute Engine instance running on target Project B does not have a service account assigned to it.

If the target Compute Engine instance requires access to Google Cloud services and APIs, create a service account in the target project with the necessary permissions to access those services and APIs. Then, assign that service account to the Compute Engine instance when you configure its target details.

You perform all configuration of Compute Engine instances from the Migrate to Virtual Machines host project. Before you can assign a service account in the target project to a Compute Engine instance, you must ensure that the Migrate to Virtual Machines default service account has the necessary permissions on the target service account.

Configuring the default service account

To assign a service account to a Compute Engine instance running on a target project, the default Migrate to Virtual Machines service account on the host project must be added to the Service Account User role on the target service account.

To add the default service account to the Service Account User role:

Determine the email address of the Migrate to Virtual Machines default service account:
Open the Migrate to Virtual Machines page in the Google Cloud console.
Select the Targets tab. At the top of the page is an information box showing the email address of the Migrate to Virtual Machines default service account in the form: service-HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com

Save that email address for use below.
In the Google Cloud console, go to the Service Accounts page.
Select the target project.
Select the checkbox next to the desired target service account.

Click Manage Access. A list of roles that have been granted on the service account are displayed.
Expand the Service Account User role to view the principals that have been granted that role on the service account.
If the email address of the Migrate to Virtual Machines default service account is not listed, select Add Principal.
Enter the email address of the Migrate to Virtual Machines default service account as the New principal.
Select the Service Accounts > Service Account User role.

Select Save. You should now be able to assign the service account to a Compute Engine instance running on a target project.

Next steps: Start your migration

After you’ve created an Azure source, you are ready to start your migration. The rest of the process for migrating your workload from an Azure source matches the process for other sources for Migrate to Virtual Machines.

For details on how to start your migration process, see Migrating individual VMs.

Step 1: Onboard a VM

The first phase of migration is to onboard the source VM. For example, a vSphere data center might contain tens, hundreds, or even thousands of VMs. Onboard only the VMs that you want to migrate.

You can have up to 200 migrations in progress at a time (excluding migrations in the Finalize phase), per host project and region. This limitation is for migrating VMs of all source types. For example, you can migrate 100 VMs from a VMware source and 100 additional VMs from AWS at the same time.

To onboard a source VM, follow these steps:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Sources tab.
From the drop-down list, select the migration source from which you want to migrate a VM.
Below the drop-down you see the Source status of the migration source as:

Active: The source is active and connected to Migrate to Virtual Machines.
Offline: The source is unavailable.
Pending: The source is in the process of being connected and verified.

If you don’t see any entries in the drop-down list, it indicates that you have not configured the migration source properly. Review the steps for your setting your migration source and try again.
A table appears showing the source VMs in the migration source available for migration. Select one or more source VMs.
The VM Power Status column shows the status as Suspended, On, or Off. You can migrate a VM with any of these statuses.
Click Add Migrations > VM Migration.
Confirm that you want to create the migration.
After you create a migration, the Replication status column for a VM displays one of the following:

Pending: VM is in the process of being onboarded.
Ready: VM is onboarded but has not started replicating yet.

You can now start replication of the VMs as described in the next step.

Step 2: Start replication of the source VM

After onboarding a source VM, start replicating the disk data from the source VM to Google Cloud. This process takes place in the background with no disruption to the workload.

Data replication is comprised of two steps:

First replication step: Migrate to Virtual Machines creates the initial snapshot of the source VM data disks and replicates the snapshot data to Google Cloud. Depending on the amount of disk data on the source VM, the first replication can take minutes or hours to complete.
The Replication status column of a VM on the first replication step displays the First sync status followed by the appropriate sub-step.
Incremental replication step: Following a successful first replication step, incremental replication steps occur at set time intervals (every two hours by default). In each step, a new snapshot is created for each data disk. Only data updates that occurred after the previous step are replicated to Google Cloud using the Change Block Tracking (CBT) mechanism.
The Replication status column of a VM on an incremental replication step displays the Active status followed by the appropriate sub-step.

Initiate replication of a source VM

To initiate replication of a source VM, follow these steps:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table appears showing the source VMs in the migration source that you have onboarded. You can start replication on any VM with the replication status Ready.
Select one or more source VMs.
Click Migration > Start Replication. The Replication status column shows replication status along with one of the sub-steps detailed in the replication cycle sub-steps table.
To view the replication history of a VM, click the VM to open the details page. Click Replication History to view the replication history of the VM along with the sub-steps of the replication.
Note: Migrate to Virtual Machines saves and displays up to 100 cycles of replication history for a VM.
You can now configure a migration target for the test-clone and cut-over phases.

Migrate to Virtual Machines generates an adaptation report after your replication cycle is complete. For more information about adaptation reports, see the adaptation report documentation.

You can create a test-clone at any time after the first replication step completes. Replication continues until you explicitly end it during the cut-over phase.

Pause replication

To pause replication, follow these steps:

At any time, you can pause replication for a VM. When you pause a VM, its Replication status changes to Paused.

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of available source VMs appears.
Select one or more VMs.
Select Pause.
To later resume replication, select one or more VMs and then select Resume.

Set the replication interval

To set the replication interval, follow these steps:

By default, Migrate to Virtual Machines performs a replication of the source VM every 2 hours. To change the replication frequency:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of available source VMs appears.
For the VM, select the Edit Target Details button. A panel opens to let you configure the target.
To set the frequency for multiple VMs, select the VMs and then select the Edit Target Details button. A panel opens to let you configure the replication frequency of the selected VMs.
Select the Target Details tab.
In the Replication policy area, set the replication frequency, in seconds.
Select Save.

Switch from VM migration to disk migration

You can switch between VM migration and disk migration at any time during the migration process.

To switch from VM migration to disk migration, follow these steps:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
Select one or more VMs.
Click Migration > Convert to disk migration.

Switching from VM migration to disk migration clears out the target details. This is because the target details for VM migration and disk migration are different. However, the replication progress won’t be lost during the switch.

You must update the target details before you clone or cut-over operations on your VM in order for the migration to succeed. For more information, see Configuring the target.

Step 3: Configure the target for a migrated VM

To configure a target, perform two main steps:

Add a target project. The target project is the project that contains the Compute Engine instance used to host the migrated VM.
The host project is automatically added as a target project so there is no need to explicitly add it. If you want to add an additional project as a target project, see Adding a target project.
Configure the Compute Engine instance used to host the migrated VM. For both a test and a production environment, configure the target Compute Engine instance to specify settings including:

Google project
Number of CPUs
Amount of memory

This section describes how to set the initial configuration of the Compute Engine instance used to host the migrated VM. However, there are many additional settings that you can apply to a Compute Engine instance. See the Compute Engine documentation for detailed descriptions of all settings.

You can modify the target details at any time. When instantiating a Compute Engine instance for either the test-clone or cut-over phase, Migrate to Virtual Machines uses the target details settings at the time of the operation.

To configure the Compute Engine target, follow these steps:

If you have not done so already, add the target project as shown in Adding a target.
Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of migrations appears.
Select a VM (you can select multiple to edit) and then select the Edit target details button. On the panel that appears, configure the target details for all of your selected VMs.
Set the Target details that define the characteristics of the Compute Engine instance used to host the migrated VM. The following table lists those settings and provides links to the Compute Engine documentation for detailed descriptions.
Migrate to Virtual Machines does not support all Compute Engine settings. You can only set those described in the following table. After the Compute Engine instance is created, you can modify all of its settings:
Section titleField nameDescriptionGeneralInstance nameThe name of the Compute Engine instance. See Resource naming convention for the naming rules.ProjectThe name of the project hosting the Compute Engine instance. It must be a project you have already added earlier in this section.ZoneZone for the Compute Engine instance. See Regions and Zones.
The region of the deployed instance is the one you specified when you registered the Migration Connector. See Installing the Migration Connector for more.LabelsTo organize your project, add labels as key/value pairs to your resources. See Labeling resources.Machine configurationMachine type seriesCompute Engine offers predefined machine type series that you can use when you create an instance. Each option has a different cost. Select the machine type series that is most appropriate for your workload.
See Pricing for more information.
Migrate to Virtual Machines determines the OS type of the Compute Engine instance automatically based on the source VM and applies PAYG licensing to the instance. See Licensing.Machine typeCompute Engine offers predefined machine types that you can use when you create an instance. The available machine types depend on the machine series you select in the Machine type series field.
See predefined machine types documentation for more information.On host maintenanceWhen Compute Engine performs periodic infrastructure maintenance, it can migrate your VM instances to other hardware without downtime. Set this option to Migrate VM Instance (Recommended), the default, to migrate the VM. Set it to Terminate to terminate the instance.Automatic restartWhen set to On (Recommended), the default, Compute Engine automatically restarts instances when they are terminated for non-user-initiated reasons, such as a maintenance event, hardware failure, or software failure. Set it to Off to disable restart.MetadataSpecify VM metadata key/value pairs that will be stored for your migrated VM.
For more information about Compute Engine VM metadata, see the VM metadata documentation.
Migrate to Virtual Machines enforces a limitation of 64K characters for all metadata key/value pairs in each migrated VM.NetworkingNetwork nameSpecify the VPC network that the instances will be part of.Subnetwork nameSpecify the subnet associated with a region. This must be a subnetwork of the specified Network.External IP addressSet to None (default) to disable external access, and to Ephemeral to allow gcloud CLI to assign an IP address. See Reserving a static external IP address.Internal IP addressSet to Ephemeral (Automatic) (default) to allow gcloud CLI to assign an IP address, Ephemeral (Custom) to set your own IP address, or reserved-internal-ip (IP) to use a predefined IP address. See Reserving a static internal IP address.Hostname
You can create a VM with a custom hostname by specifying any fully qualified DNS name. Custom hostnames must conform to RFC 1035 requirements for valid hostnames.
For more information about formatting custom hostnames, see the Custom hostname documentation.
You can change the hostname for Windows VMs using the TargetDetails API. After changing a Windows VM hostname locally, ensure that you update the hostname in the Active Directory (AD) so that AD trust doesn’t break.
Add Network InterfaceMigrate to Virtual Machines lets you optionally create a Compute Engine instance with multiple network interfaces (NICs). Each interface is attached to a different VPC network, giving that instance access to different VPC networks in gcloud CLI.
Before you add additional network interfaces, be aware of the following considerations:

Attaching multiple network interfaces to the same VPC network is not supported. While the configuration may save, the instantiation of the VM will fail.
After a Compute Engine instance is instantiated, by using test-clone or cut-over, you cannot add or remove a network interface on the created instance. You can repeat test-clone or cut-over with different target details to recreate the instance.
To add or remove a network interface:
Select Add network interface to add an additional network interface to the Compute Engine instance. You can set all of the same options as you do with the initial network interface.

For more information, see Creating instances with multiple network interfaces.Network tagsTags enable you to make firewall rules and routes applicable to specific instances. See Configuring network tags.Additional configurationService accountSpecify the service account on the target project used to run the Compute Engine instance. By default, no service account is assigned to the Compute Engine instance.
If you plan to run an application on the Compute Engine instance that needs access to other gcloud CLI services and APIs, create a service account in the target project with the necessary permissions to access those services and APIs before creating the Compute Engine instance. Then, specify that service account here. For more information, see set up a VM to run as a service account.
To attach the service account to the Compute Engine instance, your user account on the Migrate to Virtual Machines host project requires the necessary permissions. See Configuring permissions on target project service account for more.Disk typeSpecify the storage type for the instance. See Storage options.Customer managed encryption key (Preview)The key you want to use to protect your data in Google Cloud. By default, Google Cloud automatically encrypts data when it is at rest using encryption keys managed by Google. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) to encrypt and decrypt your data at rest. These encryption keys are created, managed, and owned by you.
When you add a CMEK, you must also assign the Cloud KMS CryptoKey Encrypter/Decrypter role permissions to the Compute Engine Service Agent account you are using. For more information, see Protect resources by using Cloud KMS keys.Convert BIOS to UEFI (Preview)Enable this option to convert the OS boot type of a VM instance from Basic Input/Output System (BIOS) to Unified Extensible Firmware Interface (UEFI). This option is useful when you want to securely boot your VM instance, as secure boot is only supported by UEFI. However, you can also just convert the boot type from BIOS to UEFI, without using secure boot.
The capability to convert the boot type of a VM instance from BIOS to UEFI is available as part of a Preview. To participate in the preview, send a request to the email address: m2vm-bios-to-uefi@google.com.
Note: Not all operating systems support BIOS to UEFI conversion. To see the list of operating systems that support the conversion, see the BIOS to UEFI conversion supported column in Supported operating systems.Secure bootAll selected VMs must have an EFI boot option to enable secure boot. Compute Engine enforces up-to-date policies that may prevent your VM from loading when secure boot is enabled. For more information, see Secure Boot in the Compute Engine documentation.License typeCompute Engine supports pay as you go (PAYG) licenses and bring your own licenses (BYOL) for your deployed VMs. The default license type for a migrated VM is assigned by Migrate to Virtual Machines based on the migrated operating system, as described in Supported operating systems.
If your operating system supports multiple license types, you can override the default license type to explicitly specify a license type of PAYG or BYOL.
Note: Some operating system types, such as CentOS and Debian, don’t support a license. Other operating systems only support one type of license. Attempting to set an unsupported license type causes an error when you attempt to deploy a test-clone VM or to cut-over to a production VM.Additional licensesMigrate to Virtual Machines supports up to 10 additional licenses (using valid URL format) that you can add in the Additional configuration section of the Target details dialog.
For example, you can add additional licenses using this URL format:

https://www.googleapis.com/compute/beta/projects/windows-sql-cloud/global/licenses/sql-server-2012-enterprise

Sole tenancyNode affinity labelsCompute Engine supports the deployment of migrated workloads to sole-tenant nodes. A sole-tenant node is a Compute Engine server that is dedicated to hosting only your project’s VMs.
Before you can configure your migrated workloads to run on sole-tenant nodes, you must have already created a sole-tenant node template and sole-tenant node group in the target project and zone. See Provisioning VMs on sole-tenant nodes.
Affinity labels let you logically group nodes and node groups. When provisioning your Compute Engine instances, use affinity labels to schedule your instances to run on a specific set of nodes or node groups.
You can add affinity labels to your migrating VMs by entering them manually in the Info panel by key-value pair, or by using the Browse Node dialog to select a node or node group. You can then edit the VM affinity labels to customize the sole-tenant deployment:

Select Browse Node to add an affinity label from the list of available sole-tenant nodes and node groups. A key-value pair will automatically be created for you upon selecting the node or node group.
Select Add New to manually enter the affinity label.

Minimum vCPUs allocatedSet the Minimum vCPUs allocated for the Compute Engine instance.
See Node affinity and anti-affinity and Configure node affinity labels for more information.Replication PolicyReplication idle duration between cyclesBy default, Migrate to Virtual Machines performs a replication of the source VM every 2 hours. Set the replication frequency (in seconds).
Note: The replication cycle idle time counter starts after the previous replication cycle ends.
Select Save.

You can later edit the target details. When instantiating a Compute Engine instance for either the test-clone or cut-over phase, Migrate to Virtual Machines uses the target details settings at the time of the operation.

(Optional) Step 4: Test a clone of a migrating VM

In the test-clone phase, Migrate to Virtual Machines deploys a clone of your migrated VM to a Compute Engine instance in your testing environment. While the testing phase is optional, it is best practice to perform testing before deploying a migrated VM to production.

Each time you create a test-clone instance, it is cloned from the most recently completed replication cycle data using the current target details. In other words, a test-clone instance represents a snapshot of the source VM at the time of the last completed replication cycle.

For Azure source VMs that have more than one disk, the Migrate to Virtual Machines replication cycles take snapshots of each disk independently of each other. As these snapshots are not taken simultaneously, the data captured might sometimes have minor discrepancies. Therefore, it is recommended that you don’t use test-clones as a production replacement when you cut-over.

Caution: New replication data and modifications to the target details are only applied to new test-clones, not to existing test-clones.

Initiate your first test-clone

You can create your first test-clone after the initial replication cycle completes, and then create additional test-clones throughout your migration process.

In order for you to initiate a test-clone, you must have already configured a target environment for the Compute Engine instance before you can initiate a test-clone. See Configuring the target documentation for more information.

You can only test a VM in the Paused state if it has completed at least one replication.

For more information on potential issues during the test-clone phase, see the Troubleshooting section.

Create a test-clone of a VM

To create a test-clone of a VM using Migrate to Virtual Machines, follow these steps:

Ensure that you have configured a testing VM target environment as shown in Configuring VM target.
Note: You can only test-clone a VM with a valid target environment.
Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of available source VMs appears. You can test any VM that is in the Active (Current cycle: XX%) or Active (Idle) state. The Active state means the first replication sync of the VM succeeded and VM data is being incrementally replicated.
Select a VM.
Select Cut-Over and Test-Clone > Test-Clone. The Test-Clone/Cut-Over status column shows the status of the operation along with one of the sub-steps detailed in the test-clone sub-steps table.
Wait for the Test-Clone/Cut-Over status column to show Succeeded. This indicates that the clone was created successfully.
You can view the test-clone history of a VM in one of the following ways:

Click the Info panel icon,
for the VM. On the panel that opens from the right, the Monitoring tab displays the history, including the name of each test-clone instance.
Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the test-clone history of the VM along with the sub-steps of the test-clone.

You can cancel an active test-clone operation by clicking Cut-Over and Test-Clone > Cancel Test-Clone.
For the test-clone VM, click Show details to view the VM instance name.
To manage the running Compute Engine instance, go to the VM instances page in the Google Cloud console for your project:
Go to VM instances page
From the Google Cloud console manage the Compute Engine instance to:
Start, stop, and delete the instance.
Determine the internal and external IP address of the instance.
View and modify characteristics of the instance.
Perform all other management tasks.
Perform any validation testing or other testing on the migrated VM.
After you have completed testing, delete the Compute Engine instance to free up resources so that you will no longer be charged for the instance.

Manage multiple test-clones

Over the duration of your migration journey, you might create multiple test-clones. For example, you create the first test-clone after the initial replication cycle. Then, as you refine your migration, you create new test-clones because of:

Modifications you make to your source VM to support migration
Modifications you make to the target details of the migrated VM
New replication data from the source VM
Any other changes you make over the duration of your testing cycle

Remember that a test-clone is a snapshot of the source VM created from the current replication data and target details. New replication data and modifications to the target details are only applied to new test-clones, not to existing test-clones.

If you have an existing test-clone instance running, then before you create a new test-clone you can either:

Delete the existing test-clone instance and then create a new one with the same instance name. You cannot create a new instance with the same name as an existing instance.
Edit the target details to set a new instance name. In addition, if you specified a reserved or custom IP address for an existing test-clone instance, make sure to use different values for any additional instances.

To monitor all test-clone instances, follow these steps:

View the test-clone history of a VM in one of the following ways:

Click the Info panel icon,
for the VM. On the panel that opens from the right, the Monitoring tab displays the history, including the name of each test-clone instance.
Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the test-clone history of the VM along with the sub-steps of the test-clone.

To manage a running Compute Engine instance, select the arrow icon arrow_right_alt to open the VM instance in the Google Cloud console.
Or, go directly to the VM instances page in the Google Cloud console:
Go to VM instances page
After you create a test-clone, it is up to you to manage it. If you want to modify or delete a running test-clone VM, you use the Compute Engine tools, not Migrate to Virtual Machines.

Step 5: Create a Cut-over

In the cut-over phase, you transfer control to your migrated VM running in a Compute Engine instance in your production environment on Google Cloud.

Migrate to Virtual Machines generates an adaptation report when your cut-over cycle is complete. For more information about adaptation reports, see the adaptation report documentation.

Caution: For Azure source VMs that have more than one disk, the Migrate to Virtual Machines replication cycles take snapshots of each disk independently of each other. As these snapshots are not taken simultaneously, the data captured might sometimes have minor discrepancies. Therefore, it is recommended that you don’t use test-clones as a production replacement when you cut-over.

The cut-over process, follow these steps:

If data replication is active, that is, the Replication status of the VM is Active (Current cycle: XX%), waits for it to complete.
Note: To perform cut-over, replication cannot be paused.
Shuts down the source VM.
Performs the final data replication. Because replication occurs throughout all migration phases, the amount of data to replicate shouldn’t be very large.
Stops replication.
Creates the Compute Engine instance from the final replicated data.
Note: You must have already configured the Compute Engine target details before you can initiate a cut-over. See Configuring the target for more.

The cut-over phase includes a short VM downtime and should take place during a scheduled maintenance window. You must determine the maintenance window during which you can stop the source VM and redirect traffic to the migrated VM running on Compute Engine.

To create a cut-over, follow these steps:

Ensure that you have configured the VM target details as shown in Configuring VM target. If the target details were previously configured for test-clone operation, you might want to edit the target details to point to a new target.
Note: You can only cut-over a VM with a valid target environment.
Open the Migrate to Virtual Machines page in the Google Cloud console.
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of available source VMs appears. You can cut-over any VM that is in the Active (Current cycle: XX%) or Active (Idle) state. The Active state means the first replication sync of the VM succeeded and VM data is being incrementally replicated.

The Estimated cut-over time column shows an estimate of the time it takes to complete a cut-over job for a VM after you initiate a cut-over. This field is populated only for an active VM that has completed a few replication cycles.
The Test-Clone/Cut-Over status column shows the status of the operation along with one of the sub-steps detailed in the cut-over sub-steps table.

Select a source VM.
Select Cut-Over and Test-Clone > Cut-Over. Initiating a cut-over on a migrating VM starts the following sequence of actions performed by Migrate to Virtual Machines:
Shuts down the source VM.
Performs the final data replication. Because continuous replication occurs throughout all migration phases, the amount of data to replicate should not be very large.
Creates the Compute Engine instance hosting the migrated VM from the final replicated data.
Stops data replication.
Wait for the Test-Clone/Cut-Over status column to show Cut-over job completed. This indicates that the cut-over succeeded.
You can view the cut-over history of a VM in one of the following ways:

Click the Info panel icon,
, for the VM. On the panel that opens from the right, the Monitoring tab displays the history, including the name of each cut-over instance.
Click the VM to open the details page. Click Test-Clone/Cut-Over History to view the cut-over history of the VM along with the sub-steps of the cut-over.

You can cancel an active cut-over operation by clicking Cut-Over and Test-Clone > Cancel Cut-Over. However, if you want to resume use of the source VM, you must manually restart the VM.
To manage a running Compute Engine instance, select the arrow icon arrow_right_alt to open the VM instance in the Google Cloud console.
Or, go directly to the VM instances page in the Google Cloud console:
Go to VM instances page
From the Google Cloud console manage the Compute Engine instance to:
Start, stop, and delete the instance.
Determine the internal and external IP address of the instance.
View and modify characteristics of the instance.
Perform all other management tasks.
Perform validation test on the migrated workload.

If for any reason you want to retry cut-over or roll back from the cut-over:

Retry cut-over

To retry cut-over, follow these steps:

Select a VM in the Cut-Over state.
Select Migration > Resume Replication.
Retry cut-over.

Rollback from cut-over

To rollback from cut-over, follow these steps:

Cut-over stops the original source VM in your migration source, so you must start it and redirect traffic back to the source VM.
If necessary, copy new data created on the Compute Engine instance so that you can write it to the source VM.
(Optional) delete or shutdown the Compute Engine instance running the migrated VM.
Resume replication on the source VM. Replication resumes from the last snapshot taken.
Retry cut-over.

Step 6: Finalize a migration

The replication data used to create a Compute Engine VM is retained after cut-over to allow you to resume replication from the last replication snapshot.

However, you are charged for the storage used by the replication data until you delete it in the finalize phase. Finalizing deletes all replication data and all other storage resources associated with a migrated VM.

The Finalize phase does not delete Compute Engine instances running a migrated VM. If you created Compute Engine instances during the testing phase, you must manually delete them. You will be charged for those test-clone instances until they are deleted.

To finalize a migration, follow these steps:

Open the Migrate to Virtual Machines page in the Google Cloud console:
Go to the Migrate to Virtual Machines page
Select the Migrations tab.
A table of available source VMs appears. Finalize can be performed only on VMs in the Cut-Over state.
Select a source VM.
Select Finalize and then confirm the finalize.
After finalize completes, the state of the VM is set to Finalized. The only allowed operations on a migration in the Finalized state are:

Delete the migration
Add to or remove from a group

Reference Docs

https://cloud.google.com/migrate/virtual-machines/docs/5.0/migrate/create-an-azure-source

https://cloud.google.com/migrate/virtual-machines/docs/5.0/migrate/migrating-vms

About Me

As businesses move towards cloud-based solutions, I provide my expertise to support them in their journey. With over 15 years of experience in the industry, I am currently working as a Google Cloud Principal Architect. My specialization is in assisting customers to build highly scalable and efficient solutions on Google Cloud Platform. I am well-versed in infrastructure and zero-trust security, Google Cloud networking, and cloud infrastructure building using Terraform. I hold several certifications such as Google Cloud Certified, HashiCorp Certified, Microsoft Azure Certified, and Amazon AWS Certified. My certification in Google Cloud Certified — Cloud Digital Leader is particularly noteworthy.

Certificated :

Google Cloud Certified — Cloud Digital Leader.
2. Google Cloud Certified — Associate Cloud Engineer.
3. Google Cloud Certified — Professional Cloud Architect.
4. Google Cloud Certified — Professional Data Engineer.
5. Google Cloud Certified — Professional Cloud Network Engineer.
6. Google Cloud Certified — Professional Cloud Developer Engineer.
7. Google Cloud Certified — Professional Cloud DevOps Engineer.
8. Google Cloud Certified — Professional Security Engineer.
9. Google Cloud Certified — Professional Database Engineer.
10. Google Cloud Certified — Professional Workspace Administrator.
11. Google Cloud Certified — Professional Machine Learning.
12. HashiCorp Certified — Terraform Associate
13. Microsoft Azure AZ-900 Certified
14. Amazon AWS-Practitioner Certified

I assist professionals and students in building their careers in the cloud. My responsibility is to provide easily understandable content related to Google Cloud and Google Workspace. If you find the content helpful, please like, share and subscribe for more amazing updates. If you require any guidance or assistance, feel free to connect with me.

YouTube:https://www.youtube.com/@growwithgooglecloud

Topmate :https://topmate.io/gcloud_biswanath_giri

Medium:https://bgiri-gcloud.medium.com/

Telegram: https://t.me/growwithgcp

Twitter: https://twitter.com/bgiri_gcloud

Instagram:https://www.instagram.com/google_cloud_trainer/

LinkedIn: https://www.linkedin.com/in/biswanathgirigcloudcertified/

Facebook:https://www.facebook.com/biswanath.giri

Linktree:https://linktr.ee/gcloud_biswanath_giri

and DM me,:) I am happy to help!!