Migrating ClearPay from AWS to Google Kubernetes Engine: A Production Case Study

Cloud migrations often present engineers with a high-stakes challenge: modernizing infrastructure while ensuring continuous, uninterrupted service for end users. A detailed case study highlights how a development team successfully migrated a payments application, ClearPay, from an Amazon Web Services (AWS) EC2 instance to Google Kubernetes Engine (GKE) without experiencing customer-facing downtime.

The project involved shifting a React frontend and an Express API to GKE while keeping the PostgreSQL database securely hosted on Amazon RDS. By carefully orchestrating the transition through a gradual, weighted traffic-routing strategy, the engineering team maintained strict operational control, protected transaction integrity, and preserved a fast rollback path throughout the process.

The Starting Point and Architectural Baseline

Before initiating any infrastructure changes in Google Cloud, the team established a reliable operational baseline. ClearPay operated on a standard, single-server AWS setup consisting of an EC2 instance running Nginx, a Node.js API managed by systemd, and a backend PostgreSQL database hosted on Amazon RDS. Because the application relied on a single server without automated scaling or container orchestration, the migration project aimed to introduce a more resilient, containerized architecture on Kubernetes.

Establishing trust in the initial environment was critical. Engineers ran the application locally using Docker Compose, verifying login functionality and completing end-to-end payment transfers. They rigorously tested transaction idempotency to ensure that repeated network calls—such as a user double-clicking a payment button—never resulted in duplicate charges.

Following local validation, the team deployed the application to a dedicated AWS EC2 instance using Terraform, establishing an initial performance baseline. Load-testing metrics, including request latency and error rates, were meticulously recorded. These metrics served as the benchmark against which the new GKE environment would be evaluated, ensuring that the cloud migration did not degrade user experience or transaction reliability.

Designing the Multi-Cloud Transition

Planning the migration required identifying application dependencies and establishing strict operational boundaries. The team determined that the React UI and Express API were stateless, meaning they did not retain user sessions in local memory. Instead, user authentication relied on signed JSON Web Tokens (JWTs), and all transaction history was securely stored in the PostgreSQL database.

Because the database represented a complex and data-sensitive component, the architectural design explicitly left PostgreSQL on Amazon RDS within its private AWS VPC. Attempting to migrate the database alongside the application layer would have introduced unnecessary risks and complicated troubleshooting if errors occurred. Instead, the team focused exclusively on containerizing and migrating the stateless API and UI layers to GKE.

To bridge the two cloud environments, engineers configured a secure networking path. The GKE cluster was deployed within private subnets inside a dedicated Google Cloud VPC, utilizing Cloud NAT to manage outbound internet traffic. By assigning a static public IP address to Cloud NAT and updating the AWS security groups to accept incoming database connections strictly from that IP, GKE pods were able to securely communicate with the RDS instance across cloud providers. Furthermore, database connections strictly required Transport Layer Security (TLS), ensuring data in transit remained encrypted over the public internet.

Building the Google Cloud Infrastructure via Terraform

Infrastructure provisioning in Google Cloud was executed using an incremental, eight-stage Terraform workflow. Breaking the deployment into distinct phases—ranging from foundational API enablement and network creation to GKE cluster provisioning and artifact registry setup—allowed engineers to verify each layer independently before proceeding.

The GKE cluster itself was deployed in Standard mode, providing the team with explicit visibility into node pools, machine sizing, and autoscaling configurations. Secrets management was handled securely through Google Secret Manager, leveraging Workload Identity to grant GKE pods and CI/CD pipelines access to sensitive credentials without storing plain-text key files on disk.

Once the core infrastructure and secrets were configured, engineers established a global HTTP(S) load balancer at the network edge. This load balancer served as a unified public entry point for customers, featuring a weighted traffic-splitting mechanism capable of routing incoming requests dynamically between the legacy AWS EC2 server and the new GKE production environment.

Deploying Staging Workloads and Automating CI/CD

With the destination cluster prepared, the team implemented a continuous integration and deployment (CI/CD) pipeline via GitHub Actions to automate image building, vulnerability scanning, and deployment processes. To eliminate human error and ensure consistency, manual kubectl apply commands were replaced by automated pipelines.

The pipeline utilized Trivy to scan container images for security vulnerabilities before pushing them to the Google Artifact Registry. Images that passed security gates were deployed to a private staging namespace within the GKE cluster. To validate staging readiness, engineers executed an automated promotion gate script that tested core application functions, including health checks, database connectivity, user authentication, and transaction idempotency.

By running these validation checks through a secure port-forwarding tunnel, the team confirmed that the staging environment operated correctly before opening it up to real-world traffic.

Executing the Weighted Traffic Shift

The most critical phase of the migration involved moving customer traffic from AWS to GKE gradually. Rather than executing an abrupt DNS cutover—which risks lingering caching delays and prolonged outages if a rollback becomes necessary—the team utilized the weighted routing capabilities of the Google Cloud global load balancer.

Traffic was shifted incrementally through carefully monitored stages: starting at one percent, then progressing to ten percent, twenty-five percent, fifty percent, seventy-five percent, ninety percent, and finally one hundred percent. At each interval, engineers monitored system telemetry, error rates, latency percentiles, and transaction success metrics.

Throughout the traffic shift, both AWS and GKE operated concurrently, pointing to the same underlying PostgreSQL database. This dual-cloud operational model provided an immediate safety net. If anomalies or elevated error rates were detected, the load-balancer weights could be adjusted instantly to route traffic back to AWS, or an automated rollback script could be executed to restore full service to the legacy server while preserving a clear status banner for visibility.

Careful capacity planning also prevented resource exhaustion. By analyzing the maximum database connection limits of the Amazon RDS instance against the potential scaling limits of the GKE Horizontal Pod Autoscaler, the team ensured that the combined connection pools from both active cloud environments never overwhelmed the database.

Finalizing the Cutover and Retiring Legacy Infrastructure

Following successful validation at one hundred percent traffic capacity, the GKE environment operated stably under real-world production conditions. Having proven the reliability and performance of the containerized application, the team moved forward with decommissioning the legacy infrastructure.

The AWS EC2 instance and its associated Nginx and systemd configurations were retired using targeted Terraform teardown scripts. True to the original project scope, the Amazon RDS PostgreSQL database remained operational on AWS, serving as the persistent data store for the fully migrated GKE application workloads.

Reflecting on the project, the engineering team noted that while the migration achieved zero customer downtime and preserved transaction integrity, the cross-cloud network architecture introduced a measurable increase in request latency due to the physical distance between Google Cloud and AWS data centers. This insight established a clear technical roadmap for future infrastructure optimizations, including the potential migration of the database layer into Google Cloud. Overall, the successful execution demonstrated how rigorous planning, incremental traffic shaping, and disciplined operational controls can successfully modernize complex enterprise applications.