Step-by-Step Guide: Migrating VMware Workloads to GCP

Ignore the myth: there’s no painless, one-click path from VMware to Google Cloud Platform (GCP). Successful migration demands comprehensive assessment, precise cutover execution, and in-depth understanding of both source and target architectures. Below—field-tested steps, sample tooling, practical deviations, and a few missteps to avoid.

Initial Assessment — Inventory and Dependency Mapping

Accurate workload inventory forms the foundation.

• Collect VM metadata. Extract current workloads from vSphere: VM name, vCPU count, memory, disk allocation, guest OS, VM Tools status, and NIC configurations.
  Use RVTools (v4.3 or later)—export XLS, don’t trust stale vCenter exports.
• Dependency mapping. Deploy application-level tracing or use Application Discovery Service if available. Don’t assume legacy naming conventions are meaningful—validate with real network captures.
• Version compatibility. Cross-reference OS and hypervisor versions against GCVE supported matrices. Non-supported OS targets (e.g., Windows Server 2008 R2) will require conversion or replacement.

Side Note: vSphere tags often miss critical infra-level dependencies (e.g., legacy license servers bound by MAC/IP).

Migration Architecture: GCVE Versus Compute Engine

GCVE (Google Cloud VMware Engine)

Dedicated VMware SDDC stack (vSphere, vSAN, NSX-T, vCenter) on GCP.
Maintain existing tools, scripts, admin model.

When to use:

• Tight coupling with on-prem services
• App-level refactoring blocked by technical debt or risk

Advantages:

• Minimal changes: Lift-and-shift, maintain UUID and MAC for legacy licensing.
• vMotion support: Live migrations with downtime measured in seconds.

Limitations:

• Higher per-VM cost versus native GCE
• GCVE regions still limited versus standard GCE

GCE (Google Compute Engine)

Migrate VMs as native GCP compute instances (custom or predefined machine types).

Use cases:

• Apps ready for cloud-native transformation (stateless, scalable)
• Need to leverage Managed Instance Groups, autoscaling, or integrate with GCP services (e.g., Cloud SQL)

How-to:

• Use “Migrate for Compute Engine” (formerly Velostrata), version 6.x+ recommended. Supports near-zero-downtime migration; cold cutover possible for batch or offline systems.
• Manual disk image conversion:
  1. Export VMDK from VMware datastore.
  2. Upload to GCS:
     bash gsutil cp disk.vmdk gs://bucket/
  3. Use gcloud compute images import to convert and create a bootable GCE image.

Known issue: Not all driver sets are compatible after conversion, especially for custom CentOS or Windows builds. Pre-inject GCP guest-agent where possible.

Preparing GCP: Networking, Access, Baseline Security

• Project isolation: Create dedicated projects—one for test/pilot, one for production migration.
• Networking: Mirror on-prem VPC constructs (CIDR, subnets, routes). Avoid overcommitting RFC1918 ranges. For hybrid scenarios, use Cloud Router + Partner Interconnect for predictable throughput.
  Example:

  Name: production-vpc
  Subnets: 10.50.0.0/20 (us-central1), 10.51.0.0/20 (us-east1)
  

• Firewall hardening: Explicitly define rules for migration traffic. Don’t rely on default-allow rules.
• Permissions: Apply IAM least privilege for automation and operators. Regularly audit with gcloud projects get-iam-policy.

Gotcha: GCP enforces project-level resource quotas; request lifts early—especially for external IPs and persistent disk throughput.

Data Migration: Consistency and Cutover

• GCVE: Use native vMotion for live migration. For bulk moves, Storage vMotion or third-party array replication (NetApp Cloud Volumes, Dell EMC RecoverPoint) provides consistency with minimal disruption.
• Compute Engine:
  • Live migration via Migrate for Compute Engine, supports streaming of disks and incremental sync. Plan cutover during maintenance window.
  • Cold migration: Detach and pre-copy disks, shut down source VMs, attach imported images.

Sample disk import error:

ERROR: Import failed: source disk size exceeds target machine type limit.

Some legacy VMs need resizing before exporting. Don’t skip disk cleanup.

Pilot First—Test, Validate, Adjust

Select 1–2 representative workloads with moderate complexity.

• Validate performance (CPU steal, disk latency) via Stackdriver Monitoring.
• Test service endpoints—use synthetic monitoring (curl, nmap) before production cutover.
• Implement and validate rollback (failback) process; document exact commands and timings.

Production Cutover: Orchestration & Alerting

Checklist:

1. Schedule during low impact windows. Always communicate downtime to business stakeholders—even for “live” approaches.
2. Perform final sync or delta copy, shut down original VM as last resort.
3. Update DNS, firewall, and routing (watch out for TTL propagation delay).
4. Post-migration: Validate logs, alerting, and synthetic checks for at least 24 hours.

Tip: Leverage “preemptible” GCE resources during migration for temporary workloads to control cost.

Post-Migration: Optimization and Refactoring

• Right-size instances: Use GCP’s Recommender or gcloud compute instances describe over time to adjust machine sizes.
• Modernize: Identify candidates for GKE (Kubernetes) or serverless transformation. Don’t overcommit—some workloads (e.g., stateful or Windows legacy) are best left as-is initially.
• Adopt managed services: Move from self-hosted SQL Server to Cloud SQL or Spanner where operational fit and licensing permit.

Common Migration Pitfalls and Avoidance

In Practice

In production environments, edge cases are the norm. An application reliant on static MACs for licensing may break if network hardware emulation shifts. Disk UUID mismatches can prevent clustered databases from restarting. Don’t skip the full shutdown/startup test, even if live vMotion seems perfect.

Summary

Migrating VMware estates to Google Cloud unlocks scalability, automation, and service integration—if the transition is engineered deliberately. Every phase, from dependency mapping to post-migration tuning, determines long-term project success and operational resilience. Standardized runbooks help, but application context and real-world testing drive repeatable reliability.

Practical Example:
A healthcare provider migrated 120+ Windows Server 2012 VMs via GCVE, retaining static IPs with custom ‘move groups’ to sequence DNS and firewall updates.
Actual downtime per critical application: <10 minutes (excluding some legacy print server quirks). GCVE handled legacy drivers’ idiosyncrasies; for a later phase, the same team used GCE replatforming for stateless APIs, reducing run costs by 35%.

Not perfect:
Some workloads needed manual DLL injection and OS sysprep despite GCVE “compatibility.” No automation tool caught every outlier.

Let engineering reality, not slides, shape the project. For robust transitions, gather logs, test the edge paths, and always expect “one more thing” before signing off.