KamelPay

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’s written starting position was to bring the same engine over under its own license, self-managed on Amazon EC2, avoiding managed database services altogether.

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 produced the migration strategy with documented 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. A dedicated Testing & Validation phase — functional testing of the migrated environment, data-integrity validation, and discrepancy remediation — preceded customer acceptance.

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.

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: the documented TCO retrospective applies Savings Plans, Reserved Instances, and right-sizing against observed utilization to reach a projected 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.