Hosting28 March 202615 min read

Server Migration Checklist: How to Move Hosts Without Losing Your Site

You have decided to move to better hosting. Good. But between here and there lies a minefield — DNS propagation delays, SSL certificates that do not transfer, databases that corrupt during export, and emails that vanish into the void. Here is the complete checklist to get through it without losing your site, your data, or your mind.

Why migrations go wrong

Server migration is one of the highest-risk operations in web infrastructure. You are moving a live website — with active visitors, incoming emails, and possibly processing transactions — from one server to another while keeping everything running. It is like changing the engine on a car while driving it.

Most migration problems fall into three categories: things that were not copied correctly, things that break because the new server is configured differently, and things that happen during the DNS propagation window when traffic is split between old and new servers. Every item on this checklist addresses one of these risks.

Phase 1: Before the migration (1 to 2 weeks before)

Lower your DNS TTL

This is the most commonly skipped step — and the one that causes the most problems. Your DNS records have a TTL (time to live) value that tells DNS resolvers how long to cache the record. If your TTL is 86400 (24 hours), then after you change DNS, some visitors will still be directed to your old server for up to 24 hours.

At least 48 hours before migration, log into your DNS provider and lower the TTL on your A record, CNAME records, and MX records to 300 (5 minutes). Wait 48 hours for the old high TTL to expire from caches worldwide. Then when you change DNS during the actual migration, propagation happens in minutes instead of hours.

Take a full backup of everything

  • All website files — including hidden files like .htaccess
  • Database — full SQL export with all tables, triggers, and stored procedures
  • Email accounts and their contents (if email is on the same server)
  • SSL certificate files (certificate, private key, CA bundle) if using a paid certificate
  • Cron job configurations
  • Server configuration files (php.ini settings, .htaccess rules, Nginx config)

Store the backup somewhere independent of both the old and new server — a local computer, cloud storage, or a separate backup service. If both servers have problems simultaneously, you need an independent copy.

Document your current configuration

Before you touch anything, record the current state:

  • PHP version on the old server
  • MySQL or MariaDB version
  • PHP memory limit, max execution time, upload limits
  • Installed PHP extensions (your site may depend on specific ones)
  • All DNS records — A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC
  • Current server IP address
  • Any custom Apache or Nginx rewrite rules

This documentation becomes your reference when setting up the new server. If something breaks, you can compare configurations line by line to find the difference.

Set up monitoring on both servers

Before the migration, set up Uptrue monitoringon your current site. This establishes a performance baseline — you will know your normal response time, uptime pattern, and SSL status. After migration, you can compare the new server's performance against this baseline.

  1. Add an HTTP monitor for your main domain
  2. Add a keyword monitor checking for your site title or key content
  3. Note your current average response time — this is your baseline
  4. Set up alerts on Slack, email, or Teams

Decouple email from hosting (if possible)

If your email runs on the same server as your website, migrate email to a dedicated service first. Google Workspace, Microsoft 365, or Zoho Mail all handle email independently of your web hosting. Doing this before the website migration removes the biggest risk — lost emails during DNS propagation.

If you cannot decouple email before migration, be extremely careful with MX records during the DNS switch, and keep the old server running for at least 7 days after migration to catch any emails that arrive there.

Phase 2: Set up the new server (before DNS change)

Configure the new server to match

Using your documentation from Phase 1, set up the new server with matching or better specifications:

  • Same or newer PHP version (test compatibility if upgrading)
  • Same or newer MySQL/MariaDB version
  • All required PHP extensions installed
  • PHP settings matching or exceeding old server (memory_limit, max_execution_time, upload_max_filesize)
  • Same timezone configuration

Upload files and import database

  1. Upload all website files to the new server via SFTP or the hosting provider's file manager
  2. Import the database from your SQL export
  3. Update database connection settings in your configuration files (wp-config.php for WordPress, .env for Laravel, etc.)
  4. Set correct file permissions — 644 for files, 755 for directories on Linux servers
  5. Verify .htaccess or Nginx configuration is in place

Test on the new server before changing DNS

This is critical. Do not change DNS until you have verified the site works on the new server.

  1. Access the site using the new server's IP address or temporary URL
  2. Or edit your local hosts file to point your domain to the new server IP
  3. Test every important page — homepage, product pages, contact page, blog
  4. Test all forms — submit a test enquiry, test the checkout process
  5. Check that images and media files load correctly
  6. Verify SSL works (if using a temporary URL, test HTTP first; SSL comes after DNS)
  7. Check for mixed content warnings in the browser console
  8. Test the admin panel / CMS login
  9. Verify cron jobs are configured and running

