Migrate VMware VMs to Google Cloud: Test Clones Before Cutover
To migrate on-premises VMware VMs to Google Compute Engine with Migrate to Virtual Machines, you install the Migrate Connector in your vSphere data center, replicate each VM's disks in the background using change block tracking, launch a throwaway test clone to prove the workload boots and behaves on Compute Engine, then cut over during a short downtime window. The sequence that keeps this boring is doing three checks first: the connector's permissions and network path, the target project and its network, and the machine type you intend each VM to land on. Everything painful about this migration is a consequence of skipping one of those three.
This is a lift-and-shift path. It moves the VM as it is. It does not modernise the workload, and it quietly borrows against your future by carrying the old machine's assumptions into the cloud. That trade-off is fine, as long as you make it on purpose.
What Migrate to Virtual Machines actually does
The tool is agentless from the guest's point of view. You install a single appliance, the Migrate Connector, and it talks to vCenter to snapshot and stream disk data to Google Cloud. Google's documentation describes a two-phase replication model: an initial full sync followed by incremental syncs.
The first replication step creates a snapshot of the source VM's data disks and copies it to Google Cloud, and depending on how much disk data the VM holds, that first copy can take minutes or hours. After the first sync succeeds, incremental replication runs on a schedule, every two hours by default, and each step snapshots the disks again and copies only the blocks that changed since the last step using change block tracking. Replication continues until you delete the migration, and you can pause it on individual VMs to free up network capacity for higher-priority machines.
The important operational fact is that <strong>the source VM keeps running the whole time</strong>, including while you test. Replication happens in the background with no disruption to the workload. That is what lets you validate on Compute Engine without touching production, and it is also why cutover is the only step that needs a real downtime window.
The console is the control plane
Migrate to Virtual Machines is fully integrated into the Google Cloud console, so onboarding sources, starting replication, launching test clones and cutting over all happen from the same UI. That is convenient, but it also means the migration state lives in Google's control plane, not in your Terraform. Treat the target configuration as something you version separately, because the tool applies the target details as they exist at the moment you run test clone or cutover, not as they were when you first onboarded the VM.
What to check first, before you replicate anything
Replication is the point of no easy return in the sense that it starts consuming bandwidth and snapshot storage. Get these four things right before you onboard a single VM.
The connector and its permissions
You install and configure the Migrate Connector on the on-premises vSphere data center, and you create a dedicated vCenter user account with the permissions the connector needs. Do not reuse an admin account. Scope a service account to exactly the read and snapshot rights the connector requires, because this credential now has a persistent path into your virtual estate.
One connector maps to one Google Cloud region. Each Migrate Connector you register facilitates migration to a specific region, so if you are landing workloads in more than one region, you deploy a separate connector for each. Plan that into your appliance footprint early rather than discovering it mid-wave.
The network path
The connector needs outbound access to Google Cloud APIs. Your on-premises or Google Cloud VMware Engine hosts can reach those APIs through Private Google Access over a Cloud VPN tunnel or Cloud Interconnect, and you open the required firewall rules to the Google API domains before you register the connector. Do the bandwidth arithmetic here: the first full sync moves the entire provisioned disk, and if that saturates the same link your users depend on, you have created an outage without cutting anything over. Pausing replication per VM is your pressure valve, but it is better to size the path than to throttle after the fact.
The target project, network and IAM
The Compute Engine target details define the landing zone for each migrated VM: the project, the machine type, the network settings and more. The tool uses a default service account to create the Compute Engine instances during both test clone and cutover, and that account needs real permissions in the target project.
Two IAM details catch people out. If your migrated VMs land in a Shared VPC, you add the compute.networkUser role to the Migrate to Virtual Machines default service account so it can attach instances to subnetworks in the host project. And if you are migrating from AWS rather than VMware, the tool needs ec2:DescribeSnapshots, ec2:CreateSnapshots and ec2:CreateTags on the source side to snapshot the volumes. A useful separation-of-duties control is the predefined roles/vmmigration.viewer role, which lets someone watch a migration without being able to run one.
# Target-side roles the migration touches
roles/vmmigration.viewer # read-only visibility into migrations
roles/compute.networkUser # add to default SA for Shared VPC targets
# Source-side (AWS) permissions for EC2 volume migration
ec2:DescribeSnapshots
ec2:CreateSnapshots
ec2:CreateTagsGetting the target project, network topology and IAM boundaries right is landing-zone work, and it pays to settle it before the first wave rather than retrofitting it under time pressure. If your target project structure is still in flux, that is a cloud architecture decision to close out first.
The machine type
Before you draft a migration plan, define the machine type each VM will run on in Compute Engine, gathered from the provisioned resources and the actual utilisation of each source VM. Sizing off the on-premises spec alone reimports years of over-provisioning. There is also a specific concurrency caveat worth noting: when migrating VMs with 16 or more disks into regions that do not support N2 machine types, Google recommends running fewer than 200 VMs concurrently to avoid problems. That is the kind of limit you want to know before wave four, not during it.
The migration flow, step by step
- Onboard the source VM. In the Migrations tab, select your active source and pick the VMs to migrate. If the source shows Offline or Pending instead of Active, the connector is not properly connected and nothing downstream will work.
- Start replication. The first sync runs in the background; incremental syncs then run every two hours, moving only changed blocks.
- Set the target details. Choose the project, machine type and network for the migrated instance. You can change these at any point, and the tool honours whatever is set at the moment of the next operation.
- Launch a test clone. This is where you earn confidence.
- Cut over. Short downtime, then the workload runs on Compute Engine.
Test clone: prove it before you commit
A test clone spins up a Compute Engine instance from the most recent replicated data while the source VM keeps running untouched. Use it to confirm the machine boots, the OS adaptations took, the application starts, and it can reach its dependencies on your target network. During migration the tool adapts the guest so it runs on Google Cloud: it adjusts network configuration, deploys the Compute Engine guest agent and enables the serial console, with specific adaptations for Linux and Windows. The serial console matters precisely because a lift-and-shift can fail to get a network address on the first boot, and that is your way in to debug it.
Test clones are cheap insurance. Run one per distinct OS image and per application tier, not just once for the whole estate.
Cut-over and the downtime you cannot avoid
Cutover is the step that requires a downtime window. You stop the source, let the final incremental sync complete, and the tool instantiates the production Compute Engine instance from the fully replicated data. The honest planning guidance from Google is to plan for redundancy and a cutover window, and to account for the fact that a clustered application may need to be split apart and recomposed on the other side. If you are moving a database cluster or anything with quorum, the cutover is an application procedure, not a button.
The trade-off: lift now, pay in adaptation later
Migrate to Virtual Machines supports two related paths, and you can switch between them at any point in the process because the underlying steps are the same.
| Full VM migration | Disk migration | |
|---|---|---|
| What lands | A ready-to-run Compute Engine instance | Disks you attach to a VM you define |
| Control over instance shape | Uses the target details you set | You build the instance yourself |
| Best when | Straight lift-and-shift, minimal change | You want to reshape the machine on arrival |
| Effort | Lower up front | Higher up front, less rework later |
The larger trade-off is not between these two options, it is the one you make by lifting and shifting at all. You get off the on-premises hardware quickly and with low risk, and in exchange you carry the old VM's disk layout, its baked-in agents and its sizing assumptions into Compute Engine. The bill for that arrives later as instances that are larger than they need to be and images that nobody wants to touch. That is a legitimate call to make when the priority is a datacentre exit on a deadline, and the way to keep it honest is to revisit the plan every iteration, right-size from real utilisation, and schedule the modernisation work rather than pretending it will not be needed.
Planning waves, cutover windows and rollback for a datacentre exit is the substance of a cloud migration engagement, and it is mostly project discipline rather than tooling. The tool moves bytes reliably; the sequencing of which application moves when, and what breaks when it does, is the part that needs an engineer who has done it before.
Frequently asked questions
Does the source VM go down during replication?
No. Replication runs in the background with no disruption to the running workload, using an initial full sync and then incremental syncs every two hours by change block tracking. The only step that needs a downtime window is the final cutover, when you stop the source and start the migrated instance on Compute Engine.
How long does the first replication take?
It depends on how much disk data the VM holds and on the bandwidth of your link to Google Cloud. Google states the first replication can take minutes or hours; the incremental syncs afterwards are much smaller because they only move changed blocks. Size your Cloud VPN or Cloud Interconnect capacity for the full first sync, not the incrementals.
Can I test a workload on Compute Engine before cutting over?
Yes, that is what test clones are for. A test clone builds a Compute Engine instance from the latest replicated data while production keeps running, so you can validate boot, OS adaptation and application behaviour with no impact on the source. Run one per operating system image and per application tier before you schedule any cutover.
Do I need a separate connector for each region?
Yes. Each Migrate Connector facilitates migration to a single Google Cloud region, so migrating into multiple regions means deploying a connector per region, even within the same host project. Account for that in your appliance and network planning before the first wave.
Is Migrate to Virtual Machines the right tool if I want to modernise, not just move?
Not on its own. It is a lift-and-shift tool: it carries the VM across largely as-is, applying only the adaptations needed to run on Compute Engine. If your goal is containers, managed databases or a redesigned architecture, treat this as the first step that gets you off the hardware, then plan the modernisation as separate, deliberate work.
