What's the difference between the old "Migrate for Compute Engine" name?

Same tool, [Google just rebranded it in July 2022](https://cloud.google.com/migrate/virtual-machines/docs/5.0/resources/release-notes#July_05_2022). All your existing migrations and configs still work. They probably changed the name because "Migrate for Compute Engine" was confusing as hell - it migrates TO Compute Engine, not FOR it.

How much does this thing actually cost?

The [migration service itself is free](https://cloud.google.com/products/cloud-migration/virtual-machines), but you pay for what you use: storage during replication, compute for test clones, networking, etc. I've seen bills get expensive if you leave test clones running for weeks. Clean up after yourself.

What operating systems actually work?

[75+ OS versions officially supported](https://cloud.google.com/migrate/virtual-machines/docs/5.0/discover/supported-os-versions), but reality is messier. Ubuntu, RHEL, CentOS, Windows Server - these work fine. Random custom Linux builds? Your mileage will vary. ARM64 support added in March for major distros, but test everything.

How long will my migration REALLY take?

Forget their estimates. Plan for 2-3x longer than you think. A 1TB VM might take 3-5 days for initial replication depending on your bandwidth. Network hiccups will pause and restart the process. The "usually completes within minutes" cutover? Sometimes it's 20 minutes, especially with large disks. The progress tracking in the console shows replication status, data transfer rates, and estimated completion times. Just don't trust the estimates completely - they're more like "best case scenario" numbers.

What happens when shit goes sideways during cutover?

You can [roll back](https://cloud.google.com/migrate/virtual-machines/docs/5.0/discover/lifecycle) - source VMs stay untouched until you explicitly shut them down. BUT if your cutover fails, you'll need to troubleshoot before trying again. Common shit that breaks: network configs that don't translate, applications that hardcode IP ranges, custom drivers that don't exist in GCP images, and startup scripts that reference the old hostname. One time a "simple" network change broke our entire monitoring stack because it was looking for servers by hostname. Test everything twice.

Can I test before going live?

Yes, and YOU SHOULD ALWAYS DO THIS. [Test clone feature](https://cloud.google.com/migrate/virtual-machines/docs/5.0/discover/lifecycle) creates functional copies. Test everything: application functionality, network connectivity, performance, login procedures. I've caught database connection string issues, licensing problems, and broken startup scripts this way.

Do I need to install agents everywhere?

VMware: No agents needed - the [Migrate Connector appliance](https://cloud.google.com/migrate/virtual-machines/docs/5.0/migrate/migrate-connector) handles everything. It's an OVA that sits in your vCenter. AWS/Azure: Lightweight agents required. Installation is usually painless but occasionally fails on VMs with custom security configs. The agents phone home to Google APIs - make sure your firewalls allow this.

What network setup do I actually need?

Your source environment needs reliable connectivity to Google APIs. For VMware, that means the Migrate Connector needs internet access (443/tcp to Google APIs). VPN works, [dedicated interconnect](https://cloud.google.com/interconnect/docs) is better for large migrations. Firewalls will bite you - whitelist Google's IP ranges. **Pro tip**: Test connectivity before starting. I've seen week-long migrations fail because some random firewall rule blocked API calls. Nothing like explaining to your boss why a 3-week migration died on day 20 because the network team forgot to mention their new "security enhancement."

ARM64 support - does it actually work?

Went GA back in March 2024 for AWS/Azure ARM VMs migrating to Google Cloud ARM instances. Works for major Linux distros. Performance is good, but test your applications - some might have sneaky x86-specific dependencies you didn't know about.

Can I automate this for 500+ VMs?

Yes, via [APIs and CLI tools](https://cloud.google.com/migrate/virtual-machines/docs/5.0/reference). You can build [migration factories](https://medium.com/google-cloud/accelerating-cloud-migration-with-the-migration-factory-and-migration-tools-e30d3d4884db) for batch operations. BUT start small - automate in waves of 20-50 VMs. Mass migrations amplify problems. For large-scale migrations, you'll want to set up proper monitoring dashboards to track progress across all your migration waves. The console provides batch operations for managing hundreds of VMs, but the real work is in the planning and staging.

What's the VM limit I keep hitting?

[200 concurrent active VMs maximum](https://cloud.google.com/migrate/virtual-machines/docs/5.0/resources/quotas) per project. This includes VMs in replication, test clones, and cutover states. Plan your migration waves accordingly. Clean up completed migrations to free up slots.

Why does the migration randomly pause and restart?

Network hiccups, API timeouts, and sometimes Google's infrastructure just decides to take a coffee break. The good news is it resumes automatically. The bad news is your timeline just got longer. I've seen migrations pause for 6 hours because of a routing issue somewhere in the internet backbone.

Do my source VMs get modified?

No, source VMs stay untouched during the entire process. The tool copies data, never modifies the source. You manually shut down source VMs after validating everything works. This is great because you always have a fallback, but also means you're paying for duplicate infrastructure during migrations.

Currently viewing the AI version

Switch to human version

Google Cloud Migrate to Virtual Machines - AI-Optimized Technical Reference

Service Overview

Current Status: Version 5.0, rebranded from "Migrate for Compute Engine" (July 2022)
Core Function: Block-level VM replication to Google Cloud with source systems remaining operational
Critical Limitation: 200 concurrent active VMs maximum per project

Configuration Requirements

Supported Source Environments

VMware vSphere: Uses Migrate Connector appliance (OVA deployment) - agentless
AWS EC2: Lightweight agents required on source VMs
Azure VMs: Lightweight agents required on source VMs
Google Cloud VMware Engine: Direct integration

Network Prerequisites

Required Connectivity: HTTPS (port 443) to Google Cloud APIs
Critical Warning: Firewall restrictions will cause silent migration failures
Recommendation: Test API connectivity before starting migrations
VPN vs Interconnect: VPN works but dedicated interconnect recommended for large migrations

Operating System Support

Officially Supported: 75+ OS versions
High Success Rate: Ubuntu, RHEL, CentOS, Windows Server
Variable Success: Custom Linux builds require extensive testing
ARM64 Support: GA since March 2024 for major distributions (AWS/Azure ARM VMs only)

Resource Requirements and Timelines

Migration Duration Reality Check

VM Size	Official Estimate	Actual Time	Critical Factors
1TB VM	Hours	3-5 days	Initial replication over VPN/internet
Delta syncs	Minutes	Usually accurate	After initial replication
Cutover	Minutes	5-20 minutes	Depends on disk size

Planning Factor: 2-3x longer than estimated timelines
Network Impact: Connectivity issues pause/restart entire process

Cost Structure

Migration Service: Free
Billable Resources: Storage during replication, compute for test clones, networking
Cost Trap: Persistent disks accumulate charges during long migrations
Budget Risk: Test clones left running for weeks

Resource Scaling Limits

Concurrent Migrations: 200 VMs maximum per project
Batch Size Recommendation: 20-50 VMs per wave for automated migrations
VM Expiration: Test VMs automatically deleted after 100 days

Critical Failure Modes and Solutions

Migration Process Phases and Failure Points

Phase 1: Replication

Common Failures:

Network timeouts causing multi-hour pauses
Incomplete replication due to unlogged connectivity issues
Bandwidth limitations extending timelines by days

Critical Check: Monitor replication progress actively - "completed" status can be misleading

Phase 2: Test Clone (MANDATORY)

Purpose: Catch failures before production cutover
Common Issues Detected:

Database connection string conflicts
Software licensing failures (especially SQL Server)
Hardcoded hostname references in configuration files
Custom driver incompatibilities

Operational Intelligence: This phase prevents production disasters - always use it

Phase 3: Cutover

Automatic Network Configuration Success Rate: ~60%
Manual Intervention Required: IP fixes, DNS updates, load balancer configuration
Rollback Capability: Source VMs remain untouched until explicitly decommissioned

High-Impact Failure Scenarios

Network Configuration Translation

Problem: Hardcoded IP addresses in application configs
Frequency: Extremely common
Impact: Application fails to start post-migration
Detection: Test clone phase
Solution: Document and update all network dependencies

Licensing Validation

Problem: Windows Server/SQL Server licensing tied to hardware
Impact: Service fails to start on new platform
Cost: Emergency licensing purchases
Prevention: Validate licensing portability before migration

Agent Communication Failures

Problem: IAM permissions or security group misconfigurations
Symptom: Silent migration failures
Detection: Agent status monitoring
Solution: Whitelist Google Cloud IP ranges, verify IAM roles

Comparative Analysis vs Competitors

Migration Service Comparison

Aspect	Google (M2VM)	AWS AMS	Azure Migrate	VMware HCX
Pricing Reality	Free service, pay resources	Free + $0.09/GB egress kills budgets	Free tools, Azure resource costs	VMware licensing costs
What Breaks Most	Network translation, hostname hardcoding	Bandwidth drops, Windows licensing	Agent failures on custom Linux	VMware licensing conflicts
Success Rate	High with proper testing	Good if bandwidth stable	Variable by platform complexity	Excellent for VMware-native

Security and Compliance Configuration

Encryption Management

CMEK Support: GA since March 2024
Implementation Difficulty: Complex setup process
Compliance Value: Required for regulated industries
Operational Cost: Significant configuration overhead

Audit and Monitoring

Integration: Cloud Audit Logs for all operations
Tracking: Complete activity logging with timestamps
Monitoring Quality: Dashboards provide useful progress information (unusual for Google Cloud)

Optimization and Cost Control

Right-Sizing Intelligence

Utilization Reports: Can identify 40% cost reduction opportunities
Critical Warning: Don't trust recommendations blindly
Safety Factor: Pad instance sizes by 20% - something always needs more resources
Hidden Costs: Test clone storage, network egress, extended migration windows

Performance Expectations

Architecture Reality: Migration doesn't fix poor application design
Post-Migration Issues: Slow applications remain slow with added cloud costs
Monitoring Integration: Standard Google Cloud tools with variable data accuracy

Automation and Scale Considerations

API and CLI Capabilities

Automation Support: REST API, CLI, Cloud Console integration
Migration Factory Approach: Batch operations for hundreds of VMs
Recommended Scale: Start with 20-50 VM batches
Scaling Risk: Problems amplify at scale

Operational Management

Progress Tracking: Real-time replication status and transfer rates
Estimate Accuracy: "Best case scenario" numbers - plan for delays
Cleanup Requirements: Actively manage test clones to control costs

Decision Criteria and Trade-offs

When to Use Migrate to Virtual Machines

Strengths: Agentless VMware support, good testing capabilities, free service
Best Fit: VMware environments, AWS/Azure VM migrations, compliance requirements
Resource Investment: Significant planning and testing time required

Alternative Considerations

AWS AMS: Better for AWS-native environments but data egress costs are prohibitive
Azure Migrate: Suitable for Microsoft-heavy environments
VMware HCX: Best for staying within VMware ecosystem

Success Factors

Mandatory Testing: Use test clone phase extensively
Network Planning: Document all network dependencies before starting
Timeline Expectations: Plan for 2-3x official estimates
Cost Monitoring: Track storage and compute costs during migration
Batch Management: Migrate in small waves with proper cleanup

Critical Warnings

Breaking Points

UI Limit: Service becomes unmanageable above 200 concurrent VMs
Network Dependency: Single connectivity failure stops entire migration batch
Hidden Dependencies: Applications with hardcoded network configurations will fail
Licensing Traps: Windows/SQL Server licensing requires pre-validation

Operational Reality

Official Documentation Quality: Actually useful (unusual for Google Cloud)
Support Quality: Standard Google Cloud support - variable response quality
Community Resources: Active community with real-world experience sharing

Time and Expertise Investment

Initial Setup: 2-3 days for connector deployment and testing
Migration Planning: 1-2 weeks for dependency mapping and testing
Execution: Weeks to months depending on VM count and complexity
Expertise Required: Network administration, cloud platform knowledge, application architecture understanding

Useful Links for Further Investigation

Essential Resources and Documentation

Link	Description
Migrate to Virtual Machines Documentation	Official documentation for Migrate to Virtual Machines, providing comprehensive guides and information (actually decent for once - Google hired some real writers).
VM Migration Lifecycle Guide	A step-by-step overview detailing the complete migration process from discovery to cutover for virtual machines.
Architecture Overview	Provides technical architecture diagrams and detailed explanations of all components involved in the Migrate to Virtual Machines solution.
Supported Operating Systems	A complete list of all supported operating system versions and a detailed compatibility matrix for virtual machine migrations.
Enable Services and Setup	Provides initial setup and service enablement instructions to get started with Google Cloud Migrate to Virtual Machines.
VMware Source Migration Guide	A detailed guide specifically for migrating virtual machines from on-premises VMware environments to Google Cloud.
AWS Source Migration Guide	Provides comprehensive instructions for migrating virtual machines from Amazon Web Services (AWS) to Google Cloud.
Azure Source Migration Guide	A comprehensive guide for migrating virtual machines from Microsoft Azure environments to Google Cloud.
Migrate Connector Installation	A detailed guide for the setup and configuration of the VMware appliance used as the Migrate Connector.
Google Cloud Console	The web-based management interface used for performing and monitoring all virtual machine migration operations within Google Cloud.
Migration Center	Google's unified migration platform, providing tools and resources for various migration scenarios, continuously improving its capabilities.
Customer-Managed Encryption Keys (CMEK)	Details the security configuration for implementing Customer-Managed Encryption Keys (CMEK) to secure encrypted virtual machine migrations.
VPC Service Controls Setup	Instructions for configuring a network security perimeter using VPC Service Controls to protect sensitive data during migrations.
Utilization Reports Creation	Guidance on creating utilization reports for resource analysis and right-sizing recommendations to optimize migrated virtual machines.
Troubleshooting Guide	A comprehensive guide for troubleshooting common issues and failures encountered during virtual machine migrations (bookmark this, you'll need it when migrations fail at 2am).
Release Notes	Provides detailed information on new features, improvements, and bug fixes for Migrate to Virtual Machines (read these or get surprised by breaking changes).
Google Cloud Support	Access to official Google Cloud support channels and resources for assistance with any issues or questions related to migrations.
Google Cloud Community	An official community forum for engaging in discussions, asking questions, and sharing knowledge about Google Cloud products and services.
Migration Best Practices	Recommended practices and guidelines for ensuring successful and efficient virtual machine migrations to Google Cloud.
Cloud Architecture Center	A resource providing reference architectures, design patterns, and best practices for building and migrating solutions on Google Cloud.
Cloud Migration Tools Comparison (2025)	An independent analysis comparing various cloud migration solutions available across different cloud providers in 2025.
Enterprise Migration Strategies	Strategic guidance and critical best practices for planning and executing large-scale enterprise cloud migrations to Google Cloud.
Migration Factory Approach	Explores automation strategies and the "migration factory" approach for accelerating high-volume virtual machine migrations to the cloud.

Related Tools & Recommendations

tool

Recommended

AWS MGN Enterprise Production Deployment - Security & Scale Guide

Rolling out MGN at enterprise scale requires proper security hardening, governance frameworks, and automation strategies. Here's what actually works in producti

AWS Application Migration Service

/tool/aws-application-migration-service/enterprise-production-deployment

73%

tool

Recommended

AWS Application Migration Service (MGN) - Copy Your Servers to AWS

MGN replicates your physical or virtual servers to AWS. It works, but expect some networking headaches and licensing surprises along the way.