How to move a WordPress site to new hosting without downtime

What needs to move with a WordPress site

A WordPress website has more than the pages you can see. Its files include WordPress itself, the theme, plugins and uploaded images. Its database holds page content, settings, user accounts and much of the information that makes the site behave as it does. A complete move needs both parts.

There may also be work outside WordPress. A contact form can send through a separate service. A booking tool may live at a different address. Email can use its own records. Make a list of every public address and every job a visitor can complete before anyone copies a file.

The WordPress migration guide starts with a backup of the site files and database. It also calls out settings such as the site address, database connection and permalink rules. Those details are where a move often goes wrong when someone treats it as a simple upload.

Plan the move before changing DNS

DNS is the set of records that tells a browser where a domain should go. Each record has a TTL, short for time to live. It is the period other systems can keep an old answer before asking again. Lower that setting in advance if the current provider allows it. The lower value needs time to spread before the switch, so do not leave this until the same afternoon.

Agree a switch window with the people who edit the site. A quiet period makes the final copy smaller and reduces the chance that a new enquiry, order or page update appears on the old host after the database has been copied. The aim is a short pause in editing, not a pause for visitors.

1. Record the domain, hosting access, WordPress address and every connected service.
2. Take a backup that can be restored separately from the live site.
3. Prepare the new server with the required PHP version, database and SSL certificate.
4. Choose a short final sync window and tell editors when it will happen.

Test the new host without sending visitors there

Copy the files and database to the new host first, then test that copy privately. The exact method varies by host. It may be a temporary address, a staging address or a controlled local DNS override. The useful rule is simple: check the new server while the public domain still points to the old one.

Open the home page, key landing pages, search, contact forms and any logged in area. Check the pages on a phone as well as a desktop browser. Look for missing images, wrong links, slow sections, broken layout and a browser warning about the certificate. Test a real form route with safe test details, then confirm where the email arrives.

When B&T Solutions moved their WordPress site, the move also covered a separate forms application at /onlineforms that visitors use every day. Every change first went onto a private staging copy. Before the switch, 19 pages were compared by screenshot on desktop and phone, then the forms were checked too.

Make the final sync and switch the domain

Once the staging copy is sound, briefly stop edits on the old site. Take one final database export and copy any files that changed since the first transfer, such as new uploads. Restore those changes to the prepared copy. This is the point where the two versions are brought back together.

Then change the DNS record to the new host. Some visitors may reach the new server quickly while others keep using the old answer until their saved record expires. That is why both copies should continue to work during the transition. Watch the important pages, form deliveries and server logs after the change rather than assuming the record is enough.

Check forms, email and SSL after the switch

A page loading is not the finish line. Send a form submission, check its confirmation, and make sure the recipient receives it. Test any application that sits beside WordPress. Check password resets, calendar links, file uploads and notification emails if the site uses them. Open the site in a private browser window to make sure no saved login or cache is hiding a problem.

SSL is the certificate that lets a browser connect over HTTPS. Confirm that both the main domain and any www version load without a warning and redirect to the intended address. Check that old HTTP links redirect correctly. If the move changes the database server, confirm the new credentials are in the configuration before the public switch.

B&T used the move as a chance to fix issues that should not have followed the site to its new home. About 18 MB of dead files and duplicate code were removed, including a file that allowed code to run from a page widget. A plugin blocking WordPress and plugin updates was removed before everything was updated. The hero video was given a fixed width and height so the page stopped jumping while it loaded. The site and forms stayed available to visitors during the move.

Keep the new host easy to maintain

A move is a good time to leave the next person clear access. The business should know where the domain is managed, where the site is hosted, who can update WordPress and how a backup is restored. Keep those details in a short handover note with a current contact for the hosting company. Test that the named people can sign in before the old account is closed.

The B&T work also added a page cache. On the private copy, cached page response time fell from about 0.21 seconds to about 0.002 seconds. An Arabic font was hosted with the site and loaded only for Arabic text. Both were tried on the private copy before they reached the live site.

If you are deciding whether to keep adapting an old site or replace it, our guide to custom software or SaaS may help. For a move, rebuild or support plan, get in touch.