Migrate VMware VMs to Google Cloud: Cutover Without Loss

To migrate VMware VMs to Google Cloud with Migrate to Virtual Machines, you deploy an agentless Migrate Connector into vSphere, let it replicate each source VM's disks to Google Cloud on a schedule while the source keeps running, boot a test-clone in Compute Engine to validate the workload, and only then cut over. The source is never modified in place, so the risk is not the replication. It is the cutover, because rollback is manual and anything written to the Compute Engine instance after cutover does not flow back to the source.

That is the whole shape of the job. The rest of this article is the detail a practitioner needs to run it without surprises: what to verify before you install anything, how the replication and adaptation actually behave, how to structure groups and targets, and how to plan the cutover so a failure is recoverable.

What to check before you install anything

Migrate to Virtual Machines is agentless. You do not install anything inside the guest OS of the source VMs. Instead you deploy a single appliance called the Migrate Connector into your vSphere or Google Cloud VMware Engine environment, and it does the work over the vSphere APIs. Check these things before you download the OVA.

Connectivity and the connector

The Migrate Connector establishes the datapath to Google Cloud over port 443, and that traffic can run over the public internet, a Cloud VPN tunnel, Private Google Access, or Dedicated Interconnect. It also performs storage operations against your VM disks and queries your vSphere inventory using the vSphere APIs, and it stops and monitors source VMs during cutover.

Two constraints catch people out. The connector does not support vCenter linked mode, so you install a separate connector for each vCenter. And each connector maps to one Google Cloud region, so if you are landing workloads in more than one region you deploy one connector per region.

The connector VM itself needs 4 CPUs with instruction set compatibility to a Sandy Bridge CPU or higher, and you generate an SSH key pair up front. The public key is copied to the connector during registration and is used to authenticate any remote SSH connection to it.

# Generate the SSH key pair the Migrate Connector uses for remote access
ssh-keygen -t rsa -b 4096 -f ~/.ssh/m2vm_connector -C "m2vm-connector"

# The connector needs outbound 443 to Google Cloud APIs from vSphere.
# Confirm the route you intend to use before deploying:
#   public internet | Cloud VPN | Private Google Access | Dedicated Interconnect

Identity, on both sides

You need a vCenter user account with the permissions the connector requires to read inventory and perform disk operations. On the Google Cloud side there are two distinct identities: a user account used only at registration time, and a service account the connector uses for run-time data transfer. Keep them separate in your head, because the registration account is not needed once the connector is running.

One quota to note early: the service account used by a connector is limited to 19 sources. If you plan to register more than 19 sources against the same host project, plan additional service accounts before you start rather than discovering the ceiling mid-migration.

If your VMs need to reach Google APIs privately after they land, this is the moment to get your network right. Landing-zone connectivity, private access and DNS are far cheaper to design before the first VM cuts over than to retrofit afterwards; that is core cloud architecture and networking work.

How the migration actually works

The mental model is simple once you separate replication from instantiation. Replication is continuous and non-disruptive. Instantiation, whether a test-clone or a cutover, is a point-in-time event that builds a Compute Engine instance from whatever has been replicated so far.

Replication is continuous and uses CBT

The first replication step takes an initial snapshot of the source VM's data disks and copies it to Google Cloud, which can take minutes or hours depending on disk size. After that, incremental steps run on a schedule, and each one uses VMware's Change Block Tracking (CBT) to copy only the blocks that changed since the previous step.

The default interval is every two hours, and you set the replication frequency per VM (or for a selection of VMs) in seconds from the target details. If you have limited outbound bandwidth, the connector supports throttling with a lower limit of 5 MBps, disabled by default and managed through the m2vm CLI. The connector keeps up to 100 cycles of replication history per VM, which is useful when you are proving out how long an incremental takes before you schedule the cutover window.

OS adaptation happens automatically

A raw VMware disk will not boot cleanly on Compute Engine, so Migrate to Virtual Machines performs OS adaptations at the end of each replication cycle for both Linux and Windows. These are the changes that make the guest work on Google's platform: it installs the google-compute-engine, google-osconfig-agent and google-cloud-sdk packages, sets the bootloader to print console logs to serial port 1, and disables or uninstalls VMware Tools / open-vm-tools.

