← Articles

April 4, 2026 · Tim Fraser, Cloud Operations Lead

Post-Migration AWS Checklist: What to Verify After Moving to the Cloud

The migration is done. Workloads are running on AWS, traffic is flowing, and the team is ready to move on. Except there's a gap between "it works" and "it's production-ready" — and that gap is where outages, security incidents, and surprise bills live.

Migrations are stressful. Things get configured as "good enough for now" with the intention of fixing them later. Later rarely comes. This checklist covers what commonly gets missed and causes real problems weeks or months afterward.

DNS and certificates

Verify DNS propagation is complete. Use dig or an online checker to confirm your domain resolves to the correct AWS endpoints from multiple locations. DNS caching means some users may hit old records for up to 48 hours. Check that old records pointing to previous infrastructure have been removed. Confirm SSL certificates cover all subdomains. A common miss: certificates for example.com but not www.example.com or api.example.com. Another: certificates imported from the previous host instead of using ACM, which means no auto-renewal. Check certificate expiry dates. Imported certificates have fixed expiry dates. Know what they are.

Backups and recovery

Verify RDS automated backups are enabled. Check the retention period — the default is 7 days, which may be less than your policy requires. Confirm the most recent snapshot timestamp looks right. Test a restore. Having backups configured is different from having backups that work. Restore a snapshot to a temporary instance and verify the data. Do this in the first week while urgency is fresh. Check EBS snapshot policies. EC2 instances don't have automatic backups unless you configure Data Lifecycle Manager policies. Verify S3 versioning and lifecycle policies. Versioning protects against accidental deletions. Lifecycle rules transition old versions to cheaper storage classes.

Security configuration

Audit security groups. During migrations, groups often get broad rules to avoid connectivity issues during cutover. Rules allowing 0.0.0.0/0 on SSH, or "all traffic" used for debugging, need to be tightened now. Remove temporary IAM users and access keys. Migration teams create users with broad permissions for data transfer tools and scripts. These should be deactivated once migration is complete. Check the IAM credential report for users or keys created during the migration window. Verify encryption at rest. EBS volumes, RDS instances, and S3 buckets should be encrypted. If encryption was skipped for speed during migration, plan to enable it now.

Monitoring and alerting

Set up CloudWatch alarms. At minimum: CPU and memory on EC2/ECS, database connections and storage on RDS, error rates on ALBs, and Lambda errors. If these weren't part of the migration scope (they usually aren't), set them up now. Enable CloudTrail. Create a trail logging to S3 with all regions enabled. The default 90-day Event History isn't enough for audit purposes. Configure billing alerts. Set up an AWS Budget based on projected cost. You don't know what "normal" looks like yet, so set a generous threshold and tighten after 60 days.

Cost baseline

Establish what normal spend looks like. Check Cost Explorer weekly for the first 30 days. Group by service and note the daily run rate. This baseline is how you'll detect anomalies going forward. Check for migration leftovers. DMS replication instances, temporary EC2 instances, S3 buckets with data dumps — frequently left running after migration. They cost money every day. Right-size within 30 days. Lift-and-shift typically provisions the same sizes as on-premises, which were often oversized. After two weeks of traffic, downsize anything below 30% CPU utilisation.

Automating the post-migration review

Working through this manually takes half a day. The bigger problem is that many items need ongoing verification — security groups drift, backups can stop working, costs creep up.

plainfra can verify most of this list in a single question. Ask "Run a post-migration health check" or be specific: "Are all my RDS instances being backed up?" Live results from API calls, not a static report.

Weekly health reports then keep checking automatically, so you don't need to remember to re-run the checklist next month.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.