This document describes best practices that you can consider while designing your virtual machine (VM) migration to Google Cloud with Migrate for Compute Engine. Migrate for Compute Engine 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:
- Migrating VMs with Migrate for Compute Engine: Getting started
- Migrating VMs with Migrate for Compute Engine: Building your foundation
- Migrating VMs with Migrate for Compute Engine: Migrating your VMs
- Migrating VMs with Migrate for Compute Engine: Best practices (this document)
This document is useful if you're planning to migrate VMs from a supported source environment to Compute Engine with Migrate for Compute Engine. It can help you avoid common pitfalls, expensive refactorings, and later fixes by implementing best practices early in your VM migration project. These source environments can include the following:
- A VMware vSphere environment
- A Microsoft Azure VM environment
- An Amazon Elastic Compute Cloud (Amazon EC2) environment
- Physical servers and VMs running an operating system that Google Cloud supports
The best practices described in this document cover the following areas:
- Assessing your source environment
- Building your foundation
- Migrating your VMs
- 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 for Compute Engine 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 for Compute Engine?
- What are your security and governance requirements?
- Do you have a strategy for deploying resources in the cloud?
- Do any of your workloads have hard-coded 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. 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 for Compute Engine supports:
- Migrate VMware VMs with VMware HCX to Google Cloud VMware Engine.
- Migrate supported non-VMware VMs to a VMware environment with VMware HCX OS Assisted Migration.
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
After familiarizing yourself with the structure of a migration and migration sprints and waves, analyze the 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 per 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.
This best practice helps you validate the migration plan.
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 for Compute Engine. 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 for Compute Engine has 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. As described in Designing the migration to Google Cloud, in the planning phase, you create the basic infrastructure for Migrate for Compute Engine.
Ensure your environment meets the requirements
When provisioning and configuring the infrastructure to support your migration, ensure that your environment meets the following requirements:
- The Migrate for Compute Engine requirements
- The network access requirements
- The operating system requirements for Migrate for Compute Engine
- The supported licensing options for Microsoft software
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.
When building your foundation, ensure that your environment supports the minimal network bandwidth required for Migrate for Compute Engine to operate. We also recommend that you do the following:
- To avoid congesting your network during the migration, configure bandwidth throttling.
- To maximize the network throughput, configure the maximum transmission unit while considering the recommended values for Virtual Private Cloud, 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 for Compute Engine requires enough resource quotas to complete the VM migration. For example, Migrate for Compute Engine 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. If you use multiple IP addresses for the VMs in your source environment, configure the VMs in your target environment to also use multiple IP addresses.
To ensure that you have enough quotas to complete the migration, do the following:
- Check your current available quota.
- Ensure that your available quota meets Migrate for Compute Engine quota requirements.
- 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 for Compute Engine
If you need to upgrade Migrate for Compute Engine 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 for Compute Engine 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 for Compute Engine versions.
Migrating your VMs best practices
This section describes best practices to address common issues that might arise while migrating your VMs. As described in Designing 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 migrating 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, it can lead to unexpected results, such as failing to migrate the VM.
This best practice helps you avoid errors during the migration.
Uninstalling Migrate for Compute Engine
After you complete the migration, we recommend that you do the following:
- Uninstall Migrate for Compute Engine.
- Delete the Identity and Access Management service accounts that Migrate for Compute Engine created for the migration process.
- 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.
This best practice ensures that you decommission Migrate for Compute Engine components, and avoid any unnecessary billing and management effort.
Troubleshooting best practices
This section describes best practices to help you investigate any migration issue that might occur when using Migrate for Compute Engine.
To effectively troubleshoot migration issues, or issues that occur after the migration, you gather information about Migrate for Compute Engine, your environment, and your workloads. Start by gathering information about the following:
- Migrate for Compute Engine version. Take note of the Migrate for Compute Engine version that you used for your migration projects. Check if the issues you're experiencing are mentioned in the Migrate for Compute Engine release notes.
- Migration life-cycle phases. If the migration is failing, take note of the life-cycle phase during which you experience the issue, and if the issue is reproducible and not transient.
- Use Cloud Monitoring and Cloud Logging. To gather information about your environment, we recommend that you use Cloud Monitoring and Cloud Logging to understand the status and performance of your migration. Ensure that Cloud Monitoring and Cloud Logging are enabled by checking that the necessary metadata are set for your Compute Engine instances.
For more information, see Migrate for Compute Engine troubleshooting, or help diagnose issues by gathering information and insights about your environment and about Migrate for Compute Engine.
- Attend the Migrating to Google Cloud Coursera training, which also covers Migrate for Compute Engine.
- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.