VeUP
← All case studies
Machine Learning · GitOps & pipeline automation
GoBubble logo

GoBubble migrates 21 workloads from GCP to Amazon EKS with zero downtime

Cloud-to-cloud migrationZero-downtime migrationPhased cutover with parity validationGPU capacity & inference economicsContainer platform modernizationEvent-driven architectureInfrastructure observabilityCentralized workforce identityPreventive controlsPrivate connectivity & network isolationCross-region & multi-AZ replicationWeb application firewall & bot mitigationInfrastructure-as-code foundationCI/CD delivery pipeline automationCDN & edge delivery architectureGitHub ActionsSecrets management & credential elimination
Zero
downtime — the whole estate cut over live
21
workloads migrated GCP → AWS in sequenced waves
Amazon EKSAmazon ECRAWS Step FunctionsAmazon EventBridge

GoBubble had a fixed twelve-week window to leave GCP and stand up an AWS-native container platform. VeUP’s answer was an uncompromising DevOps operating model: the entire estate defined in Terraform, a GitOps CI/CD path (GitHub Actions with AWS OIDC) as the only way anything mutates the cluster or the estate, and roughly 85 data/ETL pipelines automated on AWS Step Functions and Amazon EventBridge.

The challenge

Twelve weeks to migrate a live Emotional-AI SaaS — real-time inference on user-generated content — with zero downtime, while also modernizing dozens of GCP-coupled Airflow data pipelines. A deadline like that usually buys speed with entropy: hand-built resources, console fixes, snowflake environments that nobody can rebuild. GoBubble needed the opposite trade — delivery speed achieved through automation discipline, so the platform that existed when the window closed was reproducible, auditable, and safe to keep shipping on after the deadline passed.

The solution

VeUP built the delivery system before the platform. Terraform defines the entire AWS estate — the Amazon EKS cluster, node groups, networking, data stores, and the pipeline infrastructure — and the GitOps path is exclusive: GitHub Actions authenticates to AWS via OIDC (no long-lived keys) and is the only actor permitted to mutate the cluster or the estate; humans propose changes in git, pipelines apply them. The workload runs on EKS with autoscaling at both pod and node level placing capacity, and Amazon ECR scans every image on push. The ~85 data/ETL pipelines were translated from GCP-coupled orchestration onto AWS Step Functions, Amazon EventBridge, and AWS Glue — versioned, evented, and retryable instead of cron-shaped. Observability was built in as code too: CloudWatch Container Insights with custom GPU and latency metrics, and Amazon Managed Grafana as the shared pane. The cutover ran a 14-day data-parity overlap window that returned a Pass — and landed zero-downtime inside the fixed 12-week window.

Production outcomes

KPIResult
Milestone deliveryZero-downtime cutover of the live AI platform inside the fixed 12-week migration window, with a 14-day data-parity overlap validating the move before commitment.
Pipeline automation~85 data/ETL pipelines automated on Step Functions + EventBridge + Glue — the platform’s data operations converted from scheduled scripts to observable, event-driven workflows.
Operating model & economicsSingle GitOps mutation path with OIDC-authenticated pipelines and ECR image scanning; autoscaling at pod and node level with Graviton general-purpose compute, so capacity and cost track demand.
Lessons & continuationHard deadlines are the argument for GitOps, not against it — one declarative estate and one mutation path is what made the deadline survivable; and a data-parity overlap window converts “we think it moved cleanly” into a pass/fail fact.
AWS services in production
Amazon EKS (pod + node autoscaling)Amazon ECR (image scanning)AWS Step FunctionsAmazon EventBridgeAWS GlueAmazon CloudWatch Container InsightsAmazon Managed Grafana
Alongside
GitHub Actions + AWS OIDC (GitOps path)Terraform