The specifics differ by OS. On Linux it removes persistent network udev rules, and on Oracle Linux with a UEK7 kernel it installs kernel-uek-modules-extra for gVNIC support. On Windows it enables RDP, disables hibernation, sets the power scheme to balanced, changes the timezone to UTC, and needs up to 1.25 GiB of free space on the C drive. Check that free space on your Windows sources before you start, because a full C drive is a preventable adaptation failure.

Group your VMs and set target details

You rarely migrate one VM. Groups let you drive a set of VMs through the same lifecycle and set a common target, then override individual VMs where they differ.

Targets, machine types and licences

When you configure the target for a group, you set the target project and settings such as memory size and disk type, and you can select the whole group or narrow to a subset or a single VM whose requirements differ. Get the machine type right here rather than accepting a like-for-like default; on-prem sizing is usually generous and this is a natural point to right-size.

Licensing is applied per OS during OS adaptation: for a PAYG target licence, Migrate to Virtual Machines installs the OS-specific packages that licence requires.

VM migration or disk migration

There are two modes, and they answer different questions. VM migration produces a running Compute Engine instance. Disk migration produces Persistent Disk volumes you attach yourself, which suits cases where you want to control instance creation, boot configuration or automation. You can switch a VM between the two modes at any time.

The cutover, and the rollback you must plan for

This is where the trade-off lives. Because the source runs throughout, replication and testing carry almost no risk to production. The cost is deferred to the cutover, and it is worth being blunt about it.

Test-clone first

At any point after the first replication completes you can create a test-clone, which builds a Compute Engine instance from the latest replication data using the current target details, while the source VM keeps running. A test-clone is a static snapshot: new replication data and any later changes to target details apply only to new test-clones, not to one you already booted. So validate, then throw it away and clone again after you change anything. Testing before a production cutover is optional in the tooling and strongly recommended in practice.

Cutover stops the source, and rollback is manual

The cutover stops the source VM, performs a final replication, and creates the Compute Engine instance from that final data. Two failure modes matter. If the cutover itself fails, the source VM is stopped but the final replication data is still valid, and you retry. If the cutover succeeds but the new instance misbehaves, you roll back by deleting the Compute Engine VM and starting the source VM again.

Rollback is not automated. You have to redirect traffic back to the source yourself, and critically, anything written to the Compute Engine instance after cutover is not pushed back to the original source. That single fact drives your cutover design: keep the window short, freeze writes on anything you cannot afford to lose, and have DNS or load-balancer redirection ready in both directions before you press the button. Sequencing dozens of these cutovers with clean rollback paths is the hard part of a datacentre exit, and it is the core of our cloud migration practice.

Frequently asked questions

Do I need to install an agent inside each VM to migrate to Google Cloud?

No. Migrate to Virtual Machines is agentless for VMware sources. You deploy the Migrate Connector appliance into vSphere or VMware Engine, and it replicates disks and performs OS adaptations over the vSphere APIs without touching the guest OS. You do generate an SSH key pair for the connector itself, but nothing is installed inside the source VMs.

How much downtime does a Migrate to Virtual Machines cutover cause?

The disruptive part is only the cutover, not the replication or testing, because the source VM runs throughout and incremental replication uses Change Block Tracking. The cutover stops the source, runs a final replication of the changed blocks, and boots the Compute Engine instance. The length depends on how much data changed since the last cycle, which is why teams tighten the replication interval below the two-hour default before the window and use replication history to estimate it.

Can I roll back a Google Cloud migration if the new VM does not work?

Yes, but it is manual. You delete the Compute Engine instance and restart the source VM, then redirect traffic back yourself. The important caveat is that any data written to the Compute Engine instance after cutover does not flow back to the source, so plan short cutover windows and freeze writes on data you cannot afford to lose.

What is the difference between VM migration and disk migration in Migrate to Virtual Machines?

VM migration creates a running Compute Engine instance from the source. Disk migration creates Persistent Disk volumes that you attach to an instance yourself, which suits cases where you want to control instance creation or wrap it in automation. You can switch a VM between the two modes at any time.

How often does Migrate to Virtual Machines replicate data?

By default every two hours. You set the replication frequency per VM, or for a selection of VMs, in seconds from the target details. The first replication is a full copy of the disks, and subsequent incremental cycles copy only changed blocks using Change Block Tracking, with up to 100 cycles of history retained per VM.