Migrating VMs with Migrate for Compute Engine: Migrating your VMs

This document helps you migrate virtual machines (VMs) from your source environment to Google Cloud by using Migrate for Compute Engine. Your source environment might be running in an on-premises environment, in a private hosting environment, or in another public cloud.

This document is part of a multi-part series about migrating to Google Cloud. If you're interested in an overview of the series, see Migration to Google Cloud: Choosing your migration path.

This document is part of a series:

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

This document assumes that you have already planned and built a foundation for Migrate for Compute Engine, by following Migrating VMs with Migrate for Compute Engine: Building your foundation. In the deployment phase of the migration framework, you migrate your VMs to Google Cloud.

Structure of a migration

The following terms are important for understanding how to organize a VM migration from a supported source environment to Google Cloud:

  • A workload is a set of one or more VMs that are organized around a focused business use case.
  • A migration is the process of moving workloads from a source environment to a target environment.
  • A sprint is a division of the migration work. Multiple sprints compose a migration.
  • A wave is a way to organize the VMs that you want to migrate into batches. This organization avoids a single, high-risk migration. A sprint consists of one or more waves.
  • A runbook is a file that specifies which VMs are included in a wave, and describes the properties of the source and destination VMs. A single wave contains one runbook.
  • A job is an operation that Migrate for Compute Engine performs on the VMs in a runbook. A single wave can contain one or more jobs.
  • A run group defines the logical order in which multiple VMs are migrated within a wave.
  • A stub VM is a management object that Migrate for Compute Engine creates on VMware vSphere to interact with the physical server during a migration.

The following Unified Modeling Language (UML) diagram shows the structure of a migration in terms of sprints, waves, runbooks, run groups, and jobs.

The structure of a migration.

Migrating virtual machines with Migrate for Compute Engine

To migrate VMs with Migrate for Compute Engine, you perform the following steps:

  1. Prepare your VMs.
  2. Organize migrations in sprints.
  3. Create runbooks.
  4. Create waves.
  5. Run jobs against waves.

Preparing and adapting virtual machines

Before migrating your VMs with Migrate for Compute Engine, you must do the following:

  • Prepare your VMs and physical servers for the migration.
  • Adapt your VMs to operate in the Google Cloud environment.

Prepare your virtual machines and physical servers

Migrate for Compute Engine automatically modifies the configuration of Linux and Windows VMs before, during, and after the migration. For example, Migrate for Compute Engine installs operating system packages and drivers on VMs.

You can also use Migrate for Compute Engine to migrate physical servers to Google Cloud. You prepare each physical server for the migration, and then Migrate for Compute Engine can migrate it like any other VM.

To prepare your physical server for migration, do the following

  1. Configure the Migrate for Compute Engine physical server connector on the physical server.
  2. Register a stub VM that Migrate for Compute Engine uses to perform the migration of the physical server.

Adapt your virtual machines

In addition to the default configuration modifications that Migrate for Compute Engine applies to VMs, Migrate for Compute Engine provides custom configuration scripts to adapt your VMs before, during, and after the migration. For example, you can install an operating system package or modify the configuration of a VM. You can choose to run these adaptation scripts during the following stages of migration:

  1. Before the migration, when a VM is still in your source environment.
  2. During the migration, when a VM is running in cached mode in the target environment.
  3. After the migration, after a VM detach operation.

Organizing the migration into sprints and waves

To mitigate the risks of a migration, we recommend that you divide the work into sprints, and then divide each sprint into waves.

To organize the migration in sprints, do the following:

  1. Review the information that you gathered when assessing your workloads, where you determined what you want to migrate, and which workloads to migrate first.

    For example, let's say that you want to migrate the application-1 workload and the following four VMs associated with that workload:

    • The database-primary-vm and the database-replica-vm VMs run a database.
    • The backend-vm VM runs the backend of a the application-1 application.
    • The frontend-vm VM runs the frontend of application-1.

    Plan for a number of sprints that's equal to the number of workloads that you want to migrate. Map the sprints to each workload. A sprint is mapped to exactly one workload, and each workload is mapped to exactly one sprint.

    For example, to migrate the application-1 workload, you plan for one sprint called sprint-1.

  2. Plan your sprints so that each sprint contains all VMs that are necessary to run the workload mapped to that sprint. For example, if you mapped the application-1 workload to the sprint-1 sprint, then all VMs that support the application-1 workload should be part of the sprint: database-primary-vm, database-replica-vm, backend-vm, and frontend-vm.

  3. Divide each sprint into one or more waves. We recommend that you use waves to manage dependencies between multiple VMs.

    For example, you can divide the sprint-1 sprint into three waves: wave-1 to migrate the frontend-vm VM, wave-2 to migrate the backend-vm VM, and wave-3 to migrate the database-primary-vm and the database-replica-vm VMs.

  4. (Optional) If you need to customize the order in which Migrate for Compute Engine migrates the VMs in a wave, you use run groups. For example, you can use a run group to migrate the database-replica-vm VM before the database-primary-vm VM.

  5. Review the recommendations to rightsize the target VMs. You get performance-based or cost-based recommendations from Migrate for Compute Engine Cloud, according to the usage patterns and the configuration of the VMs that you are migrating in the wave.

