Case Study
A Plan. Then Reality.
Moneyflex came to Sherdil Cloud with a straightforward goal: migrate their entire production AWS infrastructure to a new region. The original plan pointed to AWS Bahrain (me-south-1). Eight milestones, eight days, a tight daily working window of 1:00–3:00 PM KSA. Everything mapped, everything scheduled.
Then the region became unavailable.
Without skipping a beat, the destination changed to Frankfurt (eu-central-1). The timeline stayed the same. The scope stayed the same. Only the target moved — and with it, every assumption about network topology, compliance boundaries, and regional AWS service availability.
This is the story of how that AWS cross-region migration got done.
Full Production Stack. Nothing Left Behind.
This was not a partial lift-and-shift. Moneyflex's entire production-grade AWS environment had to move — live, intact, and operational by April 10.
EC2 Virtual Machines
All compute instances — application servers, cron jobs, utility VMs — migrated to Frankfurt.
Application Load Balancer
Recreated in the target region with updated target groups and health check configs.
S3 Buckets & Objects
All stored objects transferred using S3 Batch Operations — metadata and permissions preserved.
RDS Databases
Production databases migrated with full data integrity — with a major obstacle along the way.
IAM Policies & Roles
Global by nature but reviewed and validated for region-specific ARN references.
Auto Scaling Groups
Reconfigured with Frankfurt AMIs and updated subnet mappings.
WAF Configuration
All WAF rules, ACLs, and IP sets redeployed and validated in the target region.
DNS & SSL
Cloudflare proxy reconfigured. SSL certificates reissued via ACM in Frankfurt.
Component by Component. No Guesswork.
Every AWS service behaves differently in a cross-region migration. There is no single button that moves everything. Each component required its own tool, its own sequence, and its own validation step. Here is what the Sherdil Cloud team used for each one.
| Component | Strategy | Why This Approach |
|---|---|---|
| EC2 VMs | Custom AMIs → cross-region copy → launch in Frankfurt | Preserves the full OS, software, and config state of each instance without reinstalling from scratch. |
| S3 Data | S3 Batch Operations — UAE buckets → Frankfurt buckets | Handles large-scale object transfers efficiently, with error reporting and retry built in. |
| Load Balancer | Recreated in target region with updated target groups | ALBs are regional resources and cannot be copied — a clean rebuild ensures correct subnet and SG bindings. |
| Auto Scaling | Reconfigured ASG with Frankfurt AMIs & new subnets | ASG launch templates must reference region-local AMIs — old AMI IDs become invalid across regions. |
| WAF | Redeployed rules & ACLs in Frankfurt | WAF Web ACLs are regional — all rules, rate limits, and IP sets had to be reconstructed and tested. |
| IAM | Policies are global — reviewed & validated for region ARNs | IAM itself is global but any ARN hardcoded with the old region needed updating across all policies and roles. |
| RDS | SQL dump → transfer → restore in Frankfurt RDS | Snapshot copy was blocked by a lost KMS key. Manual dump-restore was the only safe path forward. |
The Key That Wasn't There
Halfway through the migration, the team hit a wall. Not a configuration problem. Not a permissions issue. Something far more fundamental — the production RDS instance was encrypted using a customer-managed KMS key, and that key was gone.
In AWS, if you lose access to a customer-managed KMS key, your encrypted snapshots are effectively locked. You cannot copy them to another region. You cannot restore them into a new instance. The standard cross-region migration path for RDS — snapshot copy — was completely closed.
The team stepped around the AWS layer entirely. Instead of moving the encrypted snapshot, they moved the data — bypassing encryption lock-in at the infrastructure level and going directly to the database engine.
Connected directly to the source RDS instance in the UAE region while it was still accessible and running.
Performed a full database dump using mysqldump / pg_dump — capturing the full schema, data, indexes, and stored procedures.
Transferred the dump file securely to Frankfurt — the data moved as an application-level export, not as an encrypted AWS snapshot.
Spun up a fresh RDS instance in Frankfurt (eu-central-1) with a new, properly managed KMS key from day one.
Restored the dump into the new instance, validated row counts, ran integrity checks, and confirmed application connectivity before signing off.
Eight Days. Eight Milestones.
Every working day from April 2 to April 10 was a milestone. Sessions ran from 1:00–3:00 PM KSA daily. April 4 and 5 were excluded. The countdown to go-live was always visible — and the team kept pace.
M1 — Discovery & Assessment
Full inventory of running services, architecture documentation, backup verification, and target region confirmation. The foundation for everything that followed.
M2 — Infrastructure Setup
Built the entire Frankfurt environment from scratch: VPC, security groups, ACM certificates, ECR repositories, Application Load Balancers, WAF, and DNS configuration.
M3 — Data Migration
All databases migrated via RDS/DMS. File storage transferred to Frankfurt S3. Backup retention policies reviewed and updated. This is where the KMS crisis was resolved.
M4 — Application Re-Deployment
ECS Fargate clusters deployed across Prod, Stage, and Dev environments. EC2 cron servers configured. All CI/CD pipelines updated to point at Frankfurt resources.
M5 — Security & Compliance
WAF rules validated. SSL termination confirmed. IAM policies audited. Secrets Manager entries updated. Cloudflare proxy integration verified end-to-end.
M6 — Testing & Optimisation
Full functional and load testing completed. CloudWatch dashboards validated. Cost review signed off. Go-live approval obtained from the Moneyflex team.
M7 — GO-LIVE & Cutover
DNS cutover to Frankfurt at exactly 1:00 PM KSA. Smoke tests run immediately post-cutover. UAE environment frozen and locked. Live monitoring activated.
M8 — Stabilisation & Close
Post-go-live monitoring period. Full documentation updated. UAE decommission plan prepared. Formal project sign-off completed with the client.
Live on Schedule. Zero Data Lost.
On April 10 at 1:00 PM KSA, Moneyflex went live on Frankfurt. The DNS flipped. The smoke tests passed. The UAE environment went dark. Eight days of precise, structured execution — including a mid-migration crisis that would have stalled most teams — delivered exactly what was promised.
on Schedule
Across All Services
Migrated
Resolved Mid-Flight
Your Infrastructure, Our Responsibility.
Whether it’s a planned migration or a fire drill at midnight, Sherdil Cloud keeps your systems moving.