How to Move a WordPress Site Without Downtime

A hosting move looks simple on paper and feels enormous when the site brings in your enquiries. The current host is slow, or the renewal invoice has jumped, so you decide to move. Then somebody mentions DNS, and the plan slides to next month.

Very little of this needs luck. Moving WordPress is a sequence, and most of the damage comes from doing the steps out of order: pointing the domain before the new copy works, or closing the old plan in the same week. Here is the order that keeps a live site up.

Write down everything the old host does for you

A WordPress site is two things. The files, which include the theme, the plugins and every image ever uploaded, and the database, which holds your pages, products, orders and settings. Both have to travel.

The hosting account usually does more than run WordPress, and the extras are what get forgotten.

• Business email running from the same panel, such as info@ or accounts@
• DNS records other than the website, including MX for mail and TXT records for verification
• Files sitting outside WordPress: old landing pages, PDF brochures, a subfolder holding a second site
• Redirects in the .htaccess file, and cron jobs that send reports or run imports
• The PHP and MySQL versions the site currently runs on

Email bites hardest. If your mailboxes live with the old host and you change nameservers without recreating the mail records first, messages stop arriving while everyone is busy looking at the website. Decide early whether email moves too, and screenshot the existing records before you touch anything.

Take a copy you can hold yourself

Before anything changes, make a full backup and download it. Not a copy that lives only on the server you are about to leave, and not just the automatic one your host keeps. Files and database, on your own laptop or office drive.

Open the archive once and look inside. You want the wp-content folder with your uploads in it, and a database file clearly bigger than a few kilobytes. A migration plugin will make this copy, and so will SFTP plus a database export from phpMyAdmin. The method matters less than having the file in your hand.

One exception is worth knowing. If you are leaving because the site was infected, copying everything across carries the infection to the new server. Clean first, then move. Our guide on what to do when a site is hacked covers that order.

Build it on the new host before the domain points anywhere

This is the step that removes the fear. The complete site can run on the new server, at your real domain name, visible only to you, while the public keeps seeing the old one. Nothing is live until you decide it is.

Restore the copy on the new host, then preview it by editing the hosts file on your computer. The hosts file is a small text file that tells your own machine where a domain lives, so your browser goes to the new server while everybody else still lands on the old one. The new host's support team will give you the server IP address.

Then test properly, not just the home page.

• An inner page and a blog post, to prove permalinks work
• A product page and a test checkout if you run WooCommerce
• The contact form, and confirmation that the mail actually arrives
• Admin login, an image upload and the site search
• Anything with a licence key, such as a premium theme or a form plugin

Fix everything you find at this stage. Problems caught here are private. The same problems caught after the switch are public.

Lower the TTL, then switch in a quiet hour

Every DNS record carries a time to live, a number in seconds telling other networks how long they may remember the answer. If yours is set to a day, some visitors keep reaching the old server for a day after you change it. Drop the TTL to five minutes a day before the move and the switch becomes close to instant.

Then understand the overlap. For a short while some people see the new server and some the old one. That is harmless for a brochure site and awkward for anything that collects data, because an enquiry can land on the server you are abandoning. Pick your quietest hour, and if you take orders, pause the shop briefly or export the database from the old server right before you flip.

Keep the old hosting alive for two or three weeks afterwards. It costs one more month and gives you somewhere to look if something turns out to be missing. Cancel once the new site has carried real traffic and real enquiries.

What usually breaks in the first hour

A short list accounts for most of the panic after a move, and all of it is fixable once you know where to look.

• No SSL certificate on the new host yet, so browsers show a security warning
• Inner pages returning 404 because the .htaccess rules did not come across, which resaving permalinks usually rebuilds
• Contact form mail vanishing because the old host was relaying it, so the form now needs a proper sending service
• Mixed content warnings from images and scripts still being requested over http
• Scheduled jobs stopping, which quietly kills backups, scheduled posts and imports

Check the site on your phone over mobile data as well as office wifi, because your own computer may still be using the hosts file entry you added earlier. A day later, open Search Console. A host move does not reset rankings, but a noindex tag left behind from a staging copy, or a robots.txt file that blocks crawlers, does real damage.

Who should run the move, and when moving is not the answer

A small brochure site with a handful of plugins is a genuine do it yourself job for one evening, especially with a migration plugin doing the copying. A shop with live orders, a membership site, or a build with custom code in the theme deserves a rehearsal on a staging copy first.

It is also worth checking that hosting is really your problem. If the site is slow because of a heavy page builder, unoptimised images or fifty plugins, a faster server hides that for a while and then the same weight comes back. If the build itself is dated and painful to edit, moving it preserves the pain, and the questions in our piece on signs a website needs a redesign are better ones to answer first.

If you would rather the copying, the download and the restore happen in one place, that is what our own SiteShift Migrator plugin was built for. Whatever tool you pick, keep the order: full copy first, test on the new server second, DNS last.

FAQs