Moving a WordPress Site to a New Host Without Downtime

Everyone plans a host migration around downtime. The expensive risk is the opposite: two working copies of the site answering at once. Change the nameservers at four in the afternoon, and for the next day or two some visitors reach the new host while others are still sent to the old one by an ISP resolver holding a cached record. Nothing looks broken. Both copies load, both show the right pages, both accept enquiries. Roughly half of those enquiries land on a server nobody is watching any more, and they are simply gone. The site never went down for a second and the business still lost two days of leads. That is the thing nobody tells you about migrations: downtime is the easy problem, and split traffic is the one that actually costs you something. Here is a sequence built around closing that window, and where each step earns its place.

what actually goes wrong

Copying a WordPress site is not hard. It is files plus a database, and both move with ordinary tools. The trouble lives in the edges: URLs baked into the database, a PHP version mismatch, email that quietly stops because it was tied to the old hosting account, and the propagation window where two live copies exist at once.

So plan for the window rather than pretending it will not happen. During propagation some visitors reach the new server and some reach the old one, and anything written on the old copy in that period is effectively lost. On a blog that is harmless. On a site taking orders or enquiries it is not, which is why the order of operations below puts DNS last.

the inventory you write before touching anything

Twenty minutes with a notepad saves a bad evening. Write down the current PHP and MySQL versions, the WordPress version, the theme and its child theme, every active plugin, the total size of wp-content/uploads, where DNS is managed, who the registrar is, where email lives, and which cron jobs or external services hit the site.

That last one catches people. A payment webhook, an analytics integration or a form service may be pointed at your domain with an IP allowlist on the other side. If you do not know it exists, you find out when it breaks. If your DNS and registrar are separate, my domain name guide explains which control panel actually holds the records you are about to edit.

lower the TTL a day before, not on the day

Every DNS record carries a time-to-live that tells resolvers how long they may cache it. If yours is set to a day, then changing the record at four in the afternoon means some resolvers keep serving the old answer until four the next afternoon. You cannot shorten that retroactively.

So a day in advance, drop the TTL on the A record to five minutes and let the old long TTL expire. On switch day, resolvers will pick up your change within minutes instead of hours. Put it back to something sensible a week later.

# check the current TTL on your A record
dig +noall +answer example.com A

# after the switch, ask a public resolver what it sees
dig @1.1.1.1 +short example.com A

Nameserver changes are slower and blunter than record changes. If you only need the site to move, change the A record and leave the nameservers alone.

build the new site, then preview it privately

Get the copy running on the new host while the old one still serves the public. Create the database, upload the files, including hidden ones such as .htaccess that quietly hold your redirects, import the dump, set the PHP version to match or exceed the old one, and fix permissions. Then point your own machine at the new server using its IP, so you see the new site at the real domain while everyone else sees the old one.

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as administrator)
# macOS and Linux: /etc/hosts
203.0.113.45   example.com www.example.com

Now click through the site properly. Homepage, a post, a category page, the contact form, the search box, the admin area, and one page with an image gallery. Log in and open a few plugin settings screens, because a plugin that cannot reach a file path or an old database table will complain there first. Remove the hosts line when you are done, or you will spend an hour confused later.

the URLs hiding in your database

WordPress stores absolute URLs in posts, options, widgets and serialised plugin settings. If the domain is not changing, you have very little to fix. If you are moving from a staging domain or switching to HTTPS, a plain find-and-replace in a SQL file will corrupt serialised data, and the site half-breaks in ways that are annoying to trace.

Use a tool that understands serialisation. WP-CLI does, and the dry run tells you exactly what it would touch before it touches it.

# back up first: search-replace rewrites the database in place, with no undo
wp db export before-search-replace.sql

# see what would change, without changing anything
wp search-replace 'http://old.example.com' 'https://example.com' --dry-run

# then do it, including all tables and serialised values
wp search-replace 'http://old.example.com' 'https://example.com' --all-tables

plugin route or manual route

Both are legitimate. A migration plugin is faster and forgiving; doing it by hand teaches you where everything lives and does not choke on a large uploads folder over thin home upload bandwidth.

