Migrate WordPress to a New Host Without Downtime

To migrate WordPress to a new host without downtime, treat it as an order-of-operations problem, not a speed problem. Keep the old site live the entire time you build the new copy, test the new copy privately through a hosts-file preview, lower your DNS TTL to 300 seconds at least 24 hours ahead, then switch DNS. The old server stays online until traffic fully moves. Visitors never see a gap. And the most important decision isn’t which migration method you use: it’s your rollback plan, agreed before you touch anything.

The rollback plan comes first

Every migration guide buries this at the end. It belongs at the top, because it’s the decision that saves you when something breaks: with a short DNS TTL, rolling back is a single DNS change back to the old server, which is still live, untouched, with the old site intact.

Before you start, write down three things:

1. The trigger: what would make you roll back? Typical answers: checkout or payment failures, a critical plugin error, persistent 500 errors, a broken admin area on the new server.
2. The decider: who makes the call. If you’re solo, that’s you; write it down anyway so you don’t argue with yourself at 2 AM.
3. The copy-back rule: if the new server collected any writes before the rollback (comments, orders, form entries), those must be copied back to the old database afterward. Write down the exact switch time so you know the window.

With those three written, the rest is a checklist. Without them, every anomaly mid-migration becomes a judgment call.

Pre-migration checklist

Do these before moving anything. On the old site, while it’s still perfectly healthy:

1. Full backup, stored off both servers. Files and database, in a location that is neither the old host nor the new host (your computer or cloud storage). This backup is your rollback if anything goes wrong.
2. Record your environment. Note the PHP version (in wp-admin under Tools → Site Health → Info → Server), the database version, and any custom settings in .htaccess or php.ini. The new host should match or exceed these versions. A newer PHP breaking an old plugin is one of the most common migration failures.
3. Note your database credentials. Open wp-config.php and write down DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Plus the table prefix (usually wp_, but not always). You’ll need these on the new server.
4. Update everything on the old site. Run pending WordPress core, theme, and plugin updates before migrating. Moving an outdated site moves its problems with it.
5. List what’s outside WordPress. DNS records (including MX for email), email accounts on the same server, SSL certificates, cron jobs, server-level settings. A checklist written up front prevents most surprises.

Lower your DNS TTL ahead of time (timing depends on your current TTL)

One setting, a day of patience. That’s what makes the switch invisible.

TTL (time to live) tells DNS resolvers how long to cache your DNS answer before asking again. If your A record’s TTL is 86400 seconds (24 hours), some visitors keep reaching the old server for a full day after you switch. That’s where most “downtime” complaints actually come from.

The fix: lower the TTL to 300 seconds at least one full old-TTL period before the move. If the old TTL was 24 hours, make the change a full 24 hours ahead. Lowering TTL one hour before a move, when the old TTL was 24 hours, does nothing. Resolvers are still caching the old value. After the migration settles, you can raise the TTL back to a normal value.

Nameserver changes take longer. If you plan to change nameservers rather than just the A record, the registry-level change is slower. Lower the TTL anyway, but budget for a longer overlap window.

Method 1: The plugin method (beginners and small-to-medium sites)

Migration plugins package your site for you. Three come up in most guides: Duplicator, All-in-One WP Migration, and Migrate Guru. Mentioned as documented options. GoScalify has not hands-on tested them for this guide.

The Duplicator flow (documented across multiple guides; steps may vary as the plugin UI changes):

1. Install and activate Duplicator on the current site.
2. Go to Duplicator → Packages and create a new package.
3. Download the two files: installer.php and archive.zip.
4. Upload both to the root directory (public_html or equivalent) of the new server. Via FTP/SFTP or the new host’s file manager.
5. Visit yourdomain.com/installer.php in your browser and follow the installer’s prompts, entering the new server’s database details.
6. The installer imports the database and sets up the files. Update URLs if needed.
7. Delete the installer files after a successful migration.

All-in-One WP Migration is the simpler alternative: it exports the entire site into a single file you import on the new server.

The one catch: free plugin versions often cap archive size, and very large media libraries can time out mid-move. Check the plugin’s current limits before relying on it for a big site.

Plugin UI drift caveat: plugin menus and labels change with updates. If a menu name above doesn’t match what you see, search the plugin’s documentation for the current version. The function is the same even when the label moves.

Method 2: The manual method (more control, better for large sites)

The manual method does what every plugin does, out of sight, but you control each step. It suits people comfortable with a file manager, phpMyAdmin, and DNS, and it works for large sites that plugins struggle with.

The exact clicks differ by control panel — see differences between cPanel and hPanel for where each of these tools lives.

