How to Migrate a WordPress Site Without Downtime (2026 Guide)

Moving to a new host is one of those jobs that feels riskier than it actually is. If you plan the steps in the right order, you can migrate a WordPress site with zero visible downtime, no broken images, and no lost orders or comments. The trick is simple: build a complete working copy of your site on the new server first, verify it privately, and only then point your domain at it. Visitors keep hitting the old server until the very last moment, so there is never a gap where the site is offline.

This guide walks through the full WordPress migration process three ways: the manual method (files plus database), the plugin method, and host-managed migration. It also covers the part most tutorials rush through, which is the DNS cutover, because that is where downtime actually happens when a migration goes wrong.

Before You Start: Prep Work That Prevents Downtime

A smooth migration is mostly preparation. Do these four things before you touch a single file.

1. Lower your DNS TTL now. TTL (time to live) tells resolvers how long to cache your DNS records. If your A record has a TTL of 24 hours, some visitors will keep hitting your old server for up to a day after you switch. Log in to wherever your DNS is managed (your registrar or a service like Cloudflare), find the A record for your domain, and drop the TTL to 300 seconds (5 minutes). Do this at least 24 to 48 hours before the cutover so the old, longer TTL has time to expire from caches everywhere.

2. Take a full backup and keep it somewhere safe. Even if your host takes automatic backups, download your own copy of the files and database before you begin. If anything goes sideways, you can restore and start over.

3. Do some housekeeping. Delete deactivated plugins, unused themes, trashed posts, and old revisions. Everything you remove is something you do not have to transfer, and smaller databases import faster and fail less often.

4. Freeze content during the move. If your site takes orders, comments, or form submissions, pick a quiet window and put the site into a content freeze (or use maintenance mode briefly on the old site for the final database export). Any data written to the old database after your export will not exist on the new server unless you export again.

If you are switching hosts because of cost, it is worth reading up on what you should actually be paying. Our breakdown of WordPress hosting cost covers typical price ranges, and if a renewal bill is what triggered the move, you are not alone; see our post on Hostinger renewal prices for why introductory pricing rarely survives year two.

Method 1: Migrate WordPress Manually (Files + Database)

The manual method works on every host, has no file size limits, and teaches you exactly how WordPress fits together. It has two halves: the files and the database.

Step 1: Copy your files via SFTP

