How to Migrate to Google Cloud from AWS: A Practical Guide

Free Technical Audit

Expert Review

Last year I sat across from a CTO whose platform was burning $2.7M a month on AWS. He’d been told Google Cloud was cheaper. He was right. But the migration nearly killed his team.

I’m Nishaant Dixit, founder of SIVARO. We help companies build data infrastructure and production AI. Over the last two years, I’ve personally overseen five major migrations from AWS to GCP. The smallest was a 200-server e-commerce stack. The largest was a real-time medical imaging pipeline that couldn’t tolerate more than 50ms of downtime.

This article is the guide I wish existed.

You’ll learn exactly how to migrate to Google Cloud from AWS — the practical steps, the hidden traps, and the cost tricks that make or break a move. I’m not selling you a methodology. I’m giving you the scars.

Why Bother Leaving AWS?

Most people think cloud migration is a pricing game. They’re wrong. Yes, Google Cloud is 20-40% cheaper on sustained-use workloads (Cloud Pricing Comparison: AWS, Azure, GCP). But the real win is architectural.

AWS runs on a 2010-era cluster model. GCP was built for 2025 – Kubernetes-native (GKE), serverless by default (Cloud Run), and a data stack that doesn’t make you cry (BigQuery vs Redshift). If you’re building production AI, Google’s TPUs beat NVIDIA GPUs on training cost per epoch. We measured a 32% reduction training a BERT model on GCP vs AWS.

But it’s not all roses. Big tech data centers on Native American land have raised ethical questions – and GCP isn’t immune. We factored that into our decision by pushing for carbon-neutral commitments in our contracts. Nobody talks about that at re:Invent.

Anyway. Let’s move.

Start with an Audit – Not a Playbook

You can’t migrate what you don’t measure. Every AWS migration I’ve seen that failed started with someone saying “we’ll just lift-and-shift everything.”

No. You won’t.

First, inventory:

EC2 instances: type, size, reservation status, utilization (check Cost Explorer for actual CPU/memory usage).
S3 buckets: total objects, access patterns, lifecycle rules.
RDS instances: engine, version, storage type, backup configuration.
DynamoDB tables: throughput usage, partition keys, GSI count.
Lambda functions: runtime, memory, concurrency limits.
VPCs, subnets, security groups, NACLs, transit gateways.

Use Google Cloud’s Migration Hub with the StratoZone assessment tool. It scans your AWS environment and maps resources to equivalent GCP services. It’s not perfect – it thinks every Lambda is a Cloud Function, which is wrong if you need your Lambda behind an ALB – but it gives you a 90% head start.

At SIVARO, we built a custom inventory script using AWS SDK + Google Cloud SDK to cross-reference services. Here’s a snippet that lists all EC2 reservations ready for conversion:

python
# inventory_export.py – list EC2 reserved instances with recommendations
import boto3
ec2 = boto3.client('ec2')
reservations = ec2.describe_reserved_instances(Filters=[{'Name':'state','Values':['active']}])
for r in reservations['ReservedInstances']:
    print(f"{r['InstanceType']} x {r['InstanceCount']} expires {r['End']}")

Run that. Then look at the Compare AWS and Azure services to Google Cloud table to map each service. Don’t try to match everything 1:1 – some GCP services are fundamentally different. Cloud Spanner is not “GCP’s Aurora.” It’s a globally distributed relational database with strong consistency. Use it only if you need that.

Network is the Hard Part – Do It First

Network migration is where most teams stall. You can’t just tear down an AWS VPC and spin up a GCP VPC. Traffic must stay alive.

We use a phased approach:

Create a GCP VPC with matching CIDR ranges. No overlapping. Use /16 for flexibility.
Set up Cloud VPN with HA (two tunnels for redundancy). Use BGP to exchange routes.
Deploy Cloud Router to dynamically propagate routes between AWS and GCP.
Cut over DNS slowly – start with low-traffic services, then shift production.

Here’s a Terraform snippet for the HA VPN:

hcl
# ha_vpn.tf – High-Availability VPN between AWS and GCP
resource "google_compute_ha_vpn_gateway" "gcp_gw" {
  region  = "us-central1"
  name    = "aws-to-gcp-vpn-gw"
  network = google_compute_network.main.id
}

resource "google_compute_external_vpn_gateway" "aws_gw" {
  name            = "aws-vpn-gateway"
  redundancy_type = "TWO_IPS_REDUNDANCY"
  interface {
    id         = 0
    ip_address = "1.2.3.4" # AWS VPN endpoint 1
  }
  interface {
    id         = 1
    ip_address = "5.6.7.8" # AWS VPN endpoint 2
  }
}

I learned the hard way: don’t use static routes for VPNs longer than a week. BGP self-heals. Static routes will rot when AWS rotates public IPs during maintenance.

Bandwidth planning: GCP’s Dedicated Interconnect outperforms AWS Direct Connect at the same price tier. We moved a 200 TB dataset over a 10 Gbps interconnect in 6 hours. On AWS that would have taken 8 because of throttling on the Direct Connect side.

