On-Premises to Cloud Migration Checklist: 50 Things to Verify Before, During, and After

Cloud migration projects fail in predictable ways. Not usually because of architectural decisions — those get sufficient attention. They fail because someone forgot to check the database SSL certificate expiry, or didn't test the application with the new latency profile, or discovered that a dependency only supports IPv4 after migrating the network.

This checklist covers the things that get missed.

Pre-Migration Assessment

• Document every service, its dependencies, and its team owner
• Identify all external IP dependencies (firewall rules, partner systems that whitelist your IPs)
• Check software licence portability to cloud environments
• Verify all application dependencies support the target OS version
• Identify any hardcoded IP addresses in application configuration
• Check database character set and collation compatibility
• Identify any cron jobs and their schedules — where do they move?
• Document all DNS names used internally and externally
• Inventory all TLS certificates and their expiry dates
• Establish baseline performance metrics for current on-premises environment

Infrastructure Preparation

• VPC CIDR ranges don't overlap with existing VPCs or on-premises networks
• Subnets span at least two availability zones
• Security groups follow principle of least privilege
• All storage volumes have encryption enabled
• Backup policies are in place and tested before migration begins
• Route 53 health checks configured for all critical endpoints
• CloudTrail enabled on target AWS account

Application Readiness

• Application can handle increased network latency (cloud vs on-premises)
• Connection pool sizes are appropriate for the target instance type
• Database connection strings are in configuration files, not hardcoded
• Logging outputs to stdout/stderr or centrally configurable path
• Application health check endpoint exists and returns meaningful status
• Session handling works correctly across multiple instances
• Static asset serving is configured for S3/CloudFront (if applicable)

Data Migration

• Estimated migration time fits within the maintenance window (or CDC replication configured)
• Data validation queries prepared to verify record counts and checksums post-migration
• Sensitive data identified and confirmed to be encrypted during transfer
• Rollback procedure documented and tested

Cutover and Post-Migration

• DNS TTL reduced 24 hours before cutover
• Smoke tests prepared and ready to run immediately post-cutover
• Rollback decision criteria defined (what triggers a rollback decision?)
• On-premises environment kept running for 48 hours post-cutover
• All monitoring alerts active on migrated environment before cutover
• Team members on standby during and after cutover window