Connect to your old server with an SFTP client such as FileZilla or Cyberduck (your host's control panel will list the credentials). Download the entire WordPress directory, usually public_html or www. The parts that matter most:

• wp-content/ holds your themes, plugins, and uploads. This is the irreplaceable part.
• wp-config.php holds your database credentials and salts.
• .htaccess (on Apache) holds your permalink rules.

WordPress core files (wp-admin/, wp-includes/) can be re-downloaded from wordpress.org, but copying everything is simpler and safer.

Step 2: Export the database

You have two standard options:

phpMyAdmin: Open phpMyAdmin from your hosting control panel, select your WordPress database in the left sidebar, click the Export tab, choose the Quick method with SQL format, and download the .sql file.

WP-CLI: If you have SSH access, this is faster and more reliable for large databases:

wp db export backup.sql

Run it from your WordPress root directory. It produces a single SQL file you can download.

Step 3: Import at the new host

On the new server, create a fresh MySQL database and a database user with full privileges on it (note the database name, username, and password). Then import your SQL file, either through phpMyAdmin's Import tab or with WP-CLI:

wp db import backup.sql

Next, upload your files via SFTP to the new server's web root.

Step 4: Update wp-config.php

Open wp-config.php on the new server and update the database credentials to match the database you just created:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_password' );
define( 'DB_HOST', 'localhost' );

DB_HOST is usually localhost, but some hosts use a separate database hostname; check your new host's documentation.

Step 5: Search and replace URLs (only if the domain changes)

If you are keeping the same domain, skip this step entirely. If the domain is changing, the database is full of references to the old URL, and many of them live inside serialized PHP data that a plain SQL find-and-replace would corrupt. Use WP-CLI's serialization-aware command instead:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --dry-run

Review the dry run output, then run it again without --dry-run to apply. If you do not have WP-CLI, the interconnect/it Search Replace DB script and several plugins handle serialized data correctly; never do this with raw SQL UPDATE statements.

Method 2: Use a Migration Plugin

If SFTP and SQL files are not your idea of a good afternoon, plugins automate most of the above. Three well-established options:

• Duplicator packages your entire site (files plus database) into an archive with an installer script. You upload both to the new server, run the installer in a browser, and it rebuilds the site and handles URL replacement.
• All-in-One WP Migration exports the whole site to a single file, then imports it through the WordPress admin on the destination. You install a fresh WordPress on the new host first, then import over it. Note that the free version has an upload size limit, so very large sites may need the paid extension or a different method.
• UpdraftPlus is primarily a backup plugin, and its paid Migrator add-on can clone a site to a new location. If you already use UpdraftPlus for backups, restoring a backup onto a fresh install at the new host is a legitimate migration path too.

Plugins are great for small and medium sites. On very large sites (tens of gigabytes of uploads, huge databases), archive creation can time out on shared hosting, which is when the manual method or a managed migration earns its keep.

Method 3: Let Your New Host Do It

Many hosts will migrate your site for you, often at no charge, because it removes the biggest obstacle to switching. Ask the new host before assuming you have to do it yourself.

Full disclosure: Hosto is our managed WordPress hosting platform, and free migration is included on every plan. You send us a backup file or your current admin login, and our team handles the transfer, testing, and cutover coordination, usually within a day.

The DNS Cutover: Where Downtime Is Won or Lost

At this point your site exists in two places: live on the old host and staged on the new one. Do not point DNS yet. Verify first.

Step 6: Test the new site with the hosts file trick

You can preview the new server as if DNS had already switched by editing your computer's hosts file, which overrides DNS locally without affecting anyone else:

• macOS/Linux: edit /etc/hosts
• Windows: edit C:\Windows\System32\drivers\etc\hosts

Add a line with your new server's IP and your domain:

203.0.113.45  yourdomain.com www.yourdomain.com

Save, flush your DNS cache, and open your domain in a browser. You are now browsing the new server while the rest of the world still sees the old one. Click through key pages, log in to wp-admin, test forms and checkout, check that images load, and confirm permalinks work. Set up SSL on the new server before cutover; most hosts can issue a Let's Encrypt certificate ahead of the switch.

Step 7: Point DNS at the new server

Once everything checks out, update the A record (and any www record) at your DNS provider to the new server's IP. Because you lowered the TTL earlier, most visitors will reach the new server within minutes. Remove the hosts file entry so you see what real visitors see.

Step 8: Keep the old host live for 48 hours

Do not cancel the old hosting account the moment DNS changes. Some resolvers and ISPs cache records longer than they should, so a slice of traffic may still land on the old server for a while. Keep the old site running unchanged for at least 48 hours, keep the content freeze in place if the site accepts orders or comments, and cancel the old account only once server logs show traffic there has stopped.

Post-Migration Checklist

• Re-save permalinks (Settings, then Permalinks) to regenerate rewrite rules.
• Confirm HTTPS works and that HTTP requests redirect to HTTPS.
• Test email sending, since contact forms often break when the server changes.
• Update any hardcoded IPs in CDN, firewall, or uptime monitoring settings.
• Crawl the site for broken links and mixed content warnings.
• Verify scheduled tasks (wp-cron) are firing by checking a scheduled post or backup.
• Set up backups on the new host from day one.

FAQ

How long does a WordPress migration take?

For a typical small site, plan for one to three hours of hands-on work with the manual method, and less with a plugin. Large media libraries extend transfer time, and DNS propagation adds a waiting period after cutover, which is why lowering your TTL in advance matters.

Will migrating my WordPress site hurt SEO?

Not if the domain stays the same, since URLs, content, and structure are unchanged and search engines only see a new IP address. If you are changing domains, you need 301 redirects from every old URL to its new equivalent and an address change notification in Google Search Console, which is a separate project from the hosting move itself.

Can I migrate a WordPress site for free?

Yes. The manual method costs nothing, Duplicator and All-in-One WP Migration have free versions that cover most small sites, and many hosts (including ours) migrate incoming sites at no charge. You generally only pay when a site is unusually large or complex.

Do I need to put my site in maintenance mode during migration?

Not for most of it. The whole point of staging the copy on the new server first is that the live site keeps running untouched. The only window where a freeze matters is between your final database export and the DNS cutover, because content created on the old server in that gap will not exist on the new one. For a static brochure site, you can often skip the freeze entirely.

Migrating a WordPress site is a sequence, not a leap: stage the copy, verify it privately, lower the TTL, switch DNS, and leave the old server running as a safety net. Follow that order and your visitors will never know anything changed.