Moving a website to a new hosting provider is one of those tasks that sounds straightforward until you are halfway through it and your phone starts ringing with complaints that the site is down. A botched migration can mean hours of outage, lost orders, broken email, and a frantic scramble to roll things back. None of that has to happen. With the right sequence of steps, you can migrate a live website to a new server and keep it reachable throughout the entire process. This guide covers the full procedure from pre-migration DNS prep through final cutover and verification.

Why Website Migrations Cause Downtime

The root cause of most migration-related outages is not the file transfer itself. It is the mismatch between when you update your DNS records and when visitors around the world actually see those changes. DNS records are cached by resolvers everywhere, and that cache duration is controlled by the TTL (Time to Live) value on each record. If your A record has a TTL of 86400 seconds (24 hours) and you point it to your new server, visitors stuck on the old cache will hit the old server for up to 24 hours. Meanwhile, you may have already cancelled the old hosting or pointed your database somewhere else. That gap is where downtime lives.

Secondary causes include forgetting to migrate databases, misconfiguring SSL on the new host before cutover, not testing the new environment under the actual domain, and overlooking dependent services like email MX records or subdomains.

Step 1: Lower Your DNS TTL Several Days Before You Move

This is the single most important preparation step and it costs you nothing. Log into your DNS provider (wherever your nameservers are authoritative, not your registrar unless they are the same) and reduce the TTL on your A record and AAAA record to 300 seconds (5 minutes). Do this at least 48 to 72 hours before your planned cutover, because you need to wait out the current cached TTL before the lower value takes effect globally.

Most DNS control panels show TTL as a dropdown or a text field next to each record. Common interfaces:

  • Cloudflare: DNS tab, click the pencil icon on the A record, change TTL from Auto to 5 minutes.
  • cPanel / WHM zone editor: TTL column, type 300.
  • Route 53 (AWS): Edit record, TTL (seconds) field, enter 300.
  • GoDaddy / Namecheap: Advanced DNS section, edit the A record row.

Once you lower the TTL, any change you make to that A record will propagate to most resolvers within 5 minutes instead of 24 hours. That is your safety window during cutover.

After lowering your TTL, use the DNS Propagation Checker to confirm that resolvers around the world are picking up the updated TTL value before you proceed with the migration.

Step 2: Replicate Files and Database to the New Server

While the old server is still live and taking traffic, copy everything to the new host. Do not cut anything over yet. This is a read-only snapshot phase.

Copying Files

Use rsync over SSH for the fastest and most reliable file transfer. Replace the placeholders with your actual paths and credentials:

rsync -avz --progress -e "ssh -p 22" /var/www/html/ user@newserver.example.com:/var/www/html/

If you are on shared hosting without SSH access, use FTP with an FTPS client like FileZilla, or ask your new host if they support a server-to-server pull via their migration tool. Many modern hosts (SiteGround, WP Engine, Kinsta) have one-click migration plugins or built-in import tools.

Exporting the Database

For MySQL or MariaDB, export from the old server and import to the new one:

mysqldump -u dbuser -p dbname > site_backup_$(date +%Y%m%d).sql scp site_backup_*.sql user@newserver.example.com:~/ ssh user@newserver.example.com mysql -u newdbuser -p newdbname < site_backup_*.sql

If your site is WordPress, update the siteurl and home values in wp_options after the import, or use WP-CLI:

wp search-replace 'http://oldserver-ip' 'https://yourdomain.com' --all-tables

Step 3: Configure the New Host to Accept Your Domain

Before you touch DNS, the new server must be ready to serve your site for the real domain name, including a valid SSL certificate. If you flip DNS before SSL is configured, visitors will get a certificate error or a blank default page.

Setting Up a Virtual Host

On Apache, create a vhost config in /etc/apache2/sites-available/yourdomain.conf that includes your domain in the ServerName and ServerAlias directives. On Nginx, add your domain to the server_name line. Reload the web server after any config change.

sudo nginx -t && sudo systemctl reload nginx # or for Apache: sudo apachectl configtest && sudo systemctl reload apache2

Getting SSL Ready

If you are using Let's Encrypt, you cannot run Certbot with the HTTP-01 challenge until DNS is pointing to the new server. Use one of these approaches instead:

  • DNS-01 challenge: Proves domain ownership via a TXT record, so you can get a cert before DNS cutover. Certbot supports this with --preferred-challenges dns and many DNS providers have Certbot plugins.
  • Duplicate cert: If your registrar or Cloudflare controls DNS, create the TXT challenge record manually, issue the cert, then remove it.
  • Transfer existing cert: Copy your current cert and private key files from the old server to the new one before cutover (only practical for short-lived windows).
certbot certonly --preferred-challenges dns -d yourdomain.com -d www.yourdomain.com

Step 4: Test the New Server Using the Hosts File

This is the step most guides skip and it is the one that saves you. Before flipping DNS for the whole world, trick your own computer into hitting the new server by editing your local hosts file. This lets you browse your site on the new host under the real domain name to catch any broken links, missing images, or database connection errors.

On macOS or Linux, open a terminal and edit /etc/hosts. On Windows, use Notepad run as Administrator to open C:\Windows\System32\drivers\etc\hosts. Add a line like this:

