VeUP
← All case studies
Amazon RDS · Fintech Migration
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 core payments platform onto Amazon RDS for SQL Server, Multi-AZ, in the AWS Middle East (UAE) Region — zero downtime to live payments, regulated bank rails carried into the VPC intact, and single-data-center risk removed with automated cross-AZ failover.

Business impact

Zero
downtime
to live payment processing & regulated bank connectivity through the entire cutover — and zero hours of unplanned downtime since
~$160K
projected annual AWS run-rate
projected, TCO retrospective — Savings Plans, Reserved Instances, and right-sizing applied
Multi-AZ
resilience
core database on Amazon RDS for SQL Server, Multi-AZ, with automated cross-AZ failover — single-data-center risk removed
Minutes
RPO / RTO
versus nightly backups on-premises, with three full environments (Dev/Test/Prod) replacing a production-only estate

The challenge

KamelPay is a UAE fintech providing corporate payroll and disbursement solutions — individual payment cards for each worker, payroll management for employers — operating in collaboration with banks and processing millions of payment transactions. Its core payments 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 stayed on-premises in a Dubai data center — and that split had become the constraint. The on-premises database was hitting resource and load limits that throttled remittance and payroll growth, there was no elasticity to absorb payroll-cycle peaks, the estate ran as a single production-only environment with no Dev or Test tiers, and the single-data-center posture carried business-continuity risk for a regulated payments workload.

Two requirements were non-negotiable: zero downtime to live payment processing and bank connectivity, and the regulated bank and processor rails — dedicated IPsec/MPLS links into the Central Bank of the UAE, Ajman Bank, and Network International — had to be carried into AWS intact. Those multi-party banking dependencies, with four-to-six-week lead times outside anyone’s direct control, set the real sequencing constraints. And because SQL Server Standard had run the platform since inception, KamelPay came in set on bringing the same engine over under its own license, self-managed on Amazon EC2 — no managed database services.

The migration

VeUP ran the engagement against the AWS migration methodology — Assess, Mobilize, Migrate & Modernize — structured as three one-week phases: Discovery & Planning, Migration Execution, and Testing & Validation, governed by joint daily standups and retrospectives at key milestones.

Assess.Structured scoping workshops with KamelPay’s Co-Founder/CTO and his engineering team ran through December 2024 and January 2025: an infrastructure inventory of the on-premises estate, dependency mapping across the bank, card-processor, and central-bank integrations, target-state architecture diagramming, and cost estimation culminating in a full TCO analysis. VeUP’s partner-led migration readiness assessment covered five of the six AWS Cloud Adoption Framework perspectives — Business, Governance, Platform, Security, and Operations — and rated the database migration green on Platform and Security, with the genuine risks organizational and connectivity-related rather than technical. A 7Rs disposition weighed rehost onto self-managed EC2, replatform onto a managed relational service, and a longer-term refactor, and sequenced the core database as the first migration wave.

Mobilize.VeUP designed the landing zone as two peered VPCs in the AWS Middle East (UAE) Region, each spanning two Availability Zones: a core VPC for the payments application and data tiers, and a separate VPC isolating the risk engine and external-integration workloads, peered privately so no traffic between them touches the internet. Hybrid connectivity was designed around the existing regulated rails — IPsec Site-to-Site VPN terminating into strictly security-group-controlled private subnets, private MPLS to the card processors retained, AWS Network Firewall at the public edge — and the security baseline captured KamelPay’s symmetric-key encryption scheme, which the homogeneous migration would carry through unchanged.

Migrate.On the data tier, VeUP made the case for a different path than KamelPay’s starting ask. Rather than lifting SQL Server onto EC2 under a self-managed license, 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, at materially lower operational risk for a regulated payments workload than self-managing the database host. KamelPay agreed, and the database moved homogeneously — same engine, same schema, no conversion step — via a one-time native backup restored into RDS from Amazon S3, followed by a final data synchronization ahead of a planned live cutover in April 2025. Discovery had already produced the migration strategy and its contingency plans, and the cutover progressed from non-critical to mission-critical workloads with incremental validation at each step, so existing uptime, latency, and performance SLAs were met or exceeded with no data corruption or loss. Before KamelPay accepted the environment, a dedicated testing phase put it through functional testing and data-integrity validation, and chased every discrepancy to closure.

