Cloud Migration Checklist: 20 Things to Verify Before Migrating

Cloud Migration Checklist: 20 Things to Verify Before Migrating

Failed cloud migrations almost always share the same root cause: inadequate preparation. Missing a single dependency, forgetting to export a backup, or overlooking a scheduled job can turn a smooth migration into a multi-hour incident. This checklist covers 20 specific things to verify before you move a single file or update a single DNS record.

Before You Start: The Discovery Phase

1. Inventory every running process

# On your current server
ps aux --sort=-%cpu | head -20
systemctl list-units --type=service --state=running

Document every service. Background workers, cron jobs, and monitoring agents all need to be accounted for.

2. Map all external dependencies

# Find all outbound connections
ss -tnp | grep ESTABLISHED
netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort -u

Each IP or hostname is a dependency: third-party APIs, SMTP servers, payment gateways, webhook endpoints.

3. Audit all cron jobs

# Check system crontabs
crontab -l
cat /etc/crontab
ls /etc/cron.d/
ls /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/

Every cron job needs to be recreated as a PandaStack cronjob with the equivalent schedule expression.

4. List all environment variables

# On the current server — never commit this output
printenv | sort > env-inventory.txt
# Review and document which are secrets vs config

Data Safety Checks

5. Verify your database backup is restorable

Don't just make a backup — test restoring it to a staging database before migration day.

pg_dump "$PROD_DB" > pre-migration-backup.sql
# Restore to a test database
psql "$TEST_DB" < pre-migration-backup.sql
# Verify with spot checks
psql "$TEST_DB" -c "SELECT COUNT(*) FROM users;"
psql "$TEST_DB" -c "SELECT MAX(created_at) FROM orders;"

6. Confirm backup file integrity

# For custom format pg_dump
pg_restore --list pre-migration-backup.dump | wc -l
# Should match the source

7. Document your database schema version

# If using migrations (e.g., Sequelize)
npx sequelize-cli db:migrate:status | grep "up"
# Record the last applied migration name

8. Identify large or binary data

# Find tables with large rows or BLOB columns
psql "$PROD_DB" -c "
SELECT tablename,
  pg_size_pretty(pg_total_relation_size(tablename::regclass)) AS size
FROM pg_tables WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(tablename::regclass) DESC;
"

Application Readiness Checks

9. Confirm your app has a health check endpoint

Your container needs a health check for the platform to know when it's ready:

curl http://localhost:3000/health
# Expected: {"status": "ok", "db": "connected"}

10. Test your Docker image locally

docker build -t my-app:migration-test .
docker run -p 3000:3000 --env-file .env.test my-app:migration-test
curl http://localhost:3000/health
docker stop $(docker ps -q)

11. Verify your .dockerignore excludes secrets

cat .dockerignore
# Must include: .env, *.pem, *.key, node_modules, .git

12. Confirm no hardcoded IPs or hostnames

grep -rn "192.168|10.0|172.16|localhost|127.0.0.1"   ./src --include="*.js" --include="*.py" --include="*.go"

Infrastructure Checks

13. Lower your DNS TTL 24 hours before cutover

If your current DNS TTL is 3600 seconds (1 hour), a failed cutover traps you for an hour before you can roll back. Lower it to 60 seconds the day before.

# Check current TTL
dig +nocmd your-domain.com A +noall +answer

14. Verify SSL certificate provisioning

On PandaStack, SSL is provisioned automatically. Verify the certificate is active before switching DNS by accessing your app at the platform URL: https://your-app.pandastack.io

15. Confirm your new database accepts connections

psql "postgresql://user:pass@pandastack-host:5432/mydb"   -c "SELECT current_timestamp;"

16. Verify environment variables are set in the new platform

# PandaStack CLI
panda env list

# Cross-reference against your env-inventory.txt
# Every production variable must be present

Operations Checks

17. Set up monitoring before cutover, not after

Configure uptime monitoring, error tracking, and log aggregation on the new environment while the old one is still running. That way, you have a baseline before traffic arrives.

18. Document your rollback plan

Write down the exact steps to revert: what DNS change to make, which database to reconnect to, which deploy to roll back to. Keep this doc in front of you during cutover.

19. Test your rollback procedure

# Simulate rollback by pointing back to old origin
curl -H "Host: your-domain.com" https://old-server-ip/api/health

20. Schedule cutover during low-traffic hours

# Check your analytics for traffic patterns
# Typically: Tuesday-Thursday, 2-5am local time for US apps
# Export traffic data from your analytics platform to confirm

Pre-Cutover Final Command

Run this right before you update DNS:

# Final verification: new env is green
curl -f https://your-app.pandastack.io/api/health && echo "GREEN: GO" || echo "RED: HOLD"

A "RED: HOLD" stops the migration. A "GREEN: GO" means you're ready. Completing this checklist takes a few hours but can save days of incident response. See [docs.pandastack.io](https://docs.pandastack.io) for platform-specific migration guides and [dashboard.pandastack.io](https://dashboard.pandastack.io) to get started.