Migrate VMs to Google Cloud (Without Losing Your Mind)

Google rebranded this service from "Migrate for Compute Engine" to "Migrate to Virtual Machines" in July 2022. The service performs block-level replication of VM data to Google Cloud while source virtual machines remain operational.

The migration engine copies your disk data to Google Cloud storage (and racks up charges faster than you expect). Initial replication transfers the complete disk image - this takes days, not hours, especially over VPN. I've seen 1TB VMs take a week when the connection kept hiccupping. Subsequent cycles only copy changed blocks, which are much faster. Those persistent disks add up fast during long migrations, so watch your costs.

Migration has six phases:

Key operational phases:

1. Replication - Initial replication takes days, not hours - learned this the hard way. A 1TB VM? Plan for 3-5 days depending on your bandwidth. Delta syncs after that are much faster - usually minutes
2. Test Clone - This will save your ass. Use it to catch all the stuff that breaks when you change IP addresses, database connection strings, and licensing dependencies
3. Cutover - Google says "minutes" but sometimes it's 20 minutes, especially with large disks. That "under an hour" estimate? Sometimes it's true, sometimes it's not

Source Environment Integration

VMware vSphere Integration:
VMware environments use the Migrate Connector appliance - an OVA virtual appliance deployed in vCenter. This connector handles all replication operations without requiring agents on individual VMs, reducing overhead and complexity.

Cloud Platform Integration:
AWS and Azure migrations install lightweight agents on source VMs. These agents communicate with cloud provider APIs to efficiently stream disk data to Google Cloud persistent storage.

Management Interface:
The Google Cloud Console has a decent web UI for once - actually shows useful progress info instead of generic spinners. Command-line nerds get gcloud CLI and REST APIs. The CLI is your friend when you need to script 200 VM migrations and don't want to click through the web UI like a psychopath.

Network Architecture:
Source environments require HTTPS connectivity (port 443) to Google Cloud APIs. The migration service manages data transfer and tries to configure target VM network settings automatically (emphasis on "tries" - usually needs manual tweaking afterward).

Current Version and Recent Updates

Currently at version 5.0. ARM64 support finally went GA back in March 2024 - only took them forever. Works for migrating ARM VMs from AWS and Azure, but test your shit first - learned the hard way that some apps have sneaky x86 dependencies buried in random libraries.

Supported ARM64 operating systems:

• Debian 11 and 12
• RHEL 9
• Rocky Linux 8 and 9
• SLES 15 SP5
• Ubuntu 20.04 and 22.04

Current capabilities:
Four migration source types (VMware vSphere, AWS EC2, Azure VMs, Google Cloud VMware Engine) with deep integration into Google Cloud services. Each migration path uses different APIs and has its own unique ways to break.

Recent feature additions (via release notes):

• Customer-Managed Encryption Keys (CMEK) support - finally, compliance people can shut up
• Enhanced network configuration handling - "enhanced" is doing a lot of work here
• Expanded OS support - now 75+ supported versions. Random custom Linux builds? Your mileage will vary
• VM expiration policies - they delete your test VMs after 100 days now, don't say I didn't warn you

Multi-Platform Source Support

Migrate to Virtual Machines works with four types of source environments: VMware vSphere, AWS EC2, Azure VMs, and Google Cloud VMware Engine. Each one sucks in its own special way:

VMware vSphere Integration:
Deploys the Migrate Connector appliance as an OVA file in your vCenter environment. No agents needed on individual VMs, which is nice. But if the connector loses connection to Google APIs, your whole migration stops. Fun.

The architecture consists of three main components: the vCenter environment running your source VMs, the Migrate Connector appliance deployed as an OVA, and the Google Cloud infrastructure handling replication and target VM creation.

AWS and Azure Integration:
Cloud platforms require lightweight agents on source VMs. These agents phone home to Google APIs to stream disk data. IAM permissions will bite you - get them wrong and the agents can't authenticate. Security groups also need to allow outbound HTTPS or your migration dies silently.

Migration Lifecycle Operations

The migration lifecycle follows a structured three-phase approach:

1. Replication Phase - Initial sync takes 3-5 days for a 1TB VM depending on your bandwidth. Network hiccups will pause and restart the process. Schedule during off-peak hours, but expect it to take longer than you think. Pro tip from painful experience: Set up monitoring for your replication progress. I've seen "completed" migrations missing 500GB because network hiccups weren't logged properly.

2. Test Clone Phase - This will save your ass. Use it to catch database connection string issues, licensing problems, and broken startup scripts. I've caught stuff here that would have taken down production. That time SQL Server licensing freaked out and wouldn't start after migration? Test clones caught it.

3. Cutover Phase - Final production migration typically completes within minutes to hours, depending on final synchronization requirements. Source VMs remain untouched throughout the process, providing rollback capabilities until explicitly decommissioned. The "automatic" network configuration works about 60% of the time. The other 40% requires manual IP fixes, DNS updates, and praying your load balancer still finds the VMs.

Security and Compliance Features

Encryption Management:
CMEK support went GA back in March 2024. If compliance is breathing down your neck about encryption, you can use your own KMS keys. Setup is a royal pain in the ass but beats explaining a data breach to auditors.

Network Security:
VPC Service Controls create security perimeters around migration resources, particularly valuable for regulated industries. Service perimeters restrict data movement and API access, providing additional compliance controls with network-level security boundaries.

Service account architecture includes a runtime service account for ongoing data transfer operations and a user account with administrative permissions used only during initial connector registration and setup.

Audit and Monitoring:
Audit logging integration with Cloud Audit Logs provides comprehensive activity tracking. All migration operations, configuration changes, and user actions are logged with timestamps and user attribution for compliance and troubleshooting purposes.

Performance Analysis and Cost Optimization

Utilization Reporting:
Utilization reports tell you which VMs are overpaid for. I've seen 40% cost reductions, but don't trust the recommendations blindly - pad your instance sizes by 20% because something always needs more resources than expected.

Monitoring Integration:
The migration service integrates with Google Cloud monitoring and management tools. Translation: you get some dashboards that might tell you what's happening, assuming the data actually updates correctly.

Automatic System Configuration:
The service installs the Google Guest Agent and tries to configure network settings automatically. Those "automatically configured" network settings usually need manual tweaking. I've seen migrations where the VM hostname was hardcoded in 47 config files - fun times debugging that at 2am.

Architecture Limitations:
Migration tools don't fix your shitty architecture - they just move it to the cloud. If your app was slow and poorly designed before migration, it'll be slow and poorly designed after migration, just with a Google Cloud bill attached.