Your site is live right now. People are reading it, buying, subscribing — and you have to move the whole thing to a new server without anyone noticing a flicker. That's the real challenge when you migrate WordPress to a new host without downtime. The file copy is the easy part; the handoff is where things break. Do it wrong and visitors hit a half-loaded page or a database error for hours. Do it right and the switch is completely invisible. This guide walks through the exact sequence, the one DNS setting that prevents the gap, and the quiet mistakes that cause most so-called "downtime."
Quick Answer: To migrate WordPress to a new host without downtime, lower your domain's DNS TTL to 300 seconds a day before, copy your files and database to the new server, test the new site through a temporary hosts-file entry, then repoint your domain. Because the old site stays online until DNS fully propagates, visitors never see an outage. Plan for a 24-hour overlap.
What "Zero Downtime" Actually Means
Here's the thing nobody tells you: your files moving isn't what causes downtime. A good host plans around the real risk — Hostaccent, for one, keeps your old site reachable on a temporary address while the switch settles, so there's never a dead moment. The gap, when it happens, lands during the cutover — the moment your domain stops pointing at the old server and starts pointing at the new one.
If you delete the old site the second you've copied it across, you've created a window. Anyone visiting during that window — while DNS is still propagating — lands on nothing. That can last anywhere from a few minutes to 48 hours depending on your settings.
The trick is overlap. You keep both copies live at the same time. The old host serves visitors right up until the last person's DNS cache updates to the new server. Nobody is ever pointed at an empty box.
Propagation isn't a single global flip, either — it's thousands of resolvers worldwide each updating on their own schedule. A visitor in London might see the new server within two minutes while someone on a slow corporate network still hits the old one an hour later. As long as both servers serve the same site during that spread, every one of them gets a working page. That overlap is the entire reason a careful migration looks like nothing happened at all.
Two things control how smooth that overlap is. The first is TTL (time to live) — how long resolvers around the world are allowed to cache your DNS records before re-checking. The second is testing the new site before you flip anything, so the version visitors land on is already verified. Get a preview URL from your new host and confirm everything works there first. If you want the full mechanics of how name resolution and caching work, Cloudflare's DNS learning hub is a clean reference.
Lower the TTL first, and the rest of the move gets dramatically more forgiving.
What to Prepare Before You Move a Single File
Rushing the prep is the number-one reason a "quick" migration turns into a two-day mess. Get these sorted first.
- A full, current backup. Both files (
wp-content, themes, plugins, uploads) and the database. Never trust a single copy. - The new hosting account, ready and empty. PHP version, MySQL/MariaDB access, and enough disk — a typical small WordPress site needs 1–5GB, but a media-heavy one can run past 50GB.
- A PHP version match (or newer). If your old host runs PHP 8.1 and the new one defaults to 8.3, test for plugin compatibility before, not after.
- Login credentials for everything — old host, new host, domain registrar, and your WordPress admin.
When customers move to Hostaccent, the prep step our team chases most often is that missing registrar login. People remember their hosting password but forget who they bought the domain from three years ago — and you can't repoint DNS without it. Track it down before migration day, not during.
Pro Tip: Check your old PHP version under Tools → Site Health → Info in wp-admin before you start. Migrating from PHP 7.4 to 8.x is the single most common source of "white screen after migration" — it's not the move that broke the site, it's an old plugin that never supported the newer runtime. Match the version first, then upgrade once you're stable.
If you're still deciding what kind of plan to land on, our complete shared hosting starter guide breaks down what a beginner actually needs versus what's upsell. And if you're weighing a managed plan, the managed WordPress vs shared hosting comparison is worth a read before you commit.
How to Migrate WordPress to a New Host Without Downtime, Step by Step
This is the core sequence. Follow it in order — the order is what keeps you online.
- Lower your DNS TTL to 300 seconds. Do this in your registrar or DNS provider at least a few hours (ideally a full day) ahead. This shrinks how long old records linger when you finally switch. The standards behind TTL caching are defined in the IETF's DNS specification if you want the source.
- Back up files and database from the old host. Export the database via phpMyAdmin or WP-CLI (
wp db export), and grab the full file tree over SFTP. - Upload everything to the new server. Place files in the web root, import the database, and update
wp-config.phpwith the new database name, user, and password. - Don't change DNS yet. This is where most people slip. The new site exists but no one should be routed there until you've tested it.
- Test through your local hosts file. Edit your computer's
hostsfile to map your domain to the new server's IP. Now you see the new site at your real domain while the rest of the world still sees the old one. Click around. Test checkout. Log into wp-admin. - Fix anything broken in private. Broken images, mixed-content warnings, a plugin that needs reactivating — handle it now, while real visitors are still safely on the old host.
- Point DNS to the new server. Update the A record (and AAAA if you use IPv6). Because your TTL is 300 seconds, most resolvers pick up the change within minutes.
- Keep the old host live for 24–48 hours. Let propagation finish completely before you cancel anything. Some networks cache aggressively regardless of TTL.
On the Nginx → Apache and NVMe SSD stack we run at Hostaccent, the import step is usually the slowest part for large databases — and it's also where things silently go wrong. If a .sql import dies halfway, you get partial tables and confusing errors; our walkthrough on a failed database import during migration covers exactly why that happens and how to resume cleanly.
The DNS Cutover: Where the "Downtime" Actually Hides
You've tested. The new site is verified. Now you flip DNS — and this is the moment people panic about. They shouldn't, if the prep was done.
With a 300-second TTL, the global switchover typically settles in 5–30 minutes for most visitors, though stragglers on aggressive ISP caches can take up to 24 hours. During that whole window, both servers are answering. Old-cache visitors get the old (identical) site; new-cache visitors get the new one. There is no blank page in between.
Two cutover gotchas worth flagging:
- SSL must be ready on the new host before you switch. If the certificate isn't issued yet, the first visitors after the flip get a scary browser warning. Most modern hosts auto-issue via Let's Encrypt the moment DNS points correctly, but confirm it rather than assuming.
- Search-and-replace the database for hardcoded URLs if your domain or protocol changed. WP-CLI's
wp search-replacehandles serialized data safely; a raw SQL find-and-replace can corrupt it.
In the migration tickets our team handles, the single most common "the site went down" complaint isn't downtime at all — it's a browser still loading cached assets from the old IP for an hour while the owner refreshes frantically. Clear your local cache before you judge whether the switch worked. Better yet, test from a different network or your phone on mobile data; if it loads cleanly there, your migration is fine and your own browser is simply being stubborn.
Migration Mistakes We See Every Week
After moving thousands of customer sites, the same handful of errors come up over and over. Knowing them ahead of time is most of the battle.
Deleting the old site too early. This is the big one. The old host is your safety net. Keep it for at least 48 hours.
Forgetting the wp-config update. New server, new database credentials. Skip this and you'll meet the "Error establishing a database connection" screen immediately.
Hitting a file-count ceiling. A WordPress install can easily contain 100,000+ small files between plugins, cached thumbnails, and uploads. Some accounts cap the number of files (inodes), and a migration can quietly fail when you cross it. If your transfer stalls or throws a quota error, our guide on the cPanel inode limit explains what to clear.
Permission and ownership errors after upload. Files copied as the wrong user trigger a 500 Internal Server Error in WordPress — frustrating because the files are all there, just unreadable to the web server.
Insider Insight: Before you migrate a slow site, fix the slowness first. Moving a bloated, badly-cached install to faster hardware just gives you a faster slow site. On our stack, simply enabling object caching and trimming autoloaded options has taken customer TTFB from roughly 800ms down to around 210ms — without touching the host. If your current site drags, run through our 30-minute WordPress speed diagnosis before migration day so you're moving a clean site, not a problem.
Ignoring email. If your old host also handled your email (MX records), repointing your domain can break mail delivery. Decide where email lives before you touch DNS.
Let Your Host Do the Heavy Lifting
If reading those eight steps made you want to close the tab — that's a completely reasonable reaction, and it's exactly what free managed migration is for. A good host moves the files, imports the database, sets up SSL, and does the hosts-file testing for you, so you only approve the final DNS switch.
That's the path most of our customers take. Hostaccent's Linux Shared Hosting starts at $1.99/yr for the Economy plan, runs on the Cloudflare → Nginx → Apache + NVMe stack described above, and includes hands-on migration help from UK-based support — so a human does the cutover with you rather than leaving you to time DNS alone. Honest limitation: shared hosting is the right home for blogs, brochure sites, and most small stores, but if you're running a high-traffic WooCommerce shop with constant concurrent checkouts, you'll eventually want a VPS instead. For most sites leaving a sluggish host, though, it's the simplest way to migrate WordPress to a new host without downtime and actually come out faster on the other side.
Frequently Asked Questions
Can I migrate WordPress to a new host without downtime if I'm a total beginner?
Yes. The "no downtime" part comes entirely from keeping both servers live and testing through your hosts file before switching DNS — neither requires coding. That said, if the command-line steps feel risky, a host with free managed migration removes the technical parts entirely while you keep full control of the final go-live.
How long does a WordPress migration take?
The file and database copy is usually 15–60 minutes for a small-to-medium site. The longer wait is DNS propagation after cutover, which is typically 5–30 minutes with a low TTL but can stretch to 24–48 hours for some visitors. Your site stays online the entire time, so the wait costs you nothing.
Will I lose SEO rankings when I move hosts?
No — moving hosts alone doesn't affect rankings, as long as URLs stay identical and the site doesn't go down. Google cares about your domain and content, not which server answers. Faster hosting can actually help rankings over time, since Core Web Vitals reward better load times. The one thing that can hurt you is a sloppy cutover that leaves the site unreachable for hours — which is exactly what the overlap method in this guide prevents. Keep your URLs and permalink structure untouched and you'll move without a ripple in search.
Do I need to lower my DNS TTL before migrating?
It's strongly recommended. Lowering TTL to 300 seconds a day ahead means resolvers re-check your records quickly after the switch, shrinking the propagation tail from hours to minutes. Skip it and visitors may keep hitting the old server long after you've moved on.
What's the difference between transferring files and transferring a domain?
Transferring your WordPress site means copying files and the database to a new server. Transferring a domain means moving its registration to a new registrar. They're separate — you can move hosts without ever touching your domain registration, just by updating DNS records to point at the new server.
Should I use a migration plugin or do it manually?
Plugins like Duplicator or All-in-One WP Migration work well for small sites and are beginner-friendly. Manual migration (SFTP plus a database export) gives more control and handles large sites better, since plugins can time out on big databases. For anything past a few GB, manual or host-assisted is the safer route. Hostaccent customers usually skip the choice entirely and hand the whole job to support, which removes both the plugin timeout risk and the manual-error risk.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.