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.
Project snapshot
- Starting environment
- Java monolith and reporting database on managed servers in a single colocation facility.
- Business constraint
- Exit physical hardware in a defined window, with limited AWS experience on a small platform team and partner integrations pinned to fixed egress IPs.
- Migration approach
- Waves 0–3: AWS landing zone, RDS via DMS, ECS Fargate replatform, then production DNS cutover. Business logic was not rewritten in the first pass.
- Cutover / rollback
- Lowered DNS TTL, one-week parallel run, rollback runbook tested in staging before the production switch.
- Resulting operating model
- Production and mirrored staging on AWS, Infrastructure as Code (Terraform), automated RDS backups, trained on-call path and a post-migration cost review. Outcomes remain qualitative — no savings percentages published.
- Client
- B2B SaaS vendor serving mid-market customers (anonymized)
- Stack
- ECS Fargate, ALB (multi-AZ), RDS PostgreSQL Multi-AZ, read replica, ElastiCache Redis, S3, CloudFront, Secrets Manager, Terraform
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