203.0.113.45 yourdomain.com www.yourdomain.com

Replace 203.0.113.45 with the actual IP address of your new server. Save the file, flush your DNS cache, and open a browser. Everything you see will be loading from the new host. Check the homepage, log into the admin panel, submit a test form, and browse category pages. When you are satisfied, remove the hosts file entry before the final cutover step.

To flush your DNS cache:

# macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows: ipconfig /flushdns # Linux (systemd-resolved): sudo systemd-resolve --flush-caches

Step 5: Synchronise Any Content Changes Made During the Migration

If your site is active and taking user-generated content (form submissions, orders, comments, blog posts) while you were copying files, those changes happened on the old server and are not on the new one. You need to sync them before cutover.

Run rsync again in dry-run mode to see what changed:

rsync -avzn --progress -e "ssh" /var/www/html/ user@newserver.example.com:/var/www/html/

The -n flag is dry-run. Remove it to actually sync. For the database, export only rows added after your initial dump using a WHERE clause on a timestamp column, or run a full re-export if the site is small. For WooCommerce stores or high-volume sites, schedule the cutover during the lowest traffic window and accept a brief maintenance mode window of under 5 minutes.

Step 6: Cut Over DNS

Because you already lowered the TTL to 300 seconds (Step 1), this is now low risk. Go to your DNS provider and update the A record (and AAAA record if you have IPv6) to the new server IP. If you are also moving to Cloudflare, update the nameservers at your registrar and import your DNS records in Cloudflare before switching nameservers.

The change should propagate to most resolvers within 5 to 10 minutes. During that window, some visitors will still hit the old server. This is why the old server must stay live and unchanged for at least 30 to 60 minutes after cutover. Do not cancel old hosting or shut down the old server immediately.

Keep an eye on both servers during this window. Tail the access logs on both:

ssh oldserver 'tail -f /var/log/nginx/access.log' ssh newserver 'tail -f /var/log/nginx/access.log'

When traffic on the old server drops to near zero, the cutover is complete.

Step 7: Verify Everything Is Working on the New Server

Do not just look at the homepage. Run a thorough check:

  1. Confirm the SSL certificate is issued for the correct domain and is not the old cert being cached. Check the certificate details in your browser or run: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates
  2. Check that www redirects to the apex domain (or vice versa) as intended.
  3. Verify email is not broken. Check MX records still point where they should.
  4. Test any forms, logins, or checkout flows.
  5. Check your monitoring or uptime tool to confirm it reports the new IP.

Use the DNS Lookup tool to confirm your A record is resolving to the new IP from multiple geographic locations before you consider the migration done.

Step 8: Restore Your TTL to a Normal Value

After the migration is stable (typically 24 to 48 hours later), raise your TTL back to a sensible value. A TTL of 3600 (1 hour) is a reasonable balance between propagation speed and resolver load. Very large sites often use 300 permanently for flexibility, but for most sites 3600 to 14400 is fine.

Leaving TTL at 300 permanently means resolvers are querying your authoritative nameserver constantly, which can increase latency slightly and adds unnecessary load.

What About Email During the Migration

If your email MX records point to the same host you are migrating away from, you need to plan this separately. Email is not forgiving of brief DNS gaps, because messages sent during a gap may bounce or be delayed rather than quietly retry to the new server. Options:

  • Move email first: Migrate to Google Workspace, Microsoft 365, or another dedicated mail provider before the website migration. Update MX records independently. This removes email as a risk factor entirely.
  • Move email at the same time: If your new host also handles email, update MX records simultaneously with A records. Apply the same low-TTL prep beforehand.
  • Keep email on the old host temporarily: If the old host stays alive, you can migrate the website first and move email later in a separate window.

Common Mistakes That Cause Downtime Anyway

  • Skipping the TTL reduction step or not waiting out the old cached TTL before cutting over.
  • Cancelling old hosting immediately after updating DNS instead of waiting for traffic to drain.
  • Not testing SSL on the new host before cutover, resulting in certificate errors as soon as DNS flips.
  • Forgetting subdomains. Check for api., mail., ftp., cdn., and any other subdomains that may have separate A records pointing to the old server.
  • Hard-coded IPs in application configs, .htaccess, or wp-config.php that still point to the old server's database or storage after the move.
  • CDN or proxy cache (Cloudflare, Fastly, CloudFront) still serving the old origin IP. Update origin settings in the CDN dashboard independently of DNS.

Quick Reference Checklist

  1. Lower A record TTL to 300 seconds, wait 48 to 72 hours.
  2. Copy all files and database to the new server.
  3. Configure virtual host and SSL on the new server.
  4. Test via local hosts file override.
  5. Re-sync any delta content changes.
  6. Update A record DNS to new IP.
  7. Keep old server live for 30 to 60 minutes minimum.
  8. Verify SSL, forms, email, and subdomains on new server.
  9. Raise TTL back to 3600 after 24 to 48 hours.
  10. Cancel old hosting only after full verification.

Follow this sequence and you will have a migration that users never notice. The preparation work in steps 1 through 4 is what makes the actual cutover in step 6 a non-event rather than a crisis.