The Migration Is the Easy Part
Moving your application to the cloud is solved technology. AWS, GCP, and Azure have documented migration paths for every stack. The infrastructure tools are mature. The problem is everything that happens when you assume the migration is done.
Here are the 12 things to verify before you redirect DNS.
The Checklist
1. Database connection pooling: Application servers multiply in the cloud. Each server opens connections to your database. Without connection pooling via RDS Proxy or PgBouncer, you will exhaust database connection limits under modest load.
2. Environment variables: Every secret, every connection string, every third-party API key. Verify in the actual deployed environment, not just locally. Missing env vars are the most common cause of post-migration failures.
3. File storage paths: Applications that write to the local filesystem fail silently in containerized or multi-instance deployments. Every file write should go to S3 or equivalent object storage.
4. Session management: If sessions are stored in memory, they die when instances restart. Verify sessions go to Redis or the database.
5. Logging and monitoring: Console.log does not work in production cloud deployments. Verify structured logs flow to CloudWatch, Datadog, or equivalent. Set up alerts before traffic arrives.
6. Auto-scaling behavior: Test scale-up and scale-down. Verify your application handles multiple instances without race conditions. Verify the load balancer health checks actually work.
7. SSL certificate renewal: Automated certificate renewal via ACM or Let's Cert. Verify the renewal process before the first certificate expires.
8. Backup and recovery: Automated database snapshots with tested restore procedures. "We have backups" is not enough — "we restored from backup in 45 minutes last Tuesday" is.
9. Cost alerts: Set billing alarms before you go live. Misconfigured auto-scaling has produced $50,000 cloud bills. A $200 alert is cheap insurance.
10. DNS TTL: Lower TTL to 60 seconds 48 hours before cutover. This makes rollback faster if needed.
11. Rollback plan: Know exactly what to do if the migration fails. Which steps to reverse, in which order, how long it takes. Write it down before migration day.
12. Load test: Real traffic has different characteristics than you expect. Load test at 2x your expected peak before go-live, not after.
The migrations that fail skip 3 of these. The ones that succeed check all 12.