Move WordPress to New Host: Zero Downtime Website Migration Guide

Moving WordPress to a new host doesn’t need to cause downtime or risk data loss. This guide explains the safest method using /etc/hosts testing, DNS TTL reduction, and a complete rollback strategy. Follow these steps to migrate WordPress site to a new server without your visitors ever noticing.

Although we’ve done hundreds of WordPress migrations and accumulated years of experience, moving WordPress to a new host is always a critical operation.

The first rule: don’t start this on Friday night at 24:00. If you run into trouble, you’ll need time to fix it. If this is B2B site, so choose the time when traffic is low and allow yourself time to fix issues. Whatever suits your schedule best.

The reason is simple: issues can appear, and you may need hours to resolve them. Nobody wants to work until morning, and nobody wants to wake up to a broken WordPress site.

Why This Guide Exists: Real Migration Issues We’ve Encountered

In recent migrations, we’ve seen various issues that could have been avoided with proper preparation:

DNS Pointed Wrong Version of Domain: DNS records were pointing to the www version, but the site was configured for the non-www version. The moment we changed DNS, instant failure. Site wouldn’t load because of the configuration mismatch.

Database Export Failed Because of Emojis: Database had emojis saved in content. Standard export failed on import with character encoding errors. Solution required special exporting procedure with UTF-8mb4 parameters.

Third Party Service IP Whitelist: Third-party email API had IP whitelist restriction. Everything was configured correctly on new server, but emails wouldn’t send until we updated their IP whitelist.

These experiences taught us two critical techniques that prevent most migration problems: using /etc/hosts for testing before DNS changes and lowering DNS TTL in advance. Whether you’re migrating WordPress to a new host for better performance, cost savings, or switching providers, this guide explains both techniques to ensure zero downtime.

Before we dive into the process, let’s establish some fundamentals.

Understanding DNS and TTL: Why Migration Takes Time

What is DNS?

DNS (Domain Name System) is essentially the internet’s phone book. When someone types example.com into their browser, their computer doesn’t actually know where that website lives. It asks a DNS server “What’s the IP address for example.com?” and the DNS server responds “It’s at 123.456.789.012.” Then the browser connects to that IP address.

What is TTL and Why Does It Matter?

TTL (Time To Live) is how long DNS servers are allowed to remember (cache) this answer. If your TTL is set to 3600 seconds (1 hour), DNS servers worldwide will cache your domain’s IP address for 1 hour before checking again for updates.

Historically, TTL values were set to 2 days (172,800 seconds). This is why you’ll often hear “DNS propagation takes 24-48 hours.” That advice comes from this historical default. When you migrate WordPress site to a different IP address, it can take up to 2 days for every DNS server worldwide to get the new information, depending on your TTL setting.

The TTL Problem During Migration

Even if you reduce your TTL to 5 minutes, not every DNS resolver respects this value. Some may cache longer. This is why you cannot immediately shut down your old server after changing DNS records.

Step 1: Take Your Backup

Important: This guide applies to WordPress migrations where your server IP address is changing. If you’re moving from a staging domain to your main domain on the same server (for example, staging.example.com to example.com), you only need to adjust your web server configuration. No DNS changes are involved in that scenario.

I shouldn’t have to say this, but I will: TAKE A FULL BACKUP. Not “I think the host does automated backups” backup. An actual, downloaded-to-your-computer, “I can restore this myself” backup.

What to Backup from Your WordPress Site

• Complete WordPress database export
• Your entire root folder (usually public_html or www folder)
• SSL certificates (if not handled automatically by your new host)

Three Ways to Backup WordPress

Option 1: Hosting Provider Full Backup

Many hosting providers offer full backup packages that include your root folder, database, and SSL certificates. Check if your current host provides this. Download it and keep it safe. This is often the easiest option for a WordPress server migration.

Option 2: Backup or Migration Plugins

There are various backup and migration plugins available (we’re not going to test all of them here, but the concept is the same for most).

How plugin backup/migration typically works:

1. Install the backup plugin on your current WordPress site
2. Plugin takes a full database and root folder backup
3. Plugin saves this as a compressed file either locally on the server or to a cloud service like Amazon S3
4. On your new host, install fresh WordPress and the same plugin
5. Point the plugin to the backup file (either copied to new server or from cloud storage)
6. Plugin restores everything automatically

Option 3: Manual Backup (Full Control Method)

This gives you complete control and understanding of what’s happening when you migrate WordPress site to a new host:

1. Database Export:

