Version 5.0

Mass migration with groups

An Enterprise data center might contain tens, hundreds, or even thousands of VMs running concurrently. While you can use Migrate for Compute Engine to migrate each VM individually, you can also use groups to perform bulk migration tasks on multiple VMs simultaneously.

Groups streamline the migration process by letting you migrate multiple VMs in batches. You can create a group with multiple VMs, and then perform all phases of migration on the group as a whole or on a subset of VMs in the group, including:

  • Onboarding
  • Replication
  • Setting target details
  • Test-clone
  • Cut-over
  • Finalize

During migration, you can also monitor and control each VM in the group separately.

About group migrations

Applications in an Enterprise environment are often distributed over multiple VMs. For example you might have:

  • 15 VMs running application 1
  • 10 VMs running application 2
  • A collection of apps spread across 100 VMs all running on the same subnet

Use Migrate for Compute Engine to create a separate group for each application, and another group for the 100 VMs on the subnet. After creating these groups, you can then perform operations:

  • On each group separately
  • On a subset of VMs in any group

Performing operations on groups

Migration of a group of VMs occurs over the same phases as the migration of a single VM.

Onboarding

Select multiple VMs to add to an existing group, or to create a new group. Adding a VM to a group automatically onboards the VM so that you can then start replication on the VMs in the group.

Replication

Start replication of the source VMs as a group, or control replication on a subset of VMs in the group. For example, you might start replication on a subset of VMs as part of an initial test scenario. After you have successfully tested a subset of VMs, you then replicate the entire group.

Use the Google Cloud Console to control and monitor replication for each VM in the group.

Set target details

Migrate for Compute Engine gives you complete control over the target environment so that you can configure the Compute Engine instances once for the entire group, or individually specify the characteristics of the Compute Engine instances for each VM.

For example, you can select the entire group and to configure the base target details. Then, you can edit individual VMs to customize the target details specific to that VM.

Test-clone

Like replication, you might start out testing only a subset of VMs in the group. If the tests are successful, you can slowly ramp up testing to a larger subset of the group or to the entire group itself.

Cut-over

Cutover typically occurs only after you have replicated the entire group and completed all testing. When you perform the cutover on the group, all of the source VMs are turned off in the on-premises data center, and traffic is directed to the Compute Engine VMs running on Google Cloud.

Just like in the testing phase, Migrate for Compute Engine lets you customize the target environment of the group as a whole, or individually for different VMs.

If migration was unsuccessful, you can roll back the migration. As is the case with an individual VM, the roll back process is manual and requires you to restart the source VMs and handle any data migration from Compute Engine back to the source VMs.

Finalize

Cutover typically occurs only after you have replicated the entire group and completed all testing. When you perform the cutover on the group, all of the source VMs are turned off in the on-premises data center, and traffic is directed to the Compute Engine VMs running on Google Cloud.

Monitoring VMs in a group operation

During migration, you can use the Google Cloud Console to view and monitor the status of each VM in the group. If a VM fails during any migration phase, you can fix the problem and run the operation on the individual VM again.

For example, you start cut-over operation on a group containing VMs A and B. Cut-over on VM B then fails. After fixing the issues with VM B, you repeat cut-over of VM B.

What's next