This page describes the phases a particular VM undergoes during a migration to Google Cloud. Some phases are optional, and others are unavailable during cloud-to-cloud migrations.

Full migration

The full migration operation moves VMs in one step from source to target. In doing so, it:

1. Performs the run-in-cloud process.
2. Waits for the VMs to be in the Cache on Demand state, when storage is streamed to the cloud.
3. Migrates the VM data to Google Cloud.
4. After storage is fully copied to Google Cloud, prepares the VM to detach.

When this process has completed, the VM state changes to Ready to Detach.

Full migration is an automatic process that includes the following tasks (which you can also run manually).

• run-in-cloud
• storage migration
• prepare to detach

Run-in-cloud

This operation moves the source VMs from your on-premises data center to Google Cloud. This does not completely move VM storage to the cloud — you migrate storage with storage migration.

The run-in-cloud operation:

1. Shuts down the source VMs.
2. Attaches to the VM’s volumes.
3. Starts the VM on Google Cloud, streaming storage as needed.

Storage migration

This operation copies storage data associated with a migrating VM to a disk on Compute Engine. To learn more about storage migration, see Migrating on-premises storage.

Prepare to detach

This operation takes VM disks from the Migrate for Compute Engine cache and object store and creates the native data drives in Google Cloud. After this operation finishes, you can detach the VM from the Migrate for Compute Engine cache.

Detach

In the detach sequence, Migrate for Compute Engine:

• Shuts down the VM in the cloud.
• Performs any final data synchronization necessary.
• Attaches the native disks to the instance.
• Starts the instance in Google Cloud.

Upgrade OS

This operation upgrades the OS of qualified VMs in the wave. For more on upgrading OSes during migration, see Upgrading Windows Server VMs.

If you perform the Upgrade OS operation, you must run it after you successfully run the Detach operation and before you run the Cleanup operation.

During the upgrade sequence, Migrate for Compute Engine:

• Shuts down the VM on Compute Engine.
• Upgrades the VM OS.

Cleanup

After the VMs are detached and you have completed any required validation, you can start the detach cleanup. Each VM is then marked as unmanaged by Migrate for Compute Engine.

You can Move back at any time before you run Cleanup.

Move back

Moves the instances in Google Cloud back to their source, either on-premises or AWS.

The move-back operation:

1. Stops the VMs.
2. Moves storage back to source.
3. Deletes the Google Cloud instances.

Test clone

A test clone creates clones of selected VMs to test them in Compute Engine. The test clone behaves like the live systems and leverages data from the source VM. However, test clones do not modify any live data because data from the test environment is not written back on-premises. Upon creating a test clone, Migrate for Compute Engine:

1. Attaches to the VM volumes.
2. Starts each instance in Google Cloud. Storage is streamed from the VM to Google Cloud.

For more information about how to use test clones, see Testing migrated workloads.

Delete clone

Deleting the test clone removes it from Google Cloud.

Note that deleting the test clone has no impact whatsoever on your live system or data. Any changes made to data in the test clone are not replicated back to your live system.

Offline migration

Migrate for Compute Engine can migrate workloads with operating systems or file systems that Migrate for Compute Engine’s streaming technology does not support, but that the cloud environment does support.

See Supported operating systems for a list of operating systems supported for offline migration.

During the offline migration process, Migrate for Compute Engine:

1. Migrates storage.
2. Starts the new VM only after migration is completed.
3. Detaches the VM.

Organizing migrations

If you’re planning a large migration, it’s a good idea to divide the work into large chunks, called “sprints.” A sprint should contain all of the VMs running one of your apps.

Migrate for Compute Engine subdivides a migration sprint into one or more waves, which group the VMs that run your apps into batches for migration. This document describes how to create waves and defines their subcomponents, runbooks and jobs.

Migration waves

To make migration more manageable, Migrate for Compute Engine provides a feature called waves that batches VMs for migration. Waves are made up of runbooks and jobs:

• A runbook is a CSV file that specifies the VMs to be included in a wave and the configuration of target VMs. It describes the source VM, defines properties for the target VM and networks, and also contains other metadata.
• A job is the migration operation that Migrate for Compute Engine performs on the list of VMs in the runbook. Migration operations include creating test clones, migrating, and detaching. A full list of migration phases is listed in the migration lifecycle.

Some considerations when using waves:

• All VMs in a wave must each undergo the same job. For example, if a database and application server are within the same wave, you can’t have a test clone created for one while the other is being fully migrated.
• Runbooks contain run groups, which define the order in which VMs are migrated in a wave.

Performing operations on migration waves

Batches of VMs in a wave move between the following stages in the migration lifecycle:

• Test Clone (for VMs from vSphere only)
• Delete Test Clone
• Run-in-Cloud
• Move Back
• Full Migration
• Offline Migration
• Detach
• Upgrade OS
• Cleanup

If a VM fails to complete a job and move to the next stage, you can fix the problem and run the wave again. Migrate for Compute Engine picks up the migration where it left off.

For example, if you run a Run-in-Cloud job on a wave containing VMs A and B, and VM B fails to complete the operation, fix B. After fixing B, you can do the following: either perform a Run-in-Cloud operation to bring B to the same status as A (A will not be changed), or perform a Full Migration operation to bring both VMs to the same state by performing Run-in-Cloud and migrating them together.

Starting your first wave

To start migrating with waves:

1. Create and edit a runbook.
2. Create a new wave from that runbook.
3. Run jobs against the wave.

Happy Learning !!!