What moved.The migrated estate comprised the core SQL Server payments database and the surrounding application tier — application servers, web and mobile APIs, BI engine and BI database, processor middleware, background-job scheduling, HR/CMS, and SFTP services — plus MongoDB, with the risk engine and its database isolated in the second VPC. Application connectivity was repointed to the managed in-VPC RDS endpoint, all app-to-database traffic stayed internal to the VPC, and VeUP re-implemented the surrounding architecture as Infrastructure as Code. The hardware security module and office telephony remained on-premises by design, connected over the retained private links.

Architecture

Target-state AWS architecture in the AWS Middle East (UAE) Region: two peered VPCs each spanning two Availability Zones — a core VPC with AWS Network Firewall, load balancing, the application and API tier, and Amazon RDS for SQL Server Multi-AZ alongside MongoDB and the BI database in private subnets, and an external VPC isolating the risk engine — with IPsec Site-to-Site VPN and private MPLS carrying the regulated bank and processor rails into security-group-controlled private subnets.
The architecture on AWS — two peered VPCs across two Availability Zones in the UAE Region, Amazon RDS for SQL Server Multi-AZ at the core, the risk engine isolated in its own VPC, and the regulated bank rails carried in intact.
Previous-state architecture: KamelPay's on-premises Dubai data center running the VM-based core SQL Server database and core application behind a firewall, a separate office network with HSM and PBX, IPsec and private MPLS links to the Central Bank of the UAE, Ajman Bank, and Network International, and mobile/web front ends already on AWS.
The starting point — the core database and application in a single Dubai data center, split from the mobile/web tiers already on AWS, with regulated IPsec/MPLS rails to banks and processors.

How it holds up

The delivered platform holds up against all six pillars of the AWS Well-Architected Framework. Operational excellence: the environment is re-implemented as Infrastructure as Code, and delivery ran on a standup-and-retrospective cadence with incremental validation at every cutover step. Security:the risk engine is isolated in its own VPC peered privately to the core, AWS Network Firewall fronts the public edge, bank VPN traffic terminates into security-group-controlled private subnets, the customer’s symmetric-key encryption scheme carried through the homogeneous migration intact, and account governance follows least-privilege IAM with AWS CloudTrail, Security Hub, and GuardDuty enabled. Reliability:Amazon RDS for SQL Server Multi-AZ provides automated cross-AZ failover with managed backups and point-in-time recovery — RPO and RTO in minutes versus nightly backups before — and both VPCs span two Availability Zones. Performance efficiency:the load-balanced application tier scales to absorb payroll-cycle peaks that the fixed on-premises estate could not. Cost optimization: a post-migration TCO retrospective applied Savings Plans, Reserved Instances, and right-sizing against observed utilization, projecting an annual run-rate of approximately $160K. Sustainability:right-sizing against real utilization replaced an over-provisioned, always-on on-premises estate. Data residency lands squarely in the AWS Middle East (UAE) Region — a sovereignty posture that matters for a regulated UAE payments business.

Outcomes

KPIResult
Production outcomesOn-premises core platform fully migrated to the AWS Middle East (UAE) Region, completing KamelPay’s cloud transition; zero downtime to payment processing and bank connectivity — the defining requirement, met — and zero hours of unplanned downtime since cutover; existing uptime, latency, and performance SLAs met or exceeded with secure data transfer and no corruption or loss.
Resilience postureSingle-data-center risk removed: the core database runs on Amazon RDS for SQL Server, Multi-AZ, with automated cross-AZ failover, and both VPCs span two Availability Zones. KamelPay moved from a production-only estate to full Dev, Test, and Production environments, with RPO and RTO measured in minutes versus nightly backups before.
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. 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 engine, like-for-like schema) 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. The road ahead: scheduler and notification modernization, formalized disaster recovery now that the workload is stable on AWS, and readiness to expand into Saudi Arabia on the AWS me-central-2 Region.
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 S3AWS KMSAWS CloudTrailAWS Security HubAmazon GuardDutyAmazon CloudWatchAWS IAM