1. Archive the files. Compress the WordPress directory on the old host into a single archive. Via the host’s file manager or SSH. (Prefer SFTP over plain FTP wherever the host offers it; plain FTP sends your password in clear text.)
2. Export the database. In phpMyAdmin on the old host: select the site’s database → Export → keep the Quick method and SQL format → Go. For large databases, use the Custom method with gzip compression. The file is often a tenth of the size, and phpMyAdmin imports .sql.gz directly. With SSH access, mysqldump (or WP-CLI’s wp db export) does the same job.
3. Create the new database. On the new host, create a new database, a database user, and grant the user full privileges on it.
4. Upload and extract. Upload the archive to the new site’s document root and extract it.
5. Import the database. In phpMyAdmin on the new host: select the new database → Import → choose the .sql file → Go.
6. Update wp-config.php. Edit the file on the new server with the new database name, user, password, and host:
   • DB_NAME. The new database name
   • DB_USER. The new database user
   • DB_PASSWORD. The new password
   • DB_HOST. Often localhost, but use what your new host specifies

If the domain stays the same, you don’t need to change URLs in the database. If the domain or protocol changes, use a tool that understands serialized data. WP-CLI’s search-replace command handles this safely. A plain text find-and-replace can break widget and plugin settings because WordPress stores data in serialized PHP format.

Panel drift caveat: menu names (“File Manager”, database sections, backup tools) vary between hosts and between cPanel and custom panels like hPanel. Follow the function, archive files, export database, create database, not the exact label.

Which method should you pick?

Your situation	Pick	Why
Small-to-medium site, you’d rather not touch databases	Plugin method	Packaging + installer does the sequence for you; the documented beginner path
Large site, huge media library	Manual method	Plugins can hit free-tier archive limits or time out; the manual method moves any size
Store or membership site (orders, sign-ups)	Manual method	You need precise control over the final database sync and the content-freeze timing
You’re comfortable with FTP/phpMyAdmin	Manual method	More control, no plugin dependency on the old site
You just want it done and the site is modest	Plugin method	Fewest moving parts

The private test: hosts-file preview

This step is what makes the whole thing zero-downtime. You view the new server under your real domain while everyone else still sees the old one.

Your computer’s hosts file lets you point a domain at a specific IP address, bypassing public DNS. Add a line with the new server’s IP address followed by your domain. Then browse the site as normal and check carefully:

• The homepage, a few posts, and a few pages
• Images and media in older posts
• Contact forms and any email the site sends
• The admin dashboard, plugin settings, and permalinks
• Checkout and payment flows if you run a store

Remove the hosts-file line when testing is done. Otherwise you’ll forget and confuse yourself later.

The cutover: order of operations

The whole trick is order, not speed: everything is proven before DNS moves, and the old host stays live for days after.

Pick a low-traffic window (check your analytics, for most small sites that’s late night in your primary market’s timezone).

1. Freeze content. Announce it internally: no new posts, no plugin changes, no settings edits on the old site. For a store or membership site, pause checkout or sign-ups during the final sync. Visitors can still browse; nothing is lost, but no new writes land on the wrong database.
2. Run the final sync. Take a fresh database export (and files, if uploads changed) and import it on the new server, so the new copy matches the old one to the minute.
3. Switch DNS. Update the A record at your current DNS provider to point at the new IP, or change nameservers to the new host. Changing only the A record is faster and leaves email records untouched. Changing nameservers moves the whole DNS zone and is cleaner long-term, but you must recreate every record first: MX, TXT, SPF, DKIM, and any subdomains.
4. Monitor. Watch the new server’s error logs and confirm traffic is arriving; run a free uptime monitor during the propagation window so you catch issues within minutes.
5. Reopen. Confirm forms, checkout, and sign-ups work end-to-end on the new server, then reopen writes.

While propagation runs, verify your A record is resolving to the new IP with our DNS record checker.

Email, SSL, and cron after the move

Three things commonly break in the first hours after a migration.

• Email. If mailboxes lived on the old server, move them separately, or keep MX records pointing at the old host until you migrate mail. Do not let the website move drag email along with it by accident. When you recreate records on a nameserver switch, MX, SPF, and DKIM must move too. Email breaks silently when they’re forgotten.
• SSL. Certificates are tied to the server and must be issued again after the move. Free certificates typically validate by checking that the domain resolves to the server. That check fails until DNS points at the new host, so request the certificate right after the switch (or use DNS validation if your host supports it).
• Cron. WordPress runs scheduled tasks through WP-Cron, which triggers on page visits. Some sites replace this with a real server cron job. If the old server had one, recreate it on the new host.

