Product and company names withheld. We document the migration pattern and technical decisions; cost savings percentages and uptime SLAs are not published without client approval.
The Client
A B2B SaaS vendor serving mid-market customers in a regulated adjacent industry (details omitted). The product ran as a Java monolith with a separate reporting database on managed servers in a single colocation facility. Growth strained manual provisioning and backup processes; leadership mandated exit from physical hardware within a defined window.
The Challenge
- Single-datacenter risk — no tested disaster recovery to another site
- Environment drift between staging and production
- Database backups restored manually — recovery time not meeting internal targets
- Partner integrations pinned to fixed egress IPs and long DNS TTLs
- Small platform team with limited AWS experience
Migration Strategy
Kode Builder used a wave-based plan aligned with our AWS migration checklist:
- Wave 0: AWS landing zone — multi-account structure, VPC, IAM baseline, Terraform repo, CI/CD to staging
- Wave 1: Replatform database to RDS PostgreSQL with DMS initial load and ongoing replication
- Wave 2: Containerize application (ECS Fargate) — no refactor of business logic in first pass
- Wave 3: Cutover production DNS with lowered TTL; parallel run one week; rollback runbook tested in staging
Strategy per workload: replatform for database, rehost/replatform hybrid for app tier, refactor deferred for microservices split post-stabilization.
Target Architecture
- ECS Fargate services behind Application Load Balancer across two AZs
- RDS PostgreSQL Multi-AZ; reporting read replica for heavy analytics queries
- ElastiCache Redis for session and job broker
- S3 for file uploads; CloudFront for static assets
- Secrets Manager for credentials; CloudTrail and GuardDuty enabled
- CloudWatch dashboards, alarms and structured application logging
- NAT Gateway with VPC endpoints for S3 to reduce egress costs (optimized post-cutover)
Compute choice documented in our EC2 vs ECS vs EKS vs Lambda guide — ECS Fargate matched team size and container goal without EKS overhead.
Outcomes
After production cutover and a stabilization period:
- Production runs in AWS with documented runbooks and Infrastructure as Code
- Staging mirrors production topology — reduced "works in staging" surprises
- Automated RDS snapshots and tested restore procedure
- Platform team trained on deploy pipeline and incident escalation paths
- Post-migration cost review identified right-sizing and NAT endpoint improvements — ongoing FinOps using our cost optimization checklist
Cutover completed within the agreed maintenance window without activating rollback. Brief hypercare coverage followed for alarm tuning and partner IP allowlist updates.
Lessons for Similar Migrations
- Start DNS TTL reduction two weeks before cutover
- Treat partner allowlists and webhook URLs as migration blockers — inventory early
- DMS validation reports must be signed off before traffic switch
- Defer architecture rewrites until AWS operations are boring