Step	Migration plugin	By hand
Files	Bundled into an archive	SFTP, rsync, or a server-side tar
Database	Exported and rewritten for you	mysqldump, import, WP-CLI search-replace
Large uploads folder	Often where it fails	Handles it fine, resumable
Learning value	Low	High, and you can fix it at 2am
Good for	Small sites, tight deadlines	Anything you will maintain for years

email does not travel with the website

This is the step that ruins migrations. If your mail sits on the same hosting account as the site, moving the site can orphan the mailboxes, and if the MX records follow the nameservers by accident, incoming mail bounces or lands somewhere nobody checks. Messages that bounce during that window are simply gone.

Treat mail as a separate project. Note the MX records before you start and carry them across deliberately. My own preference is to keep mail entirely away from web hosting, and to send transactional mail through an authenticated relay, which also fixes contact forms landing in spam. That whole problem is its own article: why your contact form email never arrives.

switch day, in order

1. Pick a quiet hour. For an Indian audience that is usually early morning, not evening.
2. Put the old site into a read-only state if it takes orders or comments. A brief maintenance notice beats lost data.
3. Do a final sync of the database and any files uploaded since your copy.
4. Change the A record. Check with a public resolver rather than trusting your own browser.
5. Issue the TLS certificate on the new host once DNS resolves, then confirm HTTPS and the redirect from the non-canonical host.
6. Watch the new server’s access log for a while, and the old one for traffic that has not moved yet.

Certificate order matters. Most automated issuance proves control over the domain by answering an HTTP request at it, so it usually cannot complete until DNS points at the new server. You can avoid that gap: copy the existing certificate and key to the new server before the switch, or issue a new one with a DNS challenge, which proves control through a TXT record and does not need the A record to point at the new host yet. If you do neither, switch at a quiet hour, because some visitors will see a browser warning for a few minutes.

verify, then leave the old host alone for a fortnight

Once traffic has moved, walk the checklist again on the live site: forms send, images load, permalinks resolve, search works, the admin saves, scheduled posts publish, and any webhook still arrives. Then go and confirm indexing is healthy in Search Console and that nothing accidentally shipped with a noindex header, which I cover in my technical SEO checklist. A migration is also a decent moment to fix the speed problems you inherited; the caching and image work in making WordPress fast on Indian broadband is easier to do on a fresh server.

Keep the old hosting paid up for two weeks. It is your rollback plan and it costs almost nothing. Once the old server’s access log shows no visitors for a day or two, put the old copy into maintenance mode so nobody uses it by accident, but do not delete anything until you have a full working backup of the new site and a fortnight of quiet.

FAQ

How long does propagation really take?

Mostly as long as your old TTL, plus however stubborn the resolver in the middle is. With a TTL lowered in advance, most visitors follow within minutes and the stragglers clear within a few hours. Some resolvers enforce their own minimum cache time and hold on longer, which is exactly why you keep the old server answering rather than switching it off.

Will my search rankings drop?

If the URLs do not change, a host move is close to invisible to search engines. Google’s own guidance treats a server move with no URL changes as a low-risk event. Rankings wobble when URLs change, when redirects are missing, or when the new site accidentally blocks crawlers. Check robots.txt on the new host on day one.

Can I move a WooCommerce store the same way?

Same sequence, stricter about the window. Orders placed on the old copy during propagation will not exist on the new one, so put the store in maintenance mode for the final sync and accept a few minutes of closed shop. Re-test payment webhooks afterwards, because gateways sometimes need the new server allowlisted.

Should I let the new host migrate it for me?

Yes, if they offer it free, which many Indian hosts do to win the sale. Ask two questions first: do they handle the DNS timing, and do they give you a preview before the switch. Take your own backup regardless. It is your data and your afternoon if something goes sideways.

A migration is really a scheduling exercise wearing a technical costume: prepare the copy quietly, shorten your TTL, and switch when nobody is looking. Do it in that order and the only person who notices is you.

Update history: added a database backup before search-replace, switched the command examples to example.com, and added two ways to avoid the certificate gap on switch day.

Sources

• WordPress Advanced Administration Handbook: Migrating WordPress — the project’s own steps for moving files, databases and URLs.
• WP-CLI: search-replace — flags, dry runs and how serialised data is handled.
• Google Search: site moves without URL changes — what search engines expect during a host change.