Set up SSL on the new server

If using Let's Encrypt, you typically need DNS to point to the new server before issuing a certificate (because Let's Encrypt validates domain ownership). Some hosting providers support DNS validation, which lets you issue the certificate before the DNS change. If available, use DNS validation. If not, plan a brief HTTP-only window while you issue the certificate after DNS change, or use a paid certificate that you can transfer.

Set up monitoring on the new server

Add an HTTP monitor in Uptrue pointing to the new server's IP address or temporary URL. Verify it responds correctly and note the response time. This confirms the new server is healthy before you send real traffic to it.

Monitor your migration in real time

Set up monitoring on both old and new servers before the switch. See response times, uptime, and SSL status throughout the migration process.

Start Free Monitoring

Phase 3: The DNS switch

Final sync before switching

If your site has changed since the initial file copy — new posts, form submissions, orders — do a final sync:

  1. Export a fresh database from the old server
  2. Import it to the new server (replacing the old import)
  3. Copy any new uploaded files
  4. Verify the new server has the latest content

Update DNS records

Log into your DNS provider (this might be your domain registrar or a DNS service like Cloudflare). Update the following records to point to the new server:

  • A record — point to the new server's IP address
  • AAAA record — if the new server has an IPv6 address
  • CNAME records — update www and any subdomains
  • MX records — only if email is moving too (skip if you decoupled email)

Do NOT change nameservers unless you are also moving DNS management. Changing nameservers propagates more slowly than changing individual records.

Issue SSL certificate (if not done in Phase 2)

Once DNS points to the new server, run Certbot or your hosting provider's SSL tool to issue a Let's Encrypt certificate. Verify HTTPS works. Check for mixed content. Force HTTPS redirect if your site requires it.

Monitor during propagation

During DNS propagation, traffic is split between old and new servers. Monitor both:

  • Your Uptrue HTTP monitor on your domain catches any downtime during the switch
  • Keyword monitoring verifies your content is loading (not a parking page or error)
  • SSL monitoring confirms the certificate is valid on the new server
  • Response time monitoring shows whether the new server is faster (it should be — that is why you migrated)

Phase 4: After the migration (1 to 7 days after)

Verify everything works

  • Test from multiple devices and networks (not just your office network)
  • Check Google Search Console for crawl errors
  • Verify Google Analytics and tracking codes are working
  • Test all email deliverability — send tests to Gmail, Outlook, and Yahoo
  • Check that cron jobs are firing correctly
  • Verify backups are running on the new server

Keep the old server running

Do not decommission the old server immediately. Keep it running for at least 7 days after migration. During this time:

  • Check for any emails that arrived at the old server during propagation
  • Check for any form submissions or orders that went to the old server
  • Keep it as a rollback option in case something goes wrong on the new server

Compare performance

After 7 days on the new server, compare Uptrue's response time data with your pre-migration baseline. You should see:

  • Lower average response time
  • Fewer response time spikes
  • More consistent performance throughout the day
  • Better TTFB on database-heavy pages

If performance is not better, investigate. You migrated for a reason — make sure the new hosting actually delivers.

Update DNS TTL back to normal

Once you are confident the migration is complete and stable, increase your DNS TTL back to a normal value — 3600 (1 hour) or 86400 (24 hours). Low TTLs cause more DNS lookups, which adds a small overhead to every new visitor.

Cancel old hosting

After 7 to 14 days with no issues on the new server, and after retrieving any straggler data from the old server, you can safely cancel the old hosting account. Take a final backup from the old server before cancellation — just in case.

The complete checklist

Here is the full migration checklist you can follow step by step:

One to two weeks before

  1. Lower DNS TTL to 300 seconds on all records
  2. Take a complete backup (files, database, emails, config)
  3. Document current server configuration (PHP version, extensions, settings)
  4. Document all DNS records
  5. Set up Uptrue monitoring on current site (baseline)
  6. Decouple email to a separate service if possible
  7. Purchase and set up the new hosting account

One to two days before

  1. Configure new server to match old (PHP, MySQL, extensions)
  2. Upload files and import database to new server
  3. Update configuration files with new database credentials
  4. Set correct file permissions
  5. Test new server via IP or hosts file — all pages and forms
  6. Issue SSL certificate on new server (if DNS validation available)
  7. Set up Uptrue monitoring on new server IP

