Skip to content

Financial services

Moving a payments platform to AWS with zero downtime

Two co-located data centres, a PCI-DSS audit due in the same quarter and no maintenance window allowed. We moved card processing, settlement and the merchant dashboard to AWS without a single minute of downtime.

Client Project6 months
Client
Series C payments company, 300 employees, UAE
Industry
Financial services
Region
UAE
Duration
6 months
Team
8 engineers
  • Cloud migration
  • DevOps and CI/CD
  • Database migration
  • Security and compliance

Results

Downtime during the move
0 h
Uptime in the first year
99.99%
Lower infrastructure cost
50%
Faster transaction processing
30%

The challenge

The platform processed card payments for around 4,000 merchants from two leased racks in Dubai. Hardware was reaching end of support, capacity for the Ramadan and White Friday peaks had to be bought a year in advance, and every release was a scheduled night-time event with the whole platform team on a call.

Any move had to keep PCI-DSS and SOC 2 scope intact, stay inside the UAE for data residency, and could not interrupt authorisations: merchants measure outages in lost sales per second, so a maintenance window was not an option.

Before and after

How things ran when we started, and once the work shipped.

  • Before: Two leased racks, capacity bought a year ahead
  • After: Autoscaling across three availability zones
  • Before: Monthly releases in a night-time window
  • After: Daily releases through CI with no window
  • Before: Failover tested once a year, by hand
  • After: Recovery drills run every quarter from a runbook

Approach

How the work was done

5 phases over 6 months, with a working demo at the end of every week.

  1. 01

    Weeks 1–4

    Assessment and landing zone

    Mapped 46 services and their dependencies, classified data by PCI scope and built a multi-account AWS landing zone in me-central-1 with Terraform, Control Tower guardrails and centralised logging.

  2. 02

    Weeks 5–12

    Replatform the stateless tier

    Containerised the Java and Node.js services, moved them to EKS behind the existing load balancers and ran both environments in parallel with mirrored traffic to compare responses.

  3. 03

    Weeks 10–18

    Database replication

    Set up continuous replication from on-premise PostgreSQL to Aurora with AWS DMS, validated row counts and checksums nightly, and rehearsed the cut-over four times in staging.

  4. 04

    Weeks 19–22

    Weighted cut-over

    Shifted traffic merchant by merchant using weighted DNS, starting at 1% and reaching 100% over nine days, with a tested rollback path at every step.

  5. 05

    Weeks 23–26

    Decommission and handover

    Retired the racks, passed the PCI-DSS re-assessment on the new estate and handed over runbooks, dashboards and on-call training to the client platform team.

Architecture

An active-active setup across three availability zones in the UAE region, with card data isolated in its own account and every change applied through code review and CI.

  • Multi-account AWS Organization: shared services, PCI workloads and non-PCI workloads separated
  • EKS clusters per environment with Karpenter autoscaling
  • Aurora PostgreSQL with cross-AZ replicas and point-in-time recovery
  • Route 53 weighted routing used for the gradual cut-over
  • KMS-encrypted secrets, CloudTrail and GuardDuty feeding a central security account
  • GitHub Actions and Argo CD for every infrastructure and application change

Stack

  • AWS
  • EKS
  • Aurora PostgreSQL
  • AWS DMS
  • Terraform
  • Argo CD
  • GitHub Actions
  • Datadog
“We had been putting this migration off for two years because nobody could promise it without an outage. The weighted cut-over meant our merchants never noticed, and our auditors signed off the new setup first time.”
CTOSeries C payments company, UAE

Have a project like this?

Tell us where things stand today. On a 30-minute call an engineer will sketch how we would approach it, the timeline and a price range.