Post-migration verification checklist

Run this before you consider the move done. If pages look stale after the move, verify WordPress caching is set up correctly on the new host. A site that “loads” can still have broken forms, images, or payment webhooks.

• Homepage, posts, pages, and older-post media all load on the live domain (not just via the hosts file)
• Admin dashboard logs in; plugin settings intact
• Permalinks resolve (no 404s on posts/pages)
• Contact forms submit and send email
• Checkout/payment flows complete end-to-end (test mode if available)
• Cron jobs running (scheduled posts publish; backup plugin’s schedule intact)
• Integrations pointing at the site: payment webhooks, third-party services, any IP-whitelisted APIs
• SSL padlock, no mixed-content warnings (crawl the site with a site crawler to catch these)
• New host’s backup system confirmed running

Restore the DNS TTL to a normal value once the move settles, and update any integrations that referenced the old IP.

If anything on the checklist fails, work through our WordPress troubleshooter to pin down the cause.

Keeping the old host live. Your safety net

Do not cancel the old hosting on migration day. Some resolvers ignore low TTLs, and some visitors will still reach the old server for a while. Documented advice ranges from at least several days to a week.

Check the old server’s access logs. When traffic to the old server falls to near zero, it’s safe to cancel, and only after you have a full backup stored safely elsewhere.

If the rollback trigger fires, the procedure is the same move in reverse: change DNS back to the old IP (fast with the short TTL), freeze writes during the switch, then copy back any writes that landed on the new server during the window using the switch time you wrote down. Calmly. The old server was never touched.

Exceptions and edge cases

• WooCommerce / membership sites. The content-freeze window matters most here. Orders and sign-ups are database writes that vanish if they land on the old server after the final sync. Plan a brief checkout pause during the final sync; a short maintenance message on checkout is honest and expected.
• Changing domains at the same time. Possible, but it adds a search-replace step (serialized-safe tool only) and SEO risk. If you can, migrate first and change the domain later.
• WordPress Multisite. Backup and restore differ for multisite. This guide’s steps assume a standard single-site install.
• SEO. Rankings are unaffected if the domain, URLs, and content stay the same. What hurts SEO is pages returning errors or URLs changing without redirects. A tested migration avoids both.

What to do next

• Just installed? How to Install WordPress on Hostinger (Step by Step)
• Watching uptime: What Is Uptime and Why 99.9% Isn’t What You Think
• DNS basics: Domain vs Hosting: What’s the Difference?
• Speeding up the new host: How to Speed Up WordPress: The Caching Guide
• How we evaluate hosts: our How We Test page

FAQ

Can you really migrate WordPress with zero downtime?
For most sites, yes. The old server keeps serving visitors while the new one is built and tested privately, and a short DNS TTL makes the switch quick. Sites that take orders or sign-ups may need a brief checkout pause during the final sync. Visitors can still browse, and nothing is lost.

How long does a WordPress migration take?
The copy itself often takes under an hour for a small site. DNS propagation adds minutes to hours for the switchover; plan for a day of overlap and keep the old host for several days.

Should I move email at the same time as the website?
Not necessarily. Moving them separately reduces risk. Keep MX records pointing at the current mail server until you’re ready to migrate mailboxes.

Will migration affect my SEO?
Not if the domain, URLs, and content stay the same. Downtime during the switch is the main risk. Which is why the TTL preparation matters.

Do I need to change URLs in the database after migrating?
Only if the domain or protocol changes. For the same domain, no change is needed; when it is needed, use a serialized-safe tool such as WP-CLI’s search-replace. Never a plain text find-and-replace.

Why does my old site still appear after I changed DNS?
Your resolver or browser cached the old answer. It clears as the TTL expires. Flushing your local DNS cache often helps on your own machine.

What’s the biggest mistake people make?
Cancelling the old hosting before propagation finishes, or forgetting MX records on a nameserver switch. The old host is your safety net. Keep it until the old server’s access logs go quiet.

Sources:
Bisup’s zero-downtime migration guide (Sep 2026), Hostaccent’s 2026 migration playbook, Bdazzil’s cutover-sequence guide, Webhelp Agency’s host-move guide, the hostingrank-ai migration checklist (GitHub), GoDaddy’s migration guide, Bozhidar Valchev’s manual migration walkthrough (dev.to), the Duplicator flow docs (quickguides/GitHub, WPressBlog), SiteGround’s WordPress transfer KB, and the kartikkyadav WordPress migration notes (GitHub).

---

Last updated: October 14, 2026. Plugin menus, panel labels, and free-tier limits change over time. Verify the current details on the provider’s site before you move.