Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

Switching WordPress host with minimal downtime for visitors

Switching host isn’t just about copying files: the WordPress database holds serialised data that wraps URLs, and a careless replace corrupts it silently. Here’s the method I follow, from the first export through to the final DNS switch.

Describe my issue Send a message

What URL replacement touches at a deep level

WordPress stores some of its settings (theme options, widget configuration, plugin preferences) as serialised PHP data in text columns of the MySQL database. A serialised string encodes the exact length of every substring it contains: for example, s:22:"https://old-site.co.uk" means “a 22-character string, here’s its content”. If the test or destination site uses a different URL (a temporary address, subdomain, or IP), and it’s replaced with a plain SQL UPDATE using REPLACE(), the number declared before the quotes no longer matches the new string length.

It’s not a marginal case: on a WooCommerce shop, the old site’s address can turn up in dozens of separate serialised records (payment gateway settings, cart widgets, shipping extension preferences), each one potentially corrupted by a blunt replace. It’s this scattered volume that makes the problem hard to spot at a glance before a customer reports a specific glitch.

WordPress then fails to deserialise the data correctly: theme settings reset to defaults, widgets disappearing from the sidebar, empty plugin options, often with no visible error for days. The correct method goes through a tool that recalculates these lengths on every replacement, typically the WP-CLI command wp search-replace old-url new-url --all-tables.

How I switch host without visible downtime

  1. Copying files and database

    I copy the entire site’s files and a full database export to the new hosting, without touching the live site.

  2. Adapting wp-config.php

    I fill in the new database connection details (name, user, password, host) in wp-config.php on the new environment.

  3. Fixing URLs with wp search-replace

    If the test site is reachable under a different address (temporary subdomain, IP), I fix the stored URLs with wp search-replace, which recalculates serialised string lengths instead of breaking them.

  4. Validating via the local hosts file

    I test the site on the new hosting by temporarily editing my machine’s hosts file, which points to the new server without touching the public DNS or affecting visitors.

  5. Lowering the DNS TTL beforehand

    A few days before the switch, I lower the TTL (time to live) of the DNS records to speed up propagation once the change happens.

  6. Switching DNS or server during low traffic

    I schedule the switch for a low-traffic window, and carry over any orders or messages received between the initial copy and the final switch if the site sells online.

Going further

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

Will the site be unavailable during the migration?
Preparation happens entirely on the new hosting without touching the live site. The only real downtime is the final DNS switch, usually a few minutes to a few hours depending on propagation.
How do I test the new site before cutting over DNS?
By temporarily editing my machine’s hosts file to point the domain name at the new IP, which lets me browse the site like a normal visitor without affecting anyone else.
What happens to orders placed during the migration?
I note the exact time of the initial copy and manually carry over any orders or messages received between that copy and the final switch, so nothing is lost.
Why lower the DNS TTL before switching?
A high TTL means intermediate DNS servers cache the old address for longer. Lowering it a few days beforehand speeds up how quickly the change takes effect at switch time.
Can I undo the migration after the DNS switch?
Technically yes, by pointing DNS back at the old host, but any data created on the new site since the switch (orders, accounts, content) would be lost. That’s why I treat the DNS switch as the point of no return.

Related pages