
KamelPay migrates its core payments platform to AWS with zero payment downtime
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
| KPI | Result |
|---|---|
| Production outcomes | The 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 window | Discovery 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 posture | Moving 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 & continuation | Homogeneous (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. |