Copied!mysqldump -u username -p --default-character-set=utf8mb4 database_name > backup.sql
mysqldump -u username -p --default-character-set=utf8mb4 database_name > backup.sql

The --default-character-set=utf8mb4 parameter is critical if your WordPress content includes emojis or special international characters. Without this, emojis won’t transfer correctly.

2. Download Root Folder: Use FTP/SFTP to download your entire WordPress root folder (public_html or www). This includes:

• wp-content (themes, plugins, uploads)
• wp-config.php
• wp-includes
• wp-admin
• .htaccess

Important: Always copy the full root folder. Some plugins create their own folders outside wp-content, and you don’t want to miss those. Copying everything ensures nothing is left behind.

3. SSL Certificates: If your new host doesn’t provide automatic SSL (like Let’s Encrypt), download your SSL certificates from your current host.

SSL Note: If you’re using Cloudflare, it will automatically create SSL certificates if you fail to configure them. Or you can generate a new SSL certificate via Let’s Encrypt in seconds. It’s not the end of the world if SSL isn’t perfect initially. However, since we’re aiming for zero downtime migration, it’s better to set up SSL correctly before changing DNS.

Manual Restoration on New Host

1. Create a new MySQL database on the new host
2. Import your database backup file
3. Copy all files from your root folder backup to the new server’s root folder
4. Update wp-config.php with new database credentials
5. Install/configure SSL on the new host

Don’t forget SSL configuration. Many issues after migration are simply because SSL wasn’t properly set up on the new server. While Cloudflare or Let’s Encrypt can fix this quickly, it’s better to have it working from the start for true zero downtime.

Step 2: Set Up WordPress on Your New Server

Move all your WordPress files, import your database, configure your 3rd party services. But DON’T change DNS yet.

WordPress-specific setup checklist:

1. Upload all WordPress files to the new server
2. Create a new MySQL/Maria database and user on the new host
3. Import your database backup to the new database
4. Update wp-config.php with new database credentials
5. Verify file permissions (typically 755 for directories, 644 for files)
6. If changing domain names, update URLs in the database:
   • Update siteurl and home in wp_options table
   • Or use wp-cli: wp search-replace 'oldsite.com' 'newsite.com'
7. Verify .htaccess permalinks are working

Step 3: Use /etc/hosts File for Testing

This is where the magic happens. On your computer (not the server), you’re going to manually tell your machine “when I ask for example.com, go to this NEW IP address instead of checking DNS.”

Locating the hosts File on Your OS

File locations:

• Mac/Linux: sudo nano /etc/hosts
• Windows: Edit C:\Windows\System32\drivers\etc\hosts (as Administrator)

If the file location is different on your OS or you need specific instructions, search for “how to change etc/hosts on [your OS name]”. The process is similar across operating systems, but extra steps may be needed depending on your setup.

Adding Your New Server IP Addresses

Add these lines:

Copied!123.456.789.012 example.com www.example.com
:: example.com www.example.com
123.456.789.012 example.com www.example.com
:: example.com www.example.com

Replace 123.456.789.012 with your NEW server’s IPv4 address. And:: is just nulling IPv6 address, I mean if your DNS server also publish IPv6 address and if you don’t add this option, your /etc/hosts rule will be bypassed because browser will fetch IPv6 and use it instead of your IPv4 in /etc/hosts file

The Critical IPv6 Requirement

Important IPv6 Note: If your site uses IPv6 (and many do – for example, Cloudflare provides IPv6 addresses by default), you MUST add the IPv6 line. If you only add the IPv4 address and your site supports IPv6, your browser will still connect via IPv6 to the old server, defeating the purpose of this test. Add both lines to be safe.

You can add just your primary domain if you only use one version (either example.com or www.example.com), but adding both covers all bases but not compulsory.

What just happened? Your computer now thinks your website has already moved. But to the rest of the world, nothing has changed. You’re living in the future while everyone else is stuck in the present.

Step 4: Test Everything Thoroughly

Open Chrome. Hit F12 to open Developer Tools. Go to the Network tab. Check “Disable cache.”

Critical WordPress Components to Test

Now test EVERYTHING on your WordPress site:

• Homepage loads correctly
• Admin dashboard (/wp-admin) login works
• Contact forms (Contact Form 7, Gravity Forms, etc.)
• WooCommerce checkout if using e-commerce
• User logins and registrations
• Image uploads through WordPress media library
• Plugin functionality (especially critical plugins)
• Theme customizations display properly
• Permalink structure works correctly
• Search functionality
• Comments (if enabled)
• Any custom post types
• Email sending (password resets, notifications)
• Check 3rd party integrations if any

