Migrating VMs with Migrate to Virtual Machines: Best practices

Stay organized with collections Save and categorize content based on your preferences.

This document describes best practices that you can consider while designing your virtual machine (VM) migration to Google Cloud with Migrate to VMs. Migrate to VMs helps you migrate VMs from a source environment to Google Cloud. Your source environment might be running in an on-premises environment, in a private hosting environment, or in another cloud provider.

This document is part of a series that has the following parts:

This document is useful if you're planning to migrate VMs from a supported source environment to Compute Engine with Migrate to VMs. These source environments can include the following:

The best practices described in this document cover the following areas:

  1. Assessing your source environment
  2. Building your foundation
  3. Migrating your VMs
  4. Troubleshooting migration issues

Assessment best practices

This section describes best practices to address common issues that might arise during the migration assessment phase. As described in Designing the migration to Google Cloud, in the assessment phase, you assess your source environment, the workloads that you want to migrate to Google Cloud, and which VMs support each workload.

Involve the teams responsible for your workloads as early as possible

During the first phase of the migration, gather information about the source environment by involving and interviewing all teams that are responsible for your environment, workloads, and VMs. For example, to assess the technical requirements of your migration, interview development teams, operation teams, security teams, and the lines of business and stakeholders that are related to the workloads to migrate. To assess the regulatory requirements of your migration, include legal and compliance teams in these interviews.

This best practice helps you avoid surprises and unexpected issues caused by unforeseen migration requirements and dependencies.

Analyze the complexity of your environment

When assessing the source environment and VMs, evaluate factors that might affect the complexity of a migration. Determine the criteria and data points to assess the complexity of each workload. If the complexity of a migration increases, you might have to plan for additional time and effort to complete the migration. For example, you might consider the following factors:

  • Do you need to migrate VMs with operating systems that you want to update?
  • Do you need to migrate VMs with unsupported operating systems?
  • Do you need to migrate bare-metal or physical servers?
  • Do you have dependencies on a given hypervisor?
  • Do you need to migrate from a hypervisor that Migrate to VMs doesn't currently support?
  • Do you have dependencies on certain technologies or services that you don't want to or can't migrate?
  • How many VMs do you need to migrate?
  • Do any of these VMs have dependencies to other applications, systems, or VMs?
  • Does your migration team have experience with Google Cloud?
  • Does your migration team have experience with Migrate to VMs?
  • What are your security and governance requirements?
  • Do you have a strategy for deploying resources in the cloud?
  • Do any of your workloads have hardcoded configurations that you can't change?
  • Do your workloads require licensed operating systems or other licensed software?

When assessing the migration plan, if you need to migrate VMs from an environment that you manage with an unsupported hypervisor, follow the guidance to migrate physical servers with Migrate to VMs version 4.

For this process to work, a VMware host and a VMware vCenter instance must be in the same network as the VMs that you want to migrate. If there's no VMware host in the network, we recommend one of the following options to migrate your VMs to a source environment that Migrate to VMs supports:

If you need to migrate a workload that supports high volumes of transactions or requests, assess the speed at which changes are synchronized between the source and the target environments. The speed during the migration might be less than the speed at which the changes are generated by the workload. In such cases, we recommend that you assess other migration tools and techniques that are specific to these types of workloads. For example, if you migrate a database that supports a high volume of transactions per time unit, the speed at which the transactions are propagated to the target environment might not be fast enough to complete the synchronization. In this case, the VMs in the target environment might not be able to complete the data synchronization, making your migration wave impossible to complete.

This best practice helps you estimate the difficulty of a migration, and to manage expectations of the stakeholders of your migration project.

Analyze your current environment to rightsize the target environment

To draft a complete migration plan, define the machine type of each VM in the target environment for each VM that you want to migrate from the source environment. We recommend that you gather information about the provisioned resources of each VM in the source environment, and the utilization rate of those resources, as described in Migration to Google Cloud: Assessing and discovering your workloads.

This best practice helps ensure that you gain in-depth insights about your workloads.

Analyze the migration plan

Before you start your migration plan analysis, and to help you to understand the architecture of Migrate to VMs, we recommend that you read the following documents:

After you've familiarized yourself with the concepts that are discussed in these documents, analyze your migration plan to gather information about schedule, duration, effort, and costs. We recommend that you use weighted medians and weighted means instead of single values, so that you can refine the results of your analysis after each migration wave.

For example, after analyzing the migration plan, you might determine values for the following:

  • The expected migration duration
  • The expected number of VMs to migrate for each time unit
  • The total migration cost
  • The migration cost per VM
  • The available network throughput
  • The compatibility of the tools you're using for backup and disaster recovery with the target environment

Consider all deployment environments for your applications when you analyze the migration plan. If a workload requires multiple deployment environments, consider these environments and the differences between each environment in your analysis. For example, if you deploy a workload in a development, a quality assurance, and a production environment, you might discover in your analysis that these environments have a different number of VMs. You might have to adjust your migration plan to consider these differences and to meet the migration deadlines.

Adjust the migration plan while you gain experience

After establishing a migration plan, and starting to implement that plan, you gain experience about migrating apps and VMs, Google Cloud, and Migrate to VMs. While the migration is in process, use this knowledge to regularly revisit, adjust, and improve your migration plan. Amend the migration plan at least once per iteration. You might discover that you set unrealistic goals, or spent effort on unanticipated issues.

This best practice helps you optimize the migration plan.

Schedule a maintenance window for the VMs to migrate

To complete the migration of a VM, Migrate to VMs version 4 and Migrate to VMs version 5 have to perform operations that might require downtime of the VM. Plan for redundancy and for a cutover window to perform the operations that require a downtime. For example, if you migrate a cluster of VMs, you might have to split the cluster and recompose it after the migration.

