AWS migration checklist

Cloud migrations fail when teams treat them as a weekend DNS flip. This checklist walks product and platform teams through discovery, target architecture, security, migration strategy, data movement, testing and cutover — aligned with how Kode Builder executes AWS migrations for SaaS, e-commerce and logistics products. Use it internally or share with migration partners before work begins.

1. Discovery and Application Inventory

You cannot migrate what you have not cataloged. Document every workload before choosing a strategy.

• All applications, services and batch jobs listed with owners
• Dependencies mapped (databases, queues, third-party APIs, file shares)
• Traffic patterns documented: peak RPS, seasonality, background jobs
• Data stores inventoried with size, growth rate and sensitivity class
• Current hosting costs baseline captured for TCO comparison
• Technical debt and single points of failure identified
• Compliance scope defined (PCI, HIPAA, SOC2, data residency)
• Migration goals ranked: cost, reliability, scale, velocity, exit from datacenter

2. Target AWS Architecture Design

Design the landing zone and application topology before moving production traffic.

• AWS account structure decided (prod/staging/dev separation)
• VPC design with public/private subnets across multiple AZs
• Compute choice selected per workload (ECS, EKS, EC2, Lambda)
• Managed databases chosen (RDS, Aurora, DynamoDB) with sizing estimates
• Object storage (S3) and CDN (CloudFront) plan documented
• Caching layer (ElastiCache) evaluated where needed
• Infrastructure as Code tool selected (Terraform, CDK, CloudFormation)
• Architecture reviewed against AWS Well-Architected pillars

3. Security, Identity and Compliance

Security belongs in phase one — retrofitting IAM and encryption after cutover is painful.

• IAM roles follow least privilege; no long-lived access keys in apps
• Secrets stored in AWS Secrets Manager or SSM Parameter Store
• Encryption at rest enabled for RDS, S3, EBS and backups
• TLS enforced in transit; certificates managed (ACM)
• WAF and Shield evaluated for public endpoints
• Security groups and NACLs documented with review process
• CloudTrail, Config and GuardDuty enabled for audit visibility
• Data residency and backup retention policies defined

4. Migration Strategy per Workload

Pick the lightest strategy that meets reliability goals — not everything needs refactoring on day one.

• Each workload tagged: rehost, replatform, refactor or retire
• Rehost (lift-and-shift) candidates identified with compatibility checks
• Replatform targets mapped (e.g. self-managed DB → RDS)
• Refactor scope bounded for post-migration phases
• Wave plan sequenced: low-risk services first, customer-facing last
• Downtime budget and maintenance windows agreed with stakeholders
• Parallel-run or blue/green approach selected where zero downtime required
• Cost estimate per wave validated in AWS Pricing Calculator

5. Data Migration and Synchronization

Data is usually the longest pole — plan exports, replication and validation early.

• Migration method chosen: snapshot restore, DMS, logical dump, S3 sync
• Initial bulk load tested with row counts and checksum validation
• Ongoing replication or delta sync configured before cutover
• Large file/object migration plan for S3 or EFS
• Schema compatibility verified (charset, indexes, stored procedures)
• Data masking applied for non-production environments
• Rollback data snapshot taken immediately pre-cutover
• Post-migration reconciliation report signed off

6. Networking, DNS and Cutover Planning

Traffic routing changes need runbooks, TTL awareness and communication plans.

• Route 53 or DNS provider records documented with current TTLs
• TTL lowered ahead of cutover window
• Load balancer health checks configured and tested
• VPN, Direct Connect or peering requirements validated
• Static IP or egress dependencies identified (webhooks, partner allowlists)
• Cutover runbook with ordered steps and owners written
• Rollback runbook tested in staging
• Customer and internal comms scheduled for maintenance window

7. Testing, Observability and Validation

Prove parity before switching production — functional, performance and security.

• Staging environment mirrors production topology
• Automated regression suite passes against AWS staging
• Load or soak test completed at expected peak + headroom
• CloudWatch dashboards, alarms and log aggregation configured
• On-call rotation and escalation paths defined for cutover night
• Synthetic monitoring probes critical user journeys
• Backup restore drill completed successfully
• Penetration or vulnerability scan scheduled if required

8. Post-Migration Optimization and Operations

Migration day is not the finish line — stabilize, optimize and document.

• 72-hour hypercare period staffed with engineering coverage
• Cost Explorer and budgets configured with alerts
• Right-sizing review scheduled after two to four weeks of metrics
• Reserved Instances or Savings Plans evaluated for steady workloads
• Legacy environment decommission plan with data archival
• Runbooks updated: deploy, rollback, incident response
• CI/CD pipelines point to AWS environments exclusively
• Post-migration retrospective captured for wave two