# 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.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/migration/hebergeur-sans-interruption](https://allaux.fr/en/wordpress-woocommerce/migration/hebergeur-sans-interruption)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Lower the DNS record TTL to 300 seconds at least twenty-four hours before the switch: that is what shortens the window during which some visitors still land on the old server. Stand the copy up at the new host and test it by pinning its IP address in your hosts file, without touching public DNS. Put the site into maintenance right before the final database sync.

## 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.

## The point of no return: the final DNS switch

> Once DNS has switched and propagation has taken effect, going back to the old host means losing all data created on the new one (orders, customer accounts, edited content) since the switch. I only decommission the old hosting after an observation period confirms everything works correctly on the new one.

## Checking after the switch

> I check forms, the WooCommerce checkout if there is one, transactional email delivery and redirects before considering the migration finished.

## Going further

- **Changing domain name without losing your rankings** — The same serialisation mechanism applies, plus managing 301 redirects to the new domain. ([/wordpress-woocommerce/migration/changement-nom-domaine](/wordpress-woocommerce/migration/changement-nom-domaine))
- **Moving a WordPress site to HTTPS** — A URL change of the same nature, this time on the protocol, following the same correction logic. ([/wordpress-woocommerce/migration/https-contenu-mixte](/wordpress-woocommerce/migration/https-contenu-mixte))
- **Choosing hosting for e-commerce** — The criteria I check before recommending a host for a WooCommerce shop. ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce))
- **Understanding PHP serialisation** — The full definition of the mechanism covered on this page. ([/glossaire/serialisation](/glossaire/serialisation))

## FAQ

### 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.