I've Migrated 15 Production Systems from AWS to GCP - Here's What Actually Works

The Truth About AWS Discovery Tools

Forget AWS Application Discovery Service - it's garbage. I spent 2 weeks waiting for it to map dependencies only to discover it missed half our services and flagged a Redis cache as a "critical database dependency."

Instead, SSH into every box and run these commands:

• df -h - see what storage you're actually using
• free -m - check memory allocation vs what AWS thinks you need
• netstat -tulpn - find what services are talking to what (or use ss on newer systems)
• systemctl list-units --type=service --state=running - see what's actually running

Takes maybe 2 hours vs the bullshit discovery process consultants wanted to charge us - what was it, like 50 grand? For a fucking Excel sheet.

What You'll Actually Find During Assessment

Compute Resources

Half your EC2 instances are over-provisioned because "we needed them for Black Friday 3 years ago." Your custom AMIs probably have security patches from 2019. Security groups will make you cry - somebody allowed 0.0.0.0/0 on port 22 because "it was faster than figuring out the actual CIDR."

Storage

S3 buckets with public read because someone needed to "quickly test something." EBS volumes that haven't been attached to instances in 18 months but still cost $200/month. EFS filesystems that someone created for a project that got cancelled but never cleaned up. Use AWS Config to find orphaned storage - saved me 3 hours of clicking through the console like an idiot.

Databases

RDS instances running MySQL 5.7 because "if it ain't broke, don't fix it" - except it IS broke, you just don't know it yet. DynamoDB tables with provisioned capacity that scales to handle traffic from 2018. ElastiCache clusters that nobody remembers the purpose of.

Network Clusterfuck

VPCs that were supposed to be temporary but became production. Route53 records pointing to ALBs that don't exist. NAT gateways costing $500/month to route traffic for a cron job.

Real Migration Objectives (Not Marketing Bullshit)

Cost Reality Check

The magical savings Google marketing loves to quote? Total bullshit. Our first GCP bill was fucking huge - like, higher than AWS because we just moved everything over without thinking. Took forever to clean up and fight with their weird pricing models before we saw any savings.

Performance Reality

GCP's network IS faster - until you hit cross-zone traffic, then latency sucks. BigQuery is amazing for analytics but terrible for transactional workloads (learned this during a late-night on-call when our reporting queries brought down production).

AI/ML Dreams vs Reality

Vertex AI sounds great until you realize your data is still in the wrong format and your team doesn't know Python. AutoML works for demos, breaks in production.

Building a Team That Won't Quit

Don't hire consultants

• One senior engineer who's done this before - worth 5 consultants
• Someone who knows your applications - database connections will break in ways you can't imagine
• A networking person - DNS will fuck you harder than you think
• Someone with GCP experience - IAM policies make AWS look simple

Plan 3x longer than you think. Our "2-week migration" took 3 months because nobody mentioned the mobile app hard-coded AWS IP addresses everywhere, the email service still pointed to Route53, and payment processor webhook URLs were all wrong. Found that last one when customers started complaining about failed payments during dinner. Fun times.

Ready to start? Let's dive into the migration process that actually works.

Phase 1: Setting Up GCP (And Watching Things Break)

GCP Organization - The Hierarchy That Makes No Sense

GCP's resource hierarchy makes no fucking sense. They want Organization → Folders → Projects → Resources, but try creating a folder before you have the right API enabled. You can't enable APIs without a project, but you need a folder to organize projects. Chicken and egg bullshit.

What Actually Works:

1. Start with ONE project called "migration-hell-2025"
2. Get billing accounts set up FIRST - nothing works without this
3. Enable IAM - prepare for 3 different ways to deny access to the same resource
4. Create VPCs in every region you think you might need - adding them later breaks everything
5. Set up monitoring immediately - you'll need it when things inevitably break

Data Migration - The Storage Transfer Lies

Storage Transfer Service sounds great until you discover:

• 5TB/day rate limit hits you with QUOTA_EXCEEDED errors at 2am
• Transfer jobs fail silently if source buckets have versioning enabled - no error, just missing files. Discovered this when our user avatars disappeared and support tickets started flooding in
• Cross-region transfers cost 3x more than they quote because they charge egress AND ingress
• Object metadata gets fucked up - suddenly all your files are application/octet-stream instead of proper MIME types

What Actually Works for Big Data:

1. Use gsutil -m for parallel uploads
2. Run multiple transfer jobs with different prefixes to bypass daily limits
3. Test with 100GB first, not 100TB - you'll find the stupid shit faster
4. Budget like a month for multi-TB migrations, not the "few hours" bullshit Google claims