Creating waves

To create a wave, you do the following:

  1. Create the runbook for the wave from the Migrate for Compute Engine Manager. When you create the runbook, you specify the following information for each VM:
  2. Load the runbook into the wave using the Migrate for Compute Engine Manager
  3. Validate the wave.

For more information about runbooks, see Runbook reference.

Running jobs on waves

You run jobs on the waves that you created. Jobs manage the lifecycle of VMs during the migration. We recommend that you run the following jobs:

  1. Run test clones before migrating VMs.
  2. Migrate VMs.
  3. Monitor migration jobs and waves.
  4. Validate your target environment.

Run test clones before migrating VMs

Before you migrate the source VMs, we recommend that you evaluate and test how your source VMs will perform in Google Cloud to help you discover any issues. By running the test clone operation against source VMs, Migrate for Compute Engine creates clones that behave exactly like the source VMs, and runs them in Google Cloud without actually migrating the source VMs. This operation lets you measure against your previous on-premises performance baselines for your VM and make any needed changes to VM size or types. Test clones don't modify any live data because data from the test environment is not written back to the source environment. For more information about creating test clones, see Creating a test clone.

After creating the test clones, you can assess how they run in Google Cloud. You can gather information about the behavior and performance of the workloads in the new environment, and evaluate this data against the baseline of the workloads running in the current environment. You can preemptively fix any issues before the migration takes place, without disrupting your source environment.

After you complete the assessment of test clones and fix any issues, you run the delete clone operation to shut down and remove the clones from your Google Cloud environment.

Migrate VMs

Migrate for Compute Engine runs the following operations on the VMs to migrate during the migration:

  1. Run-in-cloud
  2. Storage migration
  3. Prepare to detach
  4. Detach
  5. Upgrade OS
  6. Cleanup

For more information about VM lifecycle stages, see VM migration lifecycle.

Migrate for Compute Engine conveniently groups the run-in-cloud, storage migration, and prepare to detach operations in the full migration operation. We recommend that you run the full migration operation, instead of separately running the run-in-cloud, storage migration, and prepare to detach operations due to the following reasons:

  • You don't have to remember the right order in which you should run the operations because you can let Migrate for Compute Engine take care of this aspect.
  • If any operation fails when running the full migration operation on a VM, you can fix the issue, and re-run the full migration operation. Migrate for Compute Engine automatically skips the operations part of the full migration operation that completed successfully, and resumes from the operation that failed.

If you want to roll back a VM from Google Cloud to your source environment, you can run the move back operation on that VM before detaching it.

If any of the VMs that you need to migrate runs an OS or uses a file system that Migrate for Compute Engine doesn't support, you can migrate those VMs by running the offline migration operation.

To run operations on the VMs in a wave, you create and start a new job on a wave.

Monitoring jobs and waves

Monitoring and logging are crucial to assess how the migration is progressing and to solve any issues. In addition to monitoring Migrate for Compute Engine components, we recommend that you monitor the migration when Migrate for Compute Engine runs jobs on waves. You can monitor waves and jobs and view the console log of a VM running in Google Cloud.

Validate your target environment

After migrating your VMs to Google Cloud, you validate the VMs against the baseline that you established when you ran test clones and against your compliance test suites. This validation helps ensure that your workloads are behaving correctly.

Optimizing your environment after migration

When you complete all the migration waves, the migration is considered done but your Google Cloud environment might need optimizations. For example, you can rightsize Compute Engine VMs, or you can start using managed services.

For more information about optimization, see Migration to Google Cloud: Optimizing your environment.

What's next