Testing with Browser Cache Disabled

Use Incognito mode for final checks. Why? Because even with cache disabled, your browser is sneaky. Incognito mode is paranoid mode, and during WordPress migrations, paranoia is your friend.

This /etc/hosts testing method is what makes zero downtime migration possible. You’re verifying everything works on the new server before any real visitors see it.

Important: DNS Server Change vs Webserver IP Change for WordPress

Before proceeding, understand what type of WordPress migration you’re doing:

Scenario 1: Changing Webserver IP (keeping same DNS provider) This article covers this scenario. You’re changing where your website is hosted but keeping your DNS records at the same DNS provider (like Cloudflare, AWS Route53, or your registrar).

Scenario 2: Changing Both DNS Server AND Webserver If you’re also changing DNS providers, do this in two stages:

1. First, change the webserver IP on your OLD DNS provider
2. Test everything thoroughly with /etc/hosts method
3. Once everything works, THEN change your DNS nameservers to the new provider with all the same records

Why separate them? If you change both simultaneously and something breaks, troubleshooting becomes a nightmare. You won’t know if the issue is DNS propagation, DNS configuration, or server configuration.

Rollback Strategy: Preparing for When Things Go Wrong

Understanding DNS TTL and DNS Caching Behavior

When you move WordPress to new server, understanding DNS caching is critical for a successful migration. Here’s how DNS caching actually works during a WordPress hosting change:

Copied!Stage 1: Before TTL Reduction
================================
Your DNS: TTL = 2 days (172,800 sec)
DNS Resolver A: Cached your IP, expires in 48 hours
DNS Resolver B: Cached your IP, expires in 48 hours  

Stage 2: You Lower TTL to 5 Minutes and 12 hours passed
====================================
Your DNS: TTL = 5 minutes (300 sec)
DNS Resolver A: Still has old cache, won't check for 36 hours
DNS Resolver B: Still has old cache, won't check for 36 hours 

(They only learn about new TTL when their current cache expires)

Stage 3: After 48hours you changed TTL
================================================
Your DNS: TTL = 5 minutes
DNS Resolver A: Cache expired, checks again, sees TTL=5min
DNS Resolver B: Cache expired, checks again, sees TTL=5min

Stage 4: You Change IP Address
================================
Your DNS: New IP, TTL = 5 minutes
DNS Resolver A: Will update in 5 minutes ✓
DNS Resolver B: Will update in 5 minutes ✓

Please note that, this is perfect scenario. Some DNS resolvers may not obey the TTL you set in your DNS server, so they may have different values according to their local system admin's decisions.
Stage 1: Before TTL Reduction
================================
Your DNS: TTL = 2 days (172,800 sec)
DNS Resolver A: Cached your IP, expires in 48 hours
DNS Resolver B: Cached your IP, expires in 48 hours  

Stage 2: You Lower TTL to 5 Minutes and 12 hours passed
====================================
Your DNS: TTL = 5 minutes (300 sec)
DNS Resolver A: Still has old cache, won't check for 36 hours
DNS Resolver B: Still has old cache, won't check for 36 hours 

(They only learn about new TTL when their current cache expires)

Stage 3: After 48hours you changed TTL
================================================
Your DNS: TTL = 5 minutes
DNS Resolver A: Cache expired, checks again, sees TTL=5min
DNS Resolver B: Cache expired, checks again, sees TTL=5min

Stage 4: You Change IP Address
================================
Your DNS: New IP, TTL = 5 minutes
DNS Resolver A: Will update in 5 minutes ✓
DNS Resolver B: Will update in 5 minutes ✓

Please note that, this is perfect scenario. Some DNS resolvers may not obey the TTL you set in your DNS server, so they may have different values according to their local system admin's decisions. 

The Two-Step TTL Strategy for WordPress Migration

Step 1: Lower Your TTL (2-3 Days Before Migration)

If you’re not using a proxy service like Cloudflare’s proxy mode, reduce your DNS TTL to 5 minutes.

Critical timing: Do this 2-3 days BEFORE migration. Your current TTL must expire first before the new TTL takes effect globally. If your current TTL is 2 days, the reduction to 5 minutes won’t be respected until 2 days pass.

Step 2: Quick Rollback If Needed

With reduced TTL, if something breaks during your WordPress move server operation:

• Change DNS back to old IP immediately
• Most DNS resolvers update in 5 minutes (those that respect TTL)
• Some may take longer (those that don’t respect TTL)
• Keep both servers running during this window

