GoBubble

GoBubble AI Tech is a startup-segment SaaS company whose products — Emotional-AI, the Freedom2Hear content-moderation platform, and GB Wrap — serve customers across EMEA with a growing focus on MENA markets. Its entire production estate ran on Google Cloud Platform: GKE clusters hosting the containerized microservices, VM-based workloads including Redis, PostgreSQL and file transfer, serverless functions and scheduled jobs, static frontend hosting, and hosted AI models, alongside SaaS dependencies on Confluent Kafka, MongoDB, and Snowflake, with CI/CD split between GitHub Actions and GCP Cloud Build.

Operating that estate carried growing overhead, AI workloads were hard to scale cost-effectively, and the company’s growth plans in MENA needed a platform with the right regional footprint and economics. The contracted goals: migrate all workloads — non-critical and mission-critical — to AWS with zero downtime, meet or exceed existing uptime and latency SLAs, re-platform onto infrastructure as code with full CI/CD, and hand the environment back to GoBubble’s engineering team to run autonomously.

The Statement of Work was executed on 10 February 2025 as a 12-week phased engagement — two weeks of discovery and planning, eight weeks of migration execution, and two weeks of testing and validation — followed by two further weeks of extended support, structured on the AWS migration methodology of Assess, Mobilize, and Migrate & Modernize.

Assess.Discovery opened with a full audit of the GCP estate — applications, infrastructure, and data schemas. AWS Application Discovery Service mapped workload dependencies and performance characteristics, reconciled against GoBubble’s own architecture documentation, and surfaced the dependency clusters that had to move together: the Kafka topic graph coupling the moderation services, the Freedom2Hear data-store cluster of PostgreSQL, Redis and file transfer, and the AI model-hosting chain feeding the analytics and reporting path. That model fed the migration strategy and contingency plans. In parallel we provisioned the AWS accounts and access policies, established connectivity between the GCP and AWS environments, modeled the full target environment in the AWS Pricing Calculator, and closed the phase with a pre-migration readiness checkpoint.

Mobilize. Foundations went in before any workload moved. The account security baseline followed our standard governance controls: root account locked down with MFA, CloudTrail across all regions delivering to a dedicated protected logging bucket, AWS Config and Security Hub for continuous posture validation, and KMS-backed encryption at rest. Our engineers accessed the customer environment exclusively through a dedicated cross-account IAM role with temporary, least-privilege credentials — no shared users, no long-lived keys. The application architecture was rebuilt as infrastructure-as-code modules deployed through CI/CD pipelines, and operations readiness ran alongside: CloudWatch dashboards and alarms tied to workload health KPIs, and a runbook covering daily checks, troubleshooting, and escalation. Delivery governance was contractual — daily standups and retrospectives at each milestone.

Migrate & Modernize. Execution ran in dependency-sequenced waves, non-critical systems first: a pilot wave of low-dependency workloads — container registry, static assets, serverless jobs, identity and DNS — proved the landing zone and security baseline; application and supporting tiers followed; then the data tier, with AWS Database Migration Service holding source and target PostgreSQL in continuous sync and controlled native replication covering the data stores outside DMS scope, including MongoDB; and finally the mission-critical moderation core together with the Kafka topic graph, whose topics and dead-letter queues were re-established on the target and consumers re-pointed at cutover. Each wave was validated incrementally before the next moved.

The disposition was a mixed 7Rs profile, typical for a cloud-to-cloud move. The GKE container estate moved like-for-like onto Amazon EKS, preserving the application architecture while gaining AWS-native integration; VM-based workloads were rehosted through AWS Application Migration Service with minimal downtime; the PostgreSQL tier was replatformed onto Amazon RDS for PostgreSQL in Multi-AZ configuration for managed failover and backups; and SaaS dependencies — Confluent Kafka, Snowflake, Astrato — continued as providers. After incremental validation of each wave, we ran the final data synchronization and executed the live cutover with zero downtime. Two weeks of testing and validation confirmed functional behavior and data integrity, followed by a two-week stabilization period. Rollback posture was engineered, not assumed: staged deployments with automated unit, integration and smoke tests, a deployment checklist with a documented rollback path to the previous container image and infrastructure configuration, and production change flowing exclusively through version-controlled IaC pipelines.

The environment entered production on 19 June 2025, following the zero-downtime cutover and stabilization period, with GoBubble’s team operating it autonomously. On the strength of the migration, GoBubble expanded the engagement — delivered within the extended-support window — moving its data pipelines from Airflow into Snowflake, a refactor workstream where we used generative AI to accelerate delivery: inventorying the existing DAGs, producing an operator-translation matrix mapping Airflow operators to Snowflake Tasks, Snowpark and Step Functions, and drafting the data-parity test harness used at validation. Lessons from the engagement — confirming data-store access with the customer before execution begins, and using discovery tooling more exhaustively to pre-plan replication exceptions — are now embedded in our delivery standard.

The migration covered the full documented estate — 21 workloads across the Emotional-AI and Freedom2Hear product lines plus a shared platform layer: the GKE-hosted microservices (the Emotional-AI moderation backend, Freedom2Hear backend and API, GB Wrap admin API and frontends, authentication, upload, reporting and analytics services), GPU-class AI model hosting and inference, VM workloads (Redis, PostgreSQL, sftp and integration adaptors), serverless functions and scheduled jobs, static frontend hosting, the container registries, eight DNS zones, the Confluent Kafka topic graph with its dead-letter queues, MongoDB, and the CI/CD toolchain — re-implemented as infrastructure as code with AWS-native identity and secrets management.

Network. A multi-AZ, multi-tier VPC. Public subnets contain only the internet-facing components — the CloudFront distribution, Application Load Balancers, and NAT Gateways. Application and data tiers sit in private subnets with no public IPs; east-west traffic is controlled with security-group-to-security-group rules and NACL guardrails, and outbound traffic flows through NAT.

Compute. The containerized microservices — the Emotional-AI backend, Freedom2Hear, GB Wrap and supporting services — run on Amazon EKS, a deliberate like-for-like Kubernetes move from GKE. Scaling is handled by the Horizontal Pod Autoscaler for pods and Cluster Autoscaler for nodes. General-purpose compute runs on Graviton-based m8g instances for price-performance, and AI model inference runs on a dedicated fleet of GPU g6 instances scaled independently, so inference capacity grows without inflating general-purpose compute.

Data. PostgreSQL moved from a self-managed VM to Amazon RDS for PostgreSQL in Multi-AZ configuration — automatic failover and automated backups replacing manual database operations, on gp3 storage with explicitly provisioned IOPS and throughput. S3 provides object storage and static asset hosting; ECR replaced the GCP container registries; Route 53 provides DNS across eight hosted zones.

High availability and operations. Traffic enters through CloudFront to internet-facing ALBs that distribute across Availability Zones; EKS worker nodes span AZs, and the database fails over automatically within its Multi-AZ pair. Recovery objectives were worked through with the customer, with infrastructure as code providing the rebuild path. CloudTrail all-region logging, AWS Config and Security Hub monitor posture; KMS encrypts EBS, RDS, S3 and backups at rest with TLS terminated at the ALBs; CloudWatch carries metrics and structured application logs, with alarms on error rates, latency against SLA, compute utilization, and database storage. All production change flows through version-controlled infrastructure as code and CI/CD pipelines under dedicated IAM roles — no console changes.