Global FinTech SaaS Company
AWS to OCI Migration: EKS, Aurora, Kafka and MongoDB
A global software company running business-critical workloads across four AWS environments needed a full-stack migration to Oracle Cloud Infrastructure: containers, databases, messaging, caching, and object storage, without disrupting production operations.
Industry
FinTech
Key Result
Zero Production Downtime at Cutover
Primary Service
Cloud Migration
Core Stack
AWS EKS, Oracle Kubernetes Engine (OKE), Terraform
See how your cloud setup compares to the results in this case study.
Run the Cloud FinOps DiagnosticThe Challenge
A global software company hosted development, QA, pre-production, and production environments on AWS, running containerised microservices on Amazon EKS with self-managed worker nodes, Aurora PostgreSQL databases, Kafka and MongoDB clusters on EC2, ElastiCache Redis, and 213 GB of object storage across Amazon S3. Self-managed infrastructure created constant patching and lifecycle overhead across every environment. Rising EC2 and licensing costs, duplicated operational effort across four parallel environments, and a strategic mandate to adopt managed cloud-native services drove the decision to migrate the entire platform to Oracle Cloud Infrastructure.
Our Solution
GYSP executed a seven-phase structured migration covering every layer of the AWS platform. An OCI Landing Zone was designed and provisioned using Terraform, establishing compartments, VCN, security lists, NSGs, IAM policies, and OCI Vault as the secure foundation. Kubernetes workloads were migrated from EKS to Oracle Kubernetes Engine with managed node pools, NGINX Ingress, Horizontal Pod Autoscaler, External DNS, and Helm-based application deployment. Aurora PostgreSQL clusters were migrated to Oracle Autonomous Database, MongoDB on EC2 to Oracle Autonomous JSON Database, ElastiCache Redis to OCI Cache, and Kafka to OCI Streaming via MirrorMaker with full topic, partition, and consumer group replication. 213 GB of S3 objects were migrated to OCI Object Storage with lifecycle policies and integrity validation. CI/CD pipelines were rebuilt using Terraform, Jenkins, Helm, and Docker for OCI-native deployments. Production cutover followed a wave-based approach with pre-cutover validation, application freeze, final data synchronisation, smoke testing, UAT, and hypercare support across all four environments.
Facing a similar challenge? Get a no-commitment technical brief.
Get free briefKey Deliverables
- OCI Landing Zone provisioned via Terraform with VCN, compartments, NSGs, IAM dynamic groups, and OCI Vault
- Amazon EKS migrated to Oracle Kubernetes Engine (OKE) with NGINX Ingress, HPA, External DNS, and Helm
- Aurora PostgreSQL migrated to Oracle ADB 19c with schema translation, data validation, and query benchmarking
- MongoDB migrated to Oracle Autonomous JSON Database (AJD) with BSON compatibility, index recreation, and query validation
- 213 GB of Amazon S3 objects migrated to OCI Object Storage with lifecycle policies and integrity validation
- Kafka migrated to OCI Streaming via MirrorMaker with topic, partition, and consumer group parity
- ElastiCache Redis migrated to OCI Cache with endpoint updates, data synchronisation, and failover testing
- Wave-based cutover across four environments with UAT, smoke testing, and post-launch hypercare support
Services Delivered
- Cloud Migration
- OCI Architecture
- Kubernetes Migration
- Database Migration
- DevOps Engineering
Tech Stack
This engagement used AWS EKS, Oracle Kubernetes Engine (OKE), Terraform, Jenkins, GitLab, and 15 additional tools.
Frequently Asked Questions
How do you migrate from Amazon EKS to Oracle Kubernetes Engine without production downtime?+
GYSP provisioned OKE clusters in parallel with the existing EKS environment, migrating workloads progressively using Helm charts, configuring NGINX Ingress, Horizontal Pod Autoscaler, and External DNS to match the existing topology. A wave-based cutover approach then moved production traffic environment by environment, with pre-cutover validation, smoke testing, and UAT sign-off at each wave before the next was attempted. This staged approach eliminated the risk of a single large-bang cutover.
How was Aurora PostgreSQL migrated to Oracle Autonomous Database?+
The migration covered schema migration, full data migration, reconciliation, performance testing, and application connectivity testing against the Oracle ADB endpoint. Schema objects were translated from PostgreSQL to Oracle-compatible DDL, data was migrated and validated at row level before any application traffic was switched, and performance benchmarks were run against production-representative query loads to confirm the ADB instance was correctly sized before cutover.
How was Kafka migrated from EC2 to OCI Streaming?+
OCI Streaming topics were created with matching partition configurations. MirrorMaker was used to replicate in-flight messages from the EC2-hosted Kafka cluster to OCI Streaming during the migration window, with consumer group offsets tracked throughout. Producer and consumer applications were validated against OCI Streaming endpoints before the Kafka EC2 cluster was decommissioned. Message ordering and consumer lag were monitored throughout to confirm no data loss.
What is a wave-based production cutover in a multi-environment cloud migration?+
A wave-based cutover migrates environments in planned sequences rather than all at once. For this engagement, each wave covered one or more environments and followed the same sequence: pre-cutover validation, application freeze, final data synchronisation, production cutover, smoke testing, UAT, and performance validation, before hypercare support was activated. This approach meant each wave served as a dress rehearsal for the next, reducing risk incrementally rather than concentrating it in a single migration event.
Work with GYSP
Similar FinTech challenge?
Get a free technical brief: architecture options, cost estimates, and a delivery timeline scoped to your challenge.
- 48-hour turnaround
- Senior engineers only
- No commitment required
Or call: +1 (929) 588-8364
More FinTech Case Studies
FinTechDotPe
Growing transaction volumes, three active compliance frameworks, and a full AWS-to-GCP migration, all without a single major service outage. The stakes were high for this fintech platform.
FinTechOptions Trading Platform
Retail traders were making high-stakes decisions with manual calculations and static charts. They needed the kind of strategy tools professional desks take for granted, built for the masses.
FinTechTier-1 Retail Bank, United Kingdom
Ahead of the UK's January 2018 Open Banking deadline, a tier-1 retail bank needed to migrate its legacy platform to containerized, multi-region cloud infrastructure on GCP without disrupting live banking operations or missing a single regulatory milestone.