This best practice helps you avoid unexpected downtimes of your workloads.

Planning best practices

This section describes best practices to address common issues that might arise while building your foundation for Migrate to VMs version 4 or while building the foundation for Migrate to VMs version 5. As described in Designing the migration to Google Cloud, in the planning phase, you create the basic infrastructure for Migrate to VMs.

Ensure your environment meets the requirements

When you provision and configure the infrastructure to support your migration, ensure that your environment meets the Migrate to VMs requirements for the version that you're using.

If you're using Migrate to VMs version 4, ensure that your environment meets the following requirements:

If you're using Migrate to VMs version 5, ensure that your environment meets the following requirements:

Ensure that you involve all the relevant teams in the analysis of these requirements because the requirements span different areas, such as computing, networking, security, and compliance. For example, opening a firewall port might require collaboration between the security team and the networking team.

To maximize the network throughput, we also recommend that you configure the maximum transmission unit while considering the recommended values for Virtual Private Cloud networks, Cloud Interconnect, and Cloud VPN.

This best practice helps you avoid unanticipated issues due to incompatibilities and requirements that you can't meet.

Ensure that you have enough resource quota

Google Cloud enforces quotas on resource usage. Migrate to VMs requires enough resource quotas to complete the VM migration. For example, Migrate to VMs version 4 Cloud Extensions require a persistent disk quota, depending on the number of VMs that each Cloud Extension supports.

We also recommend that you review VPC quotas and limits for Compute Engine instances.

To ensure that you have enough quotas to complete the migration, do the following:

  1. Check your current available quota.
  2. Ensure that your available quota meets Migrate to VMs quota requirements.
  3. Request an increase in quotas, if necessary.

This best practice helps you avoid delays due to quota increase requests turnaround time and quota requirements.

Upgrade Migrate to VMs version 4

If you need to upgrade Migrate to VMs version 4 to a newer version, complete or roll-back any in-flight migrations to avoid leaving VMs in inconsistent states. For example, for an early proof-of-concept in a previous phase, you might have set up an older Migrate to VMs version.

This best practice helps you avoid downtimes and issues due to your VMs being left in an inconsistent state between migrations by using different Migrate to VMs versions.

Migrating your VMs best practices

This section describes best practices to address common issues that might arise while migrating your VMs with Migrate to VMs version 4 or migrating your VMs with Migrate to VMs version 5. As described in Design the migration to Google Cloud, in the migrating your VMs phase, you migrate the VMs from the source environment to Compute Engine.

Ensure that the guest OS is correctly configured in VMWare

Before migrating your VMs, ensure that VMWare vCenter is not reporting any warnings related to the guest operating system (OS). If you see a warning, fix the guest OS configuration by changing the configured guest OS.

This best practice helps you avoid errors during the migration.

Ensure that your VMs are correctly prepared

Before you migrate your VMs or physical servers, ensure that they are correctly prepared for the migration without any errors or warnings. If your VMs and physical servers aren't prepared for the migration, there can be unexpected results for the migration attempt, such as failure to migrate the VMs. This best practice helps you avoid errors during the migration.

If you are using Migrate to VMs version 4, to learn more about how to prepare your VMs before migration, see Preparing and adapting virtual machines.

If you are using Migrate to VMs version 5, your VMs are automatically prepared before migration. For more information, see Adapting VMs to run on Google Cloud.

Ensure that your VMs are working properly in Google Cloud

We recommend that you verify that your VMs are working correctly in Google Cloud both during the replication and after the cut-over phase. This best practice helps you validate that your workloads and VMs are working as you'd expect.

When you start the replication phase, you verify your VMs by creating test clones in a sandbox environment. You can repeat the test clones creation process multiple times to evaluate how your VMs work in the cloud as you apply changes to the source environment. We recommend that you run these tests before you advance your VMs to the cut-over phase.

After you complete the cut-over phase, check the operation of your VMs by involving the owner of each workload, and asking them to assess if there are any issues with such workloads. We recommend that you run this verification before you advance your VMs to the finalize phase.

Uninstalling Migrate to VMs

After you complete the migration, we recommend that you uninstall Migrate to VMs. This best practice ensures that you decommission Migrate to VMs components, and avoid any unnecessary billing and management effort.

To uninstall Migrate to VMs version 4, do the following:

  1. Uninstall Migrate to VMs.
  2. Delete the Identity and Access Management service accounts that Migrate to VMs created for the migration process.
  3. Delete the firewall rules created for the migration process. For more information about managing firewall rules, see Google VPC firewall rules, Internetwork traffic privacy in Amazon VPC, Azure Firewall documentation, or your on-premises firewall documentation.

To uninstall Migrate to VMs version 5, do the following:

  1. Delete and uninstall Migrate Connectors from your VMware vSphere data center. For more information, see Deleting a Migrate Connector.
  2. Deactivate the Migrate to VMs version 5 service: vmmigration.googleapis.com. For more information about deactivating services in a project, see Disabling services.
  3. Delete any test clones you created to verify that your workloads work correctly in Google Cloud.

Troubleshooting best practices

This section describes best practices to help you investigate any migration issue that might occur when using Migrate to VMs.

To effectively troubleshoot migration issues, or issues that occur after the migration, you gather information about Migrate to VMs, your environment, and your workloads. Start by gathering information about the following:

For more information, see Migrate to VMs version 4 troubleshooting and Migrate to VMs version 5 troubleshooting, or help diagnose issues by gathering information and insights about your environment and about Migrate to VMs version 4.

What's next