Migration day

  1. Do a final database and file sync from old to new server
  2. Update DNS A record to new server IP
  3. Update DNS CNAME records for www and subdomains
  4. Issue SSL certificate if not done earlier
  5. Verify HTTPS works and force redirect
  6. Monitor response times and uptime throughout the day

One to seven days after

  1. Test from multiple devices and networks
  2. Check old server for straggler emails and data
  3. Verify Google Search Console shows no new errors
  4. Confirm analytics tracking is working
  5. Verify backups are running on new server
  6. Compare response time data — old versus new
  7. Increase DNS TTL back to normal
  8. Take final backup from old server
  9. Cancel old hosting

Do not migrate blind

Monitor your old and new server throughout the migration. Catch DNS issues, SSL failures, and performance problems the moment they happen — not when a customer emails you.

Got questions?

Frequently asked questions

Everything you need to know about Uptrue — no fluff.

How long does DNS propagation take during a server migration?
DNS propagation typically takes 1 to 48 hours, though most changes propagate within 4 to 8 hours. The time depends on your DNS record TTL (time to live) settings, your registrar, and the DNS resolvers used by your visitors' ISPs. Before migration, lower your DNS TTL to 300 seconds (5 minutes) at least 48 hours in advance. This ensures that when you change the DNS records to point to your new server, the change propagates much faster. If you skip this step, old DNS records with high TTLs can persist for up to 48 hours, sending visitors to your old server.
Near-zero downtime is possible with careful planning but true zero downtime is very difficult. The strategy is to keep your old server running while the new server is fully set up and tested. Lower DNS TTL in advance, copy all files and database to the new server, test thoroughly on the new server using a temporary URL or hosts file entry, then update DNS. During propagation, some visitors go to the old server and some to the new server. Both should be functional. The gap where things can go wrong is if data changes on the old server during propagation — form submissions, orders, comments — that do not make it to the new server.
If you use Let's Encrypt (the most common free SSL), you do not transfer it — you issue a new certificate on the new server. Install your site on the new server, verify it works on HTTP, then run Certbot or your hosting provider's SSL tool to issue a new Let's Encrypt certificate. If you have a paid SSL certificate from a certificate authority, you can transfer it by exporting the certificate file, private key, and CA bundle from the old server and importing them to the new one. Most managed hosting providers handle SSL automatically — you just need to ensure DNS is pointing to them.
If your email is hosted on the same server as your website (common with cPanel hosting), email is the most dangerous part of a migration. During DNS propagation, some emails go to your old server and some go to your new server. Emails sent to the old server during propagation can be lost if that server is decommissioned before you retrieve them. The safest approach is to migrate email to a separate service (Google Workspace, Microsoft 365, or Zoho Mail) before migrating your website. This decouples email from hosting entirely. If you must migrate email with the site, keep the old server running for at least 7 days after migration to catch stragglers.
There are three ways. First, use the new server's IP address directly — most hosting providers give you a temporary URL like your-server-ip/~username. Second, edit your local hosts file (on Windows: C:\Windows\System32\drivers\etc\hosts, on Mac/Linux: /etc/hosts) to point your domain to the new server IP. This lets you browse your site on the new server while everyone else still sees the old one. Third, some hosting providers offer a staging URL. Test all critical pages, forms, checkout flows, and functionality before touching DNS.
Many managed hosting providers offer free migration as part of their onboarding. This is usually the easiest option — they have done thousands of migrations and have the process refined. However, you should still verify the migration yourself. Check every page. Test every form. Verify the database. Check that file permissions are correct. Run your monitoring on the new server before switching DNS. Free migration services are good at copying files but they cannot verify that your specific site's functionality works correctly — only you can do that.
Data loss during the DNS propagation window. After you update DNS but before propagation is complete, some visitors still reach the old server. If someone places an order, submits a form, or posts a comment on the old server during this window, that data exists only on the old server. If you decommission the old server too quickly, that data is lost. The solution is to keep the old server running for at least 7 days after migration, then export any new data from it. For ecommerce sites, consider putting the site in maintenance mode during the actual DNS switch to prevent split-brain data issues.
External monitoring catches migration problems in real time. Set up HTTP monitoring on both the old and new server before the migration. Monitor the new server using its IP address or temporary URL to verify it is working before DNS changes. After changing DNS, monitor your domain to catch any downtime during propagation. Set up keyword monitoring to verify your content is loading correctly — not a hosting error page or a partially migrated site. Response time monitoring confirms the new server actually performs better than the old one. Alert channels ensure you know instantly if anything goes wrong.