Step-by-Step Guide: Migrating Workloads from Azure to Google Cloud with Minimal Downtime

Seamless migration between major cloud providers isn’t theoretical—it’s a routine necessity as platform capabilities, pricing, and business strategies evolve. Downtime and unexpected compatibility issues remain the primary risks; tackling them requires methodical assessment and a solid grasp of tooling on both sides.

Inventory and Dependency Mapping

Blind migrations fail fast. Start with a complete inventory of:

• Virtual machines (OS type, instance sizes, attached managed disks)
• Storage accounts (provisioned capacity, blob tiering, access policies)
• Databases (engine, version, performance tier, geo-replication)
• Network architecture (VNets, subnets, peering, public/private endpoints)
• Application topology (internal/external APIs, load balancers, PaaS dependencies)

Dependency mapping is non-negotiable. Don’t trust infrastructure diagrams—check live runtime service maps or use Azure Resource Graph. Discover blind dependencies using network flow logs.

Example:
A typical workload:

• Azure App Service for web front-end
• Azure SQL Database v12
• Blob Storage for user uploads
• Azure Redis Cache (if overlooked, session stickiness breaks during migration)

Prioritize assets. Mission-critical (customer-facing, transactional) workloads demand near-zero downtime. Batch jobs or analytics can tolerate longer cutovers.

Target Architecture Design

Mirror Azure constructs on GCP—rarely 1:1, often nuanced. Simple mapping table:

Tip: Not all SKUs available. Known issue—Cloud SQL supports SQL Server up to version 2022 only (as of 2024-06).

Hybrid Networking Setup

Preserving data integrity during migration means building a secure and high-throughput bridge.

• Site-to-Site VPN: Quickest to set up, ~1 Gbps throughput. Latency variable.
• Dedicated Interconnect: For sustained, high-volume migration. Lead time: 1–2 weeks for provisioning by Google or partners.
• Firewall rules: Explicitly allow subnets used by migration tools (avoid 0.0.0.0/0 rules).

Sample VPN diagram:

[Azure VNet]----(VPN Gateway)====(Cloud VPN)----[GCP VPC]

Encrypted tunnels carry migration traffic. Test IP reachability with ping and port checks before progressing.

Data Migration: Engineered for Precision

Databases:
Use Database Migration Service (DMS) for transactional DBs. DMS handles continuous (CDC-based) replication but can expose corner cases:

• Azure SQL -> Cloud SQL:

  1. Confirm source compatibility (SELECT @@VERSION).
  2. Create a DMS migration job, select continuous transfer.
  3. Set up DB users in Cloud SQL to match, or map roles as needed.
  4. Monitor for lags; DMS UI reports replication delay in seconds.

• Gotcha: Long-running transactions or unsupported data types can halt replication.

  • Check logs:

    [2024-06-03 11:01:08] ERROR: Cannot replicate CLR type 'Geography'
    

Storage:

• Use azcopy for Azure → local or VMs, and gsutil for transfer to GCP. Don’t underestimate egress costs or API throttling.

# Azure to local
azcopy cp "https://<account>.blob.core.windows.net/<container>/<prefix>*" ./localdata --recursive

# Local to GCP
gsutil -m rsync -r ./localdata gs://<bucket>

Alternatively, run an object-to-object copy directly if cross-cloud access is enabled (few security shops will allow this).

• Snapshot at start
• Incremental syncs (daily/hourly)
• Schedule freeze for final delta

Migrating Containerized Workloads

Container registries diverge in authentication and naming. Steps:

1. Authenticate and pull images from Azure Container Registry (ACR):

   az acr login --name myacr
   docker pull myacr.azurecr.io/api-service:v2.5.0
   

2. Tag and push to Google Container Registry (GCR) or Artifact Registry:

   docker tag myacr.azurecr.io/api-service:v2.5.0 gcr.io/my-gcp-project/api-service:v2.5.0
   docker push gcr.io/my-gcp-project/api-service:v2.5.0
   

3. Migrate YAMLs/Helm charts for deployment on GKE.

• Update image URIs and secrets.
• Test Kubernetes 1.28+ manifest compatibility; not all Azure-specific features have GKE equivalents.
• Roll out via blue/green or canary deployments for validation.

Tip: Set up Workload Identity for GCP-native auth—don't recycle Azure service principals.

End-to-End Validation

Critical to QA in situ—not just in isolation.

• Spin up a staging environment on GCP mirroring live configs.
• Smoke test each microservice: simulate auth, file upload, API chaining.
• Run load and soak tests (k6, locust) to identify hidden bottlenecks—network egress policies or cold-start anomalies often surface here.
• Validate observability stack: forwarding of logs/metrics to GCP’s operations suite. Legacy alerts may require rewiring.

Cutover Strategy and DNS Transition

For ultra-short outage:

1. Freeze writes—block new sessions in source app, or switch to maintenance mode.
2. Final data sync: Catch up CDC or last file/cached object batch.
3. Environment variable switch: Repoint endpoints, keys, connection strings.
4. DNS cutover:
   • Lower TTL at least 24h prior (<300 seconds ideal).
   • Flip A or CNAME records to GCP-load balancer frontends.
   • Monitor for stale connections. Some clients cache even after TTL expires.
5. Monitor for errors in both application and migration logs.
   • Sample:

     ConnectionError: Failed to connect to Cloud SQL at 10.118.2.5
     

Can’t freeze writes? Consider dual-write logic or phased user migration—but complexity and risk multiply rapidly.

Post-Migration: Clean Up, Optimize, Stabilize

• Careful Deletion: Archive/backup before deleting Azure resources. Retention policies may delay full cost shutoff.
• Rightsize: Use Google Recommender (gcloud recommender) to detect overprovisioned VMs.
• Explore GCP-exclusive features:
  • BigQuery for multi-TB analytics
  • AI/ML workloads distributed in Vertex AI
• Audit IAM: Strip unused accounts/roles to avoid permission drift.

Side note: Some orgs maintain minimal “anchor” Azure workloads for hybrid resilience—especially around AD/multi-cloud identity. There’s no need to go absolute-zero on day one.

Summary

Cloud migrations aren’t magic, but they’re never trivial either. Ignore vendor diagrams—focus on real data, observed dependencies, and native tools: DMS, gsutil, container registry workflows, detailed validation. When in doubt, start with a non-critical workload; review post-mortems from each phase.

Questions about specific heterogenous stacks (e.g., Cosmos DB, Event Grid, AKS-to-GKE migration)? Open to trade notes—there’s always edge cases.

No migration finishes perfectly; only safely and with lessons captured.