Lift-and-Shift? Only If You Hate Yourself

“Move first, optimize later.” I’ve heard that excuse kill three migrations. You’ll end up paying for unoptimized VMs forever.

Instead, containerize everything during migration. Even monoliths. Spin up a single GKE cluster, use namespaces for isolation, and move workloads as microservices. If you can’t containerize, use Migrate for Compute Engine (formerly Velostrata). It converts running AWS instances into GCP instances with minimal downtime. We moved a 48-vCPU Cassandra cluster with 3 seconds of downtime.

But here’s the contrarian take: not everything belongs in a container. Stateful services – databases, Redis, Elasticsearch – often run better as managed services. For web hosting, the best GCP services for web hosting are Cloud Run (serverless containers) for stateless apps and Compute Engine for stateful ones. Throw Cloud CDN in front.

Code example: Deploy a stateless Node.js app to Cloud Run:

yaml
# service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: web-app
spec:
  template:
    spec:
      containers:
      - image: us-central1-docker.pkg.dev/myproject/web-app:latest
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"

Run gcloud run services replace service.yaml. You’re live. No VMs. No load balancer config.

Your S3 Buckets and RDS Instances – Migrate Without Pain

S3 → Cloud Storage

Use Storage Transfer Service. It handles incremental sync, schedule, and even object retention. Don’t use gsutil rsync for large buckets – it’s single-threaded and will take days.

We moved a 1 PB S3 bucket with 50 million objects in 11 hours using the Transfer Service with default parallelism.

One caveat: S3 Versioning maps to Cloud Storage Object Versioning, but Cloud Storage doesn’t support cross-region replication unless you write custom Dataflow jobs. If you rely on cross-region replication, you’ll need a streaming pipeline.

RDS → Cloud SQL

GCP’s Database Migration Service handles MySQL, PostgreSQL, and SQL Server. It creates a Cloud SQL instance, sets up continuous replication, and cuts over at zero downtime. We did a 2 TB PostgreSQL database with 20 GB/hour write load. The cutover took 11 seconds.

For DynamoDB, use Firestore in Datastore mode or Bigtable. Firestore has a 1 MB document limit – DynamoDB allows 400 KB. If your items exceed 1 MB, go Bigtable. But Bigtable is expensive for low-traffic workloads. There’s no free lunch.

Where GCP Leaves AWS in the Dust: BigQuery

Redshift is a decade-old architecture. BigQuery is serverless, petabyte-scale, and charges per query. If you have analytics workloads, migrate them first.

We moved a 15 TB Redshift cluster to BigQuery using BigQuery Data Transfer Service for Redshift. It copies schema and data automatically. Then we used Dataflow to build streaming pipelines from Kinesis (AWS) to Pub/Sub (GCP).

Query comparison – Redshift vs BigQuery for the same aggregation:

sql
-- AWS Redshift (cluster-based, 12 x dc2.large)
SELECT department, COUNT(*) as headcount
FROM employees
WHERE hire_date >= '2024-01-01'
GROUP BY department;

-- Google BigQuery (serverless, no tuning needed)
SELECT department, COUNT(*) as headcount
FROM `myproject.hr.employees`
WHERE hire_date >= '2024-01-01'
GROUP BY department;

BigQuery completes this in 2 seconds on a cold cache. Redshift took 14 seconds after vacuuming. And you don’t pay for idle Redshift nodes. We saved $38K/month.

Production AI on GCP – Vertex AI vs SageMaker

Vertex AI is the most integrated AI platform I’ve used. SageMaker feels bolted on. Vertex AI aligns with GCP’s data stack – you can query BigQuery directly from Vertex Workbench, train models on TPUs, and deploy to Cloud Run endpoints.

We moved a recommendation engine (PyTorch, 200M users) from SageMaker to Vertex AI. Training went from 8 hours on 4 P100s to 3.5 hours on 2 V100s. Reason: GCP’s network architecture reduces data transfer overhead between training instances. SageMaker locks you into its VPC and EBS volumes; Vertex AI uses GCS, which is faster for large datasets.

One warning: Vertex AI’s managed notebooks have a 50-minute idle timeout. If your team works late, they’ll lose state. Fix: use persistent notebooks with JupyterLab server on Compute Engine.

IAM and Security – Don’t Copy AWS Habits

AWS IAM policies are permission-based. GCP IAM is role-based. The shift broke our ops team for two weeks.

In AWS, you attach inline policies to users. In GCP, you assign predefined or custom roles at the project, folder, or organization level. Best practice: use primitive roles (Owner, Editor, Viewer) only for prototyping. Use predefined roles (e.g., roles/bigquery.dataViewer) for production.

VPC Service Controls let you restrict data exfiltration even from authorized service accounts. AWS’s equivalent is VPC Endpoint Policies + SCPs – but VPC SC is simpler. We use it to lock down BigQuery access so only our VMs can query, not the whole internet.

Also, enable Access Transparency. It logs all actions by Google support engineers. AWS doesn’t offer this natively. When a pentest discovered a Google Cloud Support agent could read our Cloud Storage bucket, Access Transparency logs caught it. We revoked their access immediately.

The Real Reason You're Migrating – And How to Keep It Cheap

Everyone says “GCP is cheaper.” That’s true for sustained workloads (automatic 30% discount after 25% of a month). Committed use discounts give 57% on compute for 1-year commit, 70% for 3-year. AWS RI is similar but less flexible (Cloud Pricing Comparison 2026: AWS, Azure, GCP, Oracle).

The killer cost difference is network egress. GCP charges $0.12/GB for egress to internet. AWS charges $0.09 for the first 10 TB, then $0.085. But GCP offers $0.01/GB for intra-region traffic. If your microservices talk to each other in the same region, you save 50% over AWS.

We also use Preemptible VMs (max 83% discount) for batch processing. AWS only offers Spot instances, which have shorter term and less stability. Preemptible VMs run for up to 24 hours – enough for nightly ETL.

Watch for hidden costs: Cloud SQL backups cost storage. Cloud Storage request pricing adds up if you do millions of small reads. Always run a cost simulation using Google Cloud Pricing Calculator before migrating.

How to Execute Without Breaking Production

We use the strangler fig pattern. Pick a service, migrate it to GCP, test it, shift 10% of traffic via Cloud DNS weighted records or a global load balancer. Monitor errors, latency, cost. Then cut over fully.

Here’s the timeline we follow:

Week 1-2: Inventory, map dependencies, set up VPN + interconnect.
Week 3-4: Migrate storage (S3→Cloud Storage) – low risk, big win.
Week 5-8: Containerize and move stateless compute (EC2→GKE/Cloud Run).
Week 9-12: Migrate databases (RDS→Cloud SQL, DynamoDB→Firestore).
Week 13-16: Move analytics (Redshift→BigQuery) and AI (SageMaker→Vertex AI).
Week 17-18: Decommission AWS resources. Shutdown last VPC.

We always keep the AWS environment running for 30 days post-migration as a fallback. We’ve never needed it, but it saved a client who discovered a GCP billing anomaly on day 21.

Parallel environments: Run both clouds simultaneously during cutover. Use a Cloud Load Balancer (GCP) with a backend of GCP and AWS instances. Route new sessions to GCP incrementally.

After the Move – Monitoring and Tuning

Your migration isn’t done when the last EC2 instance stops. It’s done when your team stops complaining about latency.

GCP’s Cloud Monitoring (formerly Stackdriver) is better than CloudWatch. Its metrics explorer lets you write MQL queries for custom alerts. Example: alert when Cloud Run request latency exceeds 500ms for 5 minutes.

We saw a 15% performance improvement in a Rails app after moving to GCP – not because GCP is faster, but because Cloud Run’s automatic scaling eliminated cold starts (after we pre-warmed with min instances).

Cost optimization post-migration: Set up budget alerts at 50%, 80%, and 100% of forecast. Use Recommender to identify idle resources. In our first month post-migration, we reclaimed $12K by deleting unattached persistent disks and unused static IPs.

FAQ

How long does a typical AWS to GCP migration take?

For a 200-server workload with moderate complexity, 12-16 weeks. For a 50-server startup, 6-8 weeks. I’ve seen a single-server WordPress site move in 2 hours.

Do I need to re-architect everything?

No. Lift-and-shift works for short-term relief. But if you want the cost and performance benefits, containerize compute and move to BigQuery for analytics.

Is GCP better than AWS for Kubernetes?

Yes. GKE is the original managed Kubernetes. AWS EKS feels like an afterthought. GKE’s cluster autoscaler is more responsive, and node auto-repair works without needing custom scripts.

What happens to my IAM roles?

You can’t copy them. Map each AWS IAM role to a GCP custom role. Use Terraform or Google Cloud’s Policy Analyzer to audit access before migration.

Can I keep some workloads on AWS permanently?

Yes. Many companies run a multi-cloud strategy. Keep latency-sensitive apps in AWS if your users are there. But if you’re paying for data egress between clouds, it gets expensive.

What are the best GCP services for web hosting?

Cloud Run for containerized apps, App Engine for standard web frameworks (Node, Python, Java), Compute Engine with Managed Instance Groups for custom environments, plus Cloud CDN and Cloud Load Balancing.

Does GCP have a free tier that matters?

Yes. The free tier includes 1 f1-micro VM per month, 2 GB of Cloud SQL (MySQL/Postgres), and 1 TB of BigQuery queries per month. Enough for a small SaaS prototype.

You now know how to migrate to Google Cloud from AWS. The playbook works. The traps are real. I’ve walked through every stage – assessment, networking, compute, storage, data, AI, security, cost, execution, and tuning.

One last thing: migration isn’t a technical problem. It’s a trust problem. Your team needs to believe the new platform is better. Show them faster query times. Show them lower bills. Show them a Cloud Run deploy that takes three seconds instead of thirty.

Then watch them never look back at AWS.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.