Website Migration Checklist

Last updated Oct 25, 2026 · 4 min read

Most migrations that go wrong don't fail on the copy. They fail on something small that nobody wrote down: a cron job, an email record, a hardcoded IP, a TTL of one day. This checklist covers moving an existing site to a new server or host while keeping the same domain. Work through it top to bottom. Each item is something that has broken a real migration.

Before the move

Inventory what you have

• List every domain and subdomain the site uses (www, api, cdn, mail).
• Export the full DNS zone from the current provider. Note the MX, TXT (SPF, DKIM, DMARC, verification records) and any CNAMEs.
• Record software versions on the old server: PHP/Node/Python, database, web server. php -v, mysql --version, nginx -v.
• Copy cron jobs (crontab -l for each user), environment variables, and the web server config.
• Note anything tied to the server's IP: firewall allowlists, payment gateway IP restrictions, API keys locked to an address.
• Check where email is hosted. If the old host runs your mailboxes, plan that migration separately.

Prepare DNS

• Lower the TTL on the records you'll change (usually @ and www A/AAAA) to 300.
• Wait at least one full old TTL before migration day. A 24-hour TTL means waiting 24 hours. Why this matters.
• If you're also changing DNS providers, do that first, days before the server move. Don't change nameservers and IPs together.

Back up

• Take a full file backup: tar czf site-files.tgz /var/www/example.com.
• Take a database dump: mysqldump --single-transaction -u USER -p DBNAME | gzip > db.sql.gz (or pg_dump -Fc DBNAME > db.dump).
• Copy backups off the old server and confirm they open.

Build the new server

• Match the language and database versions, or deliberately test the upgrade.
• Copy files: rsync -avz --delete old:/var/www/example.com/ /var/www/example.com/.
• Import the database and update credentials in the app config.
• Configure the web server for the real domain name, not just the IP.
• Plan TLS. Let's Encrypt's HTTP challenge can't succeed until DNS points at the new server. Either use the DNS-01 challenge, copy the existing certificate across, or accept a short window and issue right after the switch.
• Recreate cron jobs, queue workers and background services.
• Open the firewall for 80/443 and lock down SSH.

Test the new server before switching

This is the step people skip, because the site "isn't live yet". You can see it under the real domain without touching DNS.

• Check the homepage and headers with curl: curl -I --resolve example.com:443:NEW_IP https://example.com/. Details in the curl --resolve guide.
• Click through it in a browser. A skipdns.dev preview link loads the site from the new IP under its real hostname, with no hosts file edit, and you can send it to the client or your team.
• Log in to the admin area, submit each form, run a test checkout if there's a shop.
• Check that images, CSS and JS load from the new server, not the old one.
• Watch the new server's error log while you test: tail -f /var/log/nginx/error.log.
• Compare key pages old against new: diff <(curl -s https://example.com/) <(curl -s --resolve example.com:443:NEW_IP https://example.com/).

During the move

• Announce a content freeze: no new posts, orders or uploads on the old site for the next hour if possible.
• Put the old site in maintenance or read-only mode if the app supports it.
• Run a final sync: re-run rsync and take a fresh database dump and import, so nothing written since the first copy is lost.
• Spot-check the new server once more with the preview link or curl.
• Update the A record (and AAAA, if you use IPv6) to the new IP. Delete any stale AAAA record rather than leaving it pointing at the old server.
• Watch it switch: dig +short example.com @1.1.1.1 and @8.8.8.8. With TTL 300, expect a few minutes.
• Issue or confirm the TLS certificate on the new server as soon as DNS resolves there.

After the move

First hour

• Flush your local DNS and load the site normally. Confirm it's the new server (a response header or a test file helps).
• Test HTTPS on both example.com and www.example.com, and check the redirect between them.
• Send and receive a test email if any mail records were touched.
• Check that the old server's access log goes quiet as caches expire: tail -f /var/log/nginx/access.log.

First week

• Watch the new server's error logs and 404s daily.
• Confirm cron jobs and scheduled tasks ran (backups, emails, cache clears).
• Set up backups on the new server and test a restore.
• Check Google Search Console for crawl errors or a spike in server errors.
• Update any external IP allowlists (payment gateway, APIs, monitoring) to the new address.
• Raise the DNS TTL back to 3600 or higher.

Decommission

• Keep the old server running, untouched, for at least 7 days.
• Take one last backup of it before cancelling.
• Cancel the old plan and remove its DNS records, monitoring and SSH keys.

Common problems and quick fixes

• Site works for you, not for others. Different resolvers expire at different times. Check public resolvers before changing anything. See DNS propagation time.
• Mixed content or assets from the old domain. The CMS has hardcoded URLs. In WordPress, run wp search-replace 'http://old-url' 'https://example.com' --all-tables after taking a backup.
• Redirect loop after switching. Usually HTTPS forced at both a proxy and the app. Make sure the app trusts the proxy's X-Forwarded-Proto header.
• Emails stopped arriving. MX or SPF records weren't copied to the new DNS provider. Compare the zone with the export you made at the start.

Print this page or copy it into your ticket system. Ticking the boxes takes a few minutes, and debugging a missing record at midnight takes far longer.