If you’re using Cloudflare’s proxy mode: You can skip TTL reduction. The proxy lets you change the origin IP instantly without DNS propagation delays. This is your instant rollback button.

The DNS Change: Doing It Right

Important: Check Service Dependencies First

Before you touch DNS, audit EVERYTHING that connects to your current provider:

WordPress-specific services to check:

• Email services (SMTP plugins, SendGrid, Mailgun, etc.)
• CDN configurations (Cloudflare, StackPath, etc.)
• Payment gateways (Stripe, PayPal webhooks with IP restrictions)
• Third-party APIs with IP whitelisting
• Backup services (UpdraftPlus, BackupBuddy cloud storage)
• Security plugins (Wordfence…)
• SSL certificates
• Cron jobs for scheduled posts or backups
• External media storage (Amazon S3, DigitalOcean Spaces)

Check thoroughly. Service dependencies are one of the most common reasons WordPress migrations fail even when the site itself is working perfectly.

The Actual Migration Day

Changing DNS Records

1. Change your DNS records to point to the new IP
2. DO NOT shut down your old server
3. Monitor both servers

During the TTL window (remember, you reduced it to 5 minutes), some users will hit the old server, some will hit the new one. Both need to be running. This is the key to achieving zero downtime during WordPress server migration.

How Long to Keep Both Servers Running

• Low traffic site: You can probably shut down the old server after 24 hours
• High traffic site: Wait the full original TTL period (before you reduced it)
• Paranoid (recommended): Wait 72 hours and check access logs

The IP Whitelist Gotcha

Always ask: “Do any of your services use IP whitelisting?”

Examples:

• Payment gateways
• Email APIs
• Third-party integrations
• Corporate firewalls
• Analytics tools

If yes, you need to whitelist the NEW server’s IP BEFORE migrating. Some services take 24 hours to update their whitelists. Plan accordingly.

Your WordPress Migration Checklist

3 Days Before:

• [ ] If not using Cloudflare proxy, reduce DNS TTL to 5 minutes
• [ ] Audit all WordPress plugin and service dependencies
• [ ] Update IP whitelists on 3rd party or network firewalls
• [ ] Take full WordPress backup (database with UTF-8mb4, all files, wp-config.php)

Migration Day:

• [ ] Set up /etc/hosts file
• [ ] Test WordPress admin dashboard login
• [ ] Test all critical plugins
• [ ] Test everything with cache disabled
• [ ] Test again in Incognito mode
• [ ] Verify email still works (contact forms, password resets)
• [ ] Check SSL certificates
• [ ] Verify payment processing (WooCommerce if applicable)
• [ ] Test permalink structure
• [ ] Change DNS
• [ ] Keep both servers running
• [ ] Monitor error logs on both servers

After Migration:

• [ ] Monitor both servers for 24-72 hours
• [ ] Check that WordPress emails are sending
• [ ] Verify forms are submitting
• [ ] Test WooCommerce checkout process multiple times (if applicable)
• [ ] Verify all plugins still functioning
• [ ] Check WordPress cron jobs are running
• [ ] Only then shut down old server
• [ ] Restore normal TTL after 1 week (if you lowered it)

You may not need 48 hours for low traffic sites’ DNS changes

Low traffic sites? DNS migration is almost immediate because most visitors are new. Their DNS resolvers haven’t cached your old IP. Sometimes the only people who have your website’s IP in their local DNS cache is you and your technical person, nobody else.

High traffic sites? You’ve got users whose DNS servers cached your IP 5 minutes ago, 1 hour ago, 12 hours ago, 2 days ago. They’re all seeing different versions of reality. This is why you keep both servers running and why you test EVERYTHING before changing DNS.

Didn’t See That Coming?

Moving WordPress to a new host shouldn’t be stressful. WordPress migrations are only stressful when you skip steps or assume “it’ll probably be fine.”

Don’t assume. Prepare.

Use /etc/hosts for testing. Reduce your TTL early if not using a proxy. Test in Incognito mode. Check your WordPress plugin dependencies and third-party service integrations. Keep both servers running during the transition. And take a proper backup with UTF-8mb4 encoding if your database has emojis.

Follow these steps, and your WordPress migration will be zero down time.

It reminds me of the old Windows Othello/Reversi game. You couldn’t type freely in chat; you could only select predefined messages. And one of the most iconic was:

“Didn’t see that coming?”

Use this guide, and during your next migration, you won’t have to say it.