Database Migration - When DMS Actually Works

Database Migration Service is the one Google service that isn't complete garbage:

PostgreSQL migrations: Work perfectly 90% of the time. The other 10% involves custom extensions that don't exist in Cloud SQL. You'll get a cryptic error like ERROR: extension "pg_similarity" is not available and realize you need to rewrite half your search functionality.

MySQL migrations: Work until you discover your app uses stored procedures that DMS can't migrate. Error: ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled. Plan to rewrite all your triggers or suffer through MySQL's weird privilege system.

Oracle migrations: Don't. Just rebuild the whole thing on Cloud Spanner and suffer through the query rewrites.

The Process That Actually Works:

1. Create oversized Cloud SQL instance (downsize later)
2. Run DMS migration to staging environment first
3. Test EVERY stored procedure, trigger, and foreign key constraint
4. Plan cutover for weekends when nobody's watching - shit always breaks
5. Keep AWS RDS running for 30 days minimum

Phase 2: Application Migration (The Pain Begins)

Compute Migration - When Migrate for Compute Engine Lies to You

Migrate for Compute Engine works perfectly in demos, breaks in production:

Linux VMs: 80% success rate if you're running standard distributions
Windows VMs: 30% success rate - custom drivers, Windows licensing, and registry settings will fuck you
VMs with multiple network interfaces: Forget it, manual rebuild required

What Actually Works:

1. Use Packer to build fresh Compute Engine images - don't migrate old crusty AMIs
2. Script your application deployments with Ansible or Terraform
3. Test networking FIRST - VPC peering, firewall rules, and Cloud NAT work differently than AWS
4. Plan for DNS hell - Cloud DNS takes forever for NS record propagation

Container Migration - GKE vs EKS Reality

Migrate for GKE is experimental garbage. Better to manually recreate everything:

EKS → GKE differences that will break your deployments:

• Load balancer annotations are completely different
• Persistent volume provisioning requires different storage classes
• RBAC policies need complete rewrites
• Ingress controllers behave differently with SSL termination

GKE Autopilot Reality Check:
Autopilot sounds amazing until you need:

• Custom node configurations
• Specific kernel modules
• DaemonSets that aren't pre-approved
• Any control over the underlying nodes

Phase 3: The DNS Nightmare and Security Clusterfuck

DNS Migration - When Everything Goes to Shit

DNS is where migrations go to die. Cloud DNS has different TTL behavior than Route 53:

What Always Breaks:

• Mobile apps with hardcoded IP addresses. Found out the mobile team hardcoded IPs when half our users couldn't log in. Took us 3 hours to figure out why while customers were screaming on social media
• CDN configurations pointing to old origins - CloudFlare kept serving stale content for 6 hours
• Third-party integrations with webhook URLs buried in config files nobody documented
• SSL certificate domain validation during the switch - because of course it picks the worst possible time to fail

The Process That Minimizes Pain:

1. Document EVERY DNS record - Cloud Asset Inventory won't catch them all
2. Lower TTLs to 300 seconds 48 hours before cutover
3. Set up parallel DNS in Cloud DNS and test with hosts file entries
4. Have rollback plan ready - NS record changes take forever to propagate
5. Monitor error budgets religiously during cutover

SSL Certificate Hell

Google-managed SSL certificates take forever. Sometimes Google just gives up with FAILED_NOT_VISIBLE and you restart the process. I've seen them fail for 3 days straight because of DNS propagation issues nobody at Google could explain.

Survival Strategy:

• Use Let's Encrypt with cert-manager for fast certificate provisioning
• Have ugly temporary URLs ready (users hate downtime more than ugly URLs)
• Test certificate provisioning in staging FIRST - I've seen them fail for 3 days straight because of DNS propagation issues
• Budget downtime for HTTPS services - it's going to happen

Your migration isn't done when traffic starts flowing. The real fun begins when you realize what broke and what you need to fix. But first, let's address the questions you'll be asking when things inevitably go wrong:

The Shit That Breaks After You Think You're Done

After migration, expect 3 months of firefighting. Nothing works exactly like AWS, your monitoring is broken, and you'll discover 47 services you forgot you were using when they stop working.

Performance "Optimization" - Fixing What Broke

Google Cloud's recommender will immediately tell you to downsize everything because "usage is low." Ignore this bullshit. Your CPU usage is low because half your applications are broken and not processing requests.

What Actually Needs Fixing:

Compute Sizing Reality: Custom machine types sound great until you realize they cost 20% more than predefined types for no reason. Your "optimized" 7-core, 13GB RAM instance is actually more expensive than the 8-core, 16GB standard instance. Google's pricing team must be laughing their asses off.

Storage Clusterfuck: Cloud Storage lifecycle policies will move your critical files to Coldline storage overnight, then charge you retrieval fees when your app needs them. Set up monitoring alerts BEFORE implementing lifecycle policies or prepare to get fucked by surprise fees.

Network Performance Lies: Google's premium network tier is faster - until you hit cross-zone traffic. Your database in us-central1-a talking to your app in us-central1-b will have higher latency than AWS cross-AZ traffic.

Database Performance Hell: Cloud SQL performance is unpredictable. The same query takes 100ms one hour, 2 seconds the next. Enable Query Insights immediately or you'll be debugging phantom performance issues for months while your users complain about slow page loads.

Cost Management - Why Your Bill Doubled

Sustained use discounts only apply to identical instance types running 24/7. Your auto-scaling instances that change size based on load? No discounts for you.

Committed use contracts lock you into spending commitments. Miss your commitment by $100? Pay $100 extra. Exceed it by $1000? Still pay the commitment, plus the overage.

Cost Monitoring That Doesn't Suck:

• Budget alerts at 25%, 50%, 75%, and 90% - not just 100%
• Billing export to BigQuery for detailed cost analysis
• Daily Slack alerts showing top 10 costs - surprises suck less when they're small

Hidden Cost Bombs:

• Network egress: $0.12/GB adds up fast
• Cloud NAT: $45/gateway/month + data processing fees
• Load balancing: Per forwarding rule charges nobody mentions
• BigQuery: Analysts running $500 queries "just to check something"

Security Hardening - IAM Hell Continues

GCP IAM makes AWS look simple. There are 3 different ways to deny access to every resource, and figuring out which one is blocking you requires a PhD in Google documentation.

Service Account Nightmare: Your application worked with AWS IAM roles. GCP service accounts work differently:

• No automatic instance metadata service access
• JSON key files that need to be managed (and rotated)
• Workload Identity for GKE that requires 17 configuration steps

Security Tools That Are Actually Useful:

• VPC Flow Logs: Expensive but essential for debugging network issues
• Cloud Audit Logs: Works better than AWS CloudTrail
• Security Command Center: Pretty dashboards, questionable alerting

Monitoring - Everything is Broken

Cloud Monitoring metrics don't map 1:1 to CloudWatch metrics. Your dashboards are useless, your alerts fire constantly, and SLOs become SLO-ry time.

Monitoring Migration Reality:

• Metrics Collection: Ops Agent conflicts with existing monitoring (Datadog, New Relic)
• Custom Metrics: Different namespace, different format, different costs
• Alerting: Alerting policies have different trigger conditions than CloudWatch alarms
• Dashboards: Start from scratch, existing dashboards don't import from AWS CloudWatch

What Actually Works:

• Keep existing monitoring running for 3 months minimum
• Use Cloud Trace for distributed tracing - it's actually good
• Cloud Profiler works but requires application code changes

Disaster Recovery - Planning for the Next Disaster

Cloud Storage backup is reliable, Persistent Disk snapshots work well, but restore testing will reveal fun surprises.

Database Backup Reality: Cloud SQL automated backups happen during peak usage hours by default. Change this immediately or suffer performance degradation during business hours.

Multi-Region Complexity: Multi-region deployments sound great until you deal with:

• Data replication delays
• Network latency between regions
• Cross-region firewall complexity
• Load balancer health checks failing during network partitions

Ongoing "Optimization" - The Never-Ending Project

You're not done when traffic is flowing. You're done when you stop getting fucked by surprise AWS charges 6 months later.

Monthly Cleanup Tasks:

• Check Cloud Asset Inventory for orphaned resources
• Review Recommender suggestions (ignore most of them)
• Hunt down the AWS resources you forgot about using billing alerts
• Update runbooks with new GCP-specific procedures

Google releases new capabilities monthly that break your existing setup. Stay current or suffer, but test everything in staging first.

You survived. Now what?

Six months from now, when you're not getting paged at 3am about AWS billing surprises, you'll realize this pain was worth it. GCP isn't perfect - no cloud is. But if you followed this guide, you avoided the worst migration disasters and built something maintainable.

The next time some consultant tries to sell you a "seamless 2-week migration," laugh in their face and show them this guide. Real migrations are messy, expensive, and take 3x longer than anyone estimates. But if you follow what actually works, you can minimize the damage and live to fight another day.

Need more resources that might actually help? Check these out: