VeUP
← All case studies
Financial Services · Regulated fintech platform
KamelPay wordmark

KamelPay migrates its core payments platform to AWS with zero payment downtime

On-premises datacenter exitZero-downtime migrationPhased cutover with parity validationPrivate connectivity & network isolationCross-region & multi-AZ replicationInfrastructure-as-code foundationData residencySQL Server replatform to managed RDSDay-2 runbooks & team enablement
0
downtime to live payments and regulated bank rails
Minutes
RPO/RTO — from nightly on-premises backups
Risk retired
single-data-center exposure removed with Multi-AZ failover
Amazon RDS for SQL Server (Multi-AZ)Multi-AZ (UAE)Site-to-Site VPNNetwork Firewall

VeUP migrated KamelPay’s on-premises, SQL Server core payments platform to the AWS Middle East (UAE) Region in a three-week phased engagement with zero downtime to live payments — re-platforming the core database onto Amazon RDS for SQL Server, Multi-AZ, carrying its regulated bank rails into the AWS VPC intact, and removing single-data-center risk with automated cross-AZ failover.

The challenge

KamelPay’s transaction platform ran on an on-premises, VM-based estate built on Microsoft SQL Server. Mobile and web front ends had already moved to AWS, but the core database and core application remained on-premises — and that split was now the constraint: the on-premises database was hitting resource and load limits throttling remittance and payroll growth, and the single-data-center posture carried business-continuity and resilience risk. KamelPay needed to move the core platform to AWS quickly without interrupting live payment processing or breaking the private, regulated connectivity to its banking and processor partners. Two hard requirements: no downtime to payments or bank connectivity; and preserve the regulated bank rails (dedicated IPsec/MPLS links). KamelPay came in set on keeping the same SQL Server engine on AWS under its own license, self-managed on Amazon EC2 — no managed database services.

The solution

A phased migration in three one-week phases — Discovery & Planning, Migration Execution, Testing & Validation — with joint daily standups and milestone retrospectives. Discovery audited the on-premises infrastructure, applications, and data schemas and produced a migration strategy with contingencies. On the data tier, VeUP made the case for a different path than KamelPay’s starting ask: rather than lifting SQL Server onto self-managed EC2, VeUP recommended — and delivered — the core payments database on Amazon RDS for SQL Server, Multi-AZ, a fully managed engine with automated cross-AZ failover, backups, and patching. The database moved homogeneously — same engine, same schema, no conversion step — via a one-time native backup restored into RDS from Amazon S3; application connectivity was repointed to the managed in-VPC RDS endpoint with all traffic internal to the AWS VPC. VeUP re-implemented the architecture on AWS as Infrastructure as Code. A phased validated cutover progressed from non-critical to mission-critical workloads so existing uptime/latency/performance SLAs were met or exceeded with no corruption or loss. The target topology carried KamelPay’s existing private bank and processor connections (IPsec site-to-site VPN + private MPLS) into the AWS VPC, and the platform was deployed across two Availability Zones in the AWS Middle East (UAE) Region with the core database in Multi-AZ configuration.

Production outcomes

KPIResult
Production outcomesThe remaining on-premises core — database and application — moved to the AWS Middle East (UAE) Region, completing KamelPay’s cloud transition with zero downtime to payment processing and bank connectivity: the defining requirement, met. Single-data-center risk is gone — the core database runs on Amazon RDS for SQL Server, Multi-AZ, with automated cross-AZ failover, and both VPCs span two Availability Zones. Existing uptime, latency, and performance SLAs were met or exceeded, data moved securely with no corruption or loss, and the whole engagement took three phased weeks. KamelPay’s co-founder and CTO signed off the completed work in May 2025.
Engagement windowDiscovery ran through December 2024 and January 2025, and the engagement was scoped that January. Execution took four weeks from early April 2025, the database cutover landed the same month, and KamelPay’s co-founder and CTO signed off completion in May 2025.
Cost / TCO postureMoving the core database onto managed Amazon RDS for SQL Server bought a lower-operational-risk, lower-toil posture — no self-managed patching, backup, or failover tooling to run for a regulated payments workload — while the homogeneous move avoided schema-conversion effort. A post-migration TCO retrospective — Savings Plans, Reserved Instances, right-sizing — projects an annual AWS run-rate of approximately $160K.
Lessons & continuationHomogeneous (like-for-like) database migration removes schema-conversion risk and lets the team focus on a clean cutover; for a regulated payments workload, carrying the existing IPsec/MPLS bank rails into the VPC topology intact is the precondition that makes a zero-downtime cutover possible; phasing from non-critical to mission-critical workloads with continuous monitoring is how you hold a no-downtime bar on live payments.
AWS services in production
Amazon RDS for SQL Server (Multi-AZ)Amazon EC2 (application & API tier)Amazon VPC (multi-VPC, multi-AZ, peered)AWS Network FirewallAWS Site-to-Site VPNElastic Load BalancingAmazon S3