Complete website migration guide: steps and considerations for changing hosting

Website migration sounds simple on paper — copy the files, point DNS at the new server — but in practice most teams stumble over the small details: database character-set mismatches, upload directories with the wrong permissions, mail services still bound to the old server IP, or a forgotten cron job that never made it to the new machine. DNS propagation delays, data loss, expired SSL certificates, and configuration differences can turn a routine migration into a post-mortem. The workflow below comes from real migrations and fits roughly 95% of small and mid-sized websites.

Pre-migration preparation

1. Full backup

A backup isn't just "a copy for reference" — it has to let you restore the pre-migration state completely. Besides site files, that means configuration files, cron jobs (crontab), environment variables, and mail data.

# File backup
tar -czf website-backup-$(date +%Y%m%d).tar.gz /var/www/

# Database backup
mysqldump -u root -p --all-databases > db-backup-$(date +%Y%m%d).sql

# Config backup
tar -czf config-backup.tar.gz /etc/nginx/ /etc/apache2/

After the backup finishes, do two things: download the archives to your local machine or object storage instead of leaving them only on the old server, and actually extract them once to confirm they can be restored. Many teams only discover a corrupted backup when something breaks; this step surfaces the problem early.

2. Check new environment compatibility

A new server is not simply "the same empty machine" — version drift is the most common hidden pitfall:

  • PHP/Node.js/Python versions matching or backward-compatible with the old environment
  • Database version compatibility — watch for character-set and sql_mode differences when upgrading across major versions
  • Required system extensions and libraries (e.g. PHP gd, imagick, redis)
  • Sufficient disk space and inodes — small sites with many files often fail here

3. Lower TTL

Reduce DNS TTL to 300 seconds (5 minutes) 48 hours before migration so the new records propagate in minutes rather than a day. Don't forget to restore the TTL to its normal value (typically 3600 or 86400) after the switch, otherwise later DNS edits will spread more slowly.

4. Pick a window and prepare a checklist

Schedule the migration during a traffic low point, such as early morning on a weekday. Also agree that no other deploys happen on migration day, so a failure isn't masked by overlapping changes.

Migration execution

  1. Set up the new environment with the same software stack and restore configuration; get Nginx/PHP/database running before loading production data.
  2. Migrate data — use rsync for files and a MySQL dump/import for databases. For larger sites, run a full rsync first and then an incremental rsync inside the maintenance window to shorten downtime. After importing, run FLUSH PRIVILEGES and verify row counts match the old database.
  3. Test the new environment via the hosts file or direct IP before switching DNS. Verify login, payment callbacks, uploads, and search — features that depend on absolute URLs and sessions are most likely to break.
  4. Switch DNS records (A/AAAA or NS) to the new server; if you use a CDN, point its origin back to the new IP.
  5. Monitor and verify:
dig +short example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

Then confirm DNS resolution with dig/nslookup, HTTP responses with curl, the SSL certificate, and every core function of the site.

Migration strategy comparison

Strategy Downtime Risk Best for
Full cutover 1-2 hours Medium Small static sites, low-traffic business sites
Incremental rolling 5-15 minutes Low Mid-sized sites with continuously changing data
Blue-green parallel Zero downtime Higher (needs double resources) E-commerce and SaaS that cannot tolerate downtime

For most personal and SMB sites, incremental rolling migration offers the best value: with solid preparation, the actual "switch" window is often under half an hour.

Common issues

Issue Solution
DNS propagation delay Lower TTL early, wait 24-48 hours
SSL mismatch Reissue or install certificate on new server
DB connection failure Check database user and host permissions
File permission errors Check file/directory permissions
Email delivery failure Update SPF/DKIM/DMARC records, confirm the new IP isn't blacklisted

Rollback plan

Should be able to roll back within 30 minutes:

  1. Point DNS back to old server
  2. Keep old server for at least 7 days
  3. Keep full backups

Rollback isn't "starting over" — write down the trigger conditions and the exact steps in advance, and make sure at least two people know where that document lives.

16IDC Takeaway

90% of migration issues can be prevented with thorough preparation. Before you start, walk a checklist: backup restorable, compatibility verified, TTL lowered, rollback steps documented. Use trial periods to fully test new hosting before committing; for choosing a reliable provider, browse the server selection category for reviews and comparisons.