Migration WordPress entre deux hébergeurs : la vraie checklist en 20 étapes

J ai migré plus de 120 sites WordPress entre hébergeurs depuis 2015. Des sites vitrine chez OVH vers o2switch, des WooCommerce de Hostinger vers Infomaniak, des WordPress headless de mutualisé vers VPS. Et à chaque fois, je constate la même chose : ce n est pas la migration en elle-même qui pose problème, c est tout ce qu on oublie autour.

Ce guide est la checklist que j utilise en production, étape par étape. Pas de théorie abstraite : chaque point correspond à un problème réel rencontré sur un projet client.

Pourquoi migrer son WordPress vers un autre hébergeur

La première question à se poser est simple : pourquoi migrer ? Parce qu une migration mal justifiée, c est du risque pour rien.

Les raisons légitimes que je vois revenir en 2026 :

Performance insuffisante. Un TTFB supérieur à 800 ms en mutualisé, des pics de charge qui font tomber le site. Si vous avez déjà optimisé le cache object Redis et que ça ne suffit toujours pas, c est l hébergeur le goulot d étranglement.

Support technique absent. Quand un ticket met 72 heures à obtenir une réponse sur un site e-commerce en panne, c est un signal clair.

Besoin de SSH et Git. Beaucoup d hébergeurs mutualisés bloquent encore l accès SSH. Pour un workflow de développement moderne avec déploiement Git, c est rédhibitoire.

Changement de stack. Passer d un mutualisé à un VPS pour installer WordPress en headless avec Next.js, par exemple.

Tarification devenue excessive. Les prix de renouvellement chez certains hébergeurs doublent après la première année. J ai vu des clients passer de 3,99 € à 12,99 €/mois sans amélioration de service.

Si votre seule motivation est « un ami m a dit que tel hébergeur est mieux », prenez le temps de comparer sérieusement avec un comparatif d hébergeurs à jour avant de vous lancer.

Les prérequis avant de toucher à quoi que ce soit

Avant même d exporter le moindre fichier, il faut verrouiller plusieurs points. C est ici que 80 % des migrations ratées se jouent.

Vérifiez la version PHP du nouvel hébergeur. Votre site tourne en PHP 8.1 ? Le nouvel hébergeur propose PHP 8.3 par défaut ? Testez la compatibilité de vos plugins avant la migration, pas après. Le plugin PHP Compatibility Checker fait ça en deux clics.

Notez la taille de votre base de données. En dessous de 500 Mo, un plugin de migration suffit. Au-dessus de 1 Go, passez directement à la méthode manuelle. Entre les deux, ça dépend de la qualité de votre connexion et de la patience que vous avez.

Listez tous vos accès. Panneau de contrôle actuel, FTP/SFTP, base de données (host, user, password, nom de la base), accès DNS (souvent chez le registrar, pas chez l hébergeur), accès email si hébergé au même endroit.

Faites un export complet de vos emails. Si vos boîtes mail sont hébergées chez l ancien prestataire et que vous changez les DNS, vous perdrez l accès. Exportez tout en IMAP ou demandez à votre nouvel hébergeur s il propose un outil de migration email.

Désactivez les tâches cron lourdes. Si vous avez des imports WooCommerce programmés, des sauvegardes automatiques via UpdraftPlus, ou des envois de newsletter Brevo planifiés, suspendez-les. Vous ne voulez pas qu un cron se déclenche en pleine migration.

Vérifiez l espace disque disponible sur le nouvel hébergement. Un site WordPress avec WooCommerce et 4 000 produits peut facilement peser 8 à 15 Go avec les images.

Méthode 1 : migration par plugin (Duplicator ou All-in-One)

C est la méthode que je recommande pour les sites de moins de 1 Go. Elle fonctionne dans la grande majorité des cas et ne nécessite pas d accès SSH.

Duplicator (version gratuite) reste mon premier choix en 2026. Le plugin crée une archive contenant les fichiers WordPress et un dump SQL de la base de données, plus un installeur PHP autonome.

Voici le processus étape par étape :

1. Installez Duplicator sur le site source. Créez un nouveau paquet. Laissez les options par défaut sauf si vous avez des fichiers volumineux à exclure (dossier de cache, logs).

2. Téléchargez les deux fichiers générés : l archive zip et le fichier installer.php.

3. Uploadez ces deux fichiers à la racine du nouvel hébergement via FTP ou le gestionnaire de fichiers du panneau de contrôle.

4. Créez une base de données vide sur le nouvel hébergement. Notez le nom de la base, l utilisateur et le mot de passe.

5. Accédez à installer.php via le navigateur (votredomaine.com/installer.php ou l IP temporaire du serveur). Suivez l assistant.

Le piège classique avec Duplicator : les limites d upload du nouvel hébergeur. Si votre archive fait 800 Mo et que la limite PHP est à 128 Mo, l upload via l interface web échouera. Passez par FTP dans ce cas.

All-in-One WP Migration est l alternative si Duplicator pose problème. Plus simple d interface, mais la version gratuite limite l import à 512 Mo. La version payante (69 $ pour un site) lève cette limite.

Un point important : ces deux plugins gèrent automatiquement le search and replace des URLs dans la base de données. Si vous changez de nom de domaine en même temps que d hébergeur, ils remplaceront toutes les occurrences de l ancienne URL par la nouvelle.

Méthode 2 : migration manuelle via SSH et mysqldump

Pour les sites volumineux, les bases de données lourdes, ou quand vous voulez un contrôle total, la méthode manuelle est incontournable.

Étape 1 : exporter la base de données. Connectez-vous en SSH à l ancien serveur et lancez :

mysqldump -u utilisateur -p nom_base > backup_$(date +%Y%m%d).sql

Pour les bases volumineuses, ajoutez les options –single-transaction (évite de verrouiller les tables InnoDB) et –quick (réduit la consommation mémoire).

Étape 2 : transférer les fichiers. Depuis le nouveau serveur, utilisez rsync plutôt que SCP :

rsync -avz --progress user@ancien-serveur:/var/www/wordpress/ /var/www/nouveau-site/

Rsync a l avantage de reprendre un transfert interrompu et de ne copier que les fichiers modifiés si vous devez relancer.

Étape 3 : importer la base de données. Sur le nouveau serveur :

mysql -u nouvel_utilisateur -p nouvelle_base < backup_20260419.sql

Étape 4 : modifier wp-config.php. Mettez à jour les constantes de connexion à la base :

define('DB_NAME', 'nouvelle_base');
define('DB_USER', 'nouvel_utilisateur');
define('DB_PASSWORD', 'nouveau_mot_de_passe');
define('DB_HOST', 'localhost');

Attention : chez certains hébergeurs (OVH notamment), le DB_HOST n est pas localhost mais une adresse spécifique.

Étape 5 : search and replace. Si le domaine change, utilisez Search Replace DB ou WP-CLI :

wp search-replace 'ancien-domaine.fr' 'nouveau-domaine.fr' --all-tables

N oubliez pas le flag --all-tables : sans lui, WP-CLI ignore les tables créées par les plugins (et il y en a toujours).

Étape 6 : permissions des fichiers. Vérifiez que les permissions sont correctes : 755 pour les dossiers, 644 pour les fichiers, et 600 pour wp-config.php.

DNS, SSL et propagation : les étapes critiques

C est le moment le plus stressant de la migration, et celui où la plupart des erreurs arrivent.

Réduisez le TTL DNS 48 heures avant la migration. Passez-le de 3600 (1 heure, valeur courante) à 300 (5 minutes). Ça accélère la propagation le jour J. J ai vu des clients oublier ce point et attendre 48 heures avec deux versions du site en ligne.

Modifiez les enregistrements DNS chez votre registrar. Changez le A record pour pointer vers l IP du nouveau serveur. Si vous utilisez des enregistrements AAAA (IPv6), mettez-les à jour aussi. Les MX records ne doivent être modifiés que si vous changez aussi de serveur mail.

Le certificat SSL doit être en place avant le changement DNS. Sur le nouveau serveur, installez Let's Encrypt via Certbot ou l outil de votre hébergeur. Si le domaine ne pointe pas encore vers le nouveau serveur, utilisez la validation DNS (challenge TXT) plutôt que HTTP.

Gardez l ancien hébergement actif au minimum 72 heures après le changement DNS. Pendant la propagation, certains visiteurs verront encore l ancien serveur. Si vous le coupez trop tôt, ces visiteurs auront une erreur 404.

Pour vérifier la propagation en temps réel, utilisez whatsmydns.net : il interroge des serveurs DNS dans le monde entier et vous montre qui pointe où.

La checklist complète en 20 étapes

Voici la checklist que j utilise pour chaque migration client. Je la parcours dans l ordre, sans sauter d étape.

Cette checklist couvre un site vitrine standard. Pour un WooCommerce actif, ajoutez des étapes spécifiques (voir la section cas particuliers plus bas).

Tests post-migration : tout vérifier avant de couper l ancien hébergement

Une migration n est terminée que quand les tests passent. Voici ma liste de vérifications systématiques.

Page d accueil et pages principales. Vérifiez le rendu visuel, les images, les polices. Un chemin absolu codé en dur dans un thème custom peut casser l affichage.

Formulaires de contact. Envoyez un message test. Vérifiez que le mail arrive bien, et que la fonction PHP mail() ou le SMTP configuré fonctionne sur le nouveau serveur. C est le point de rupture le plus courant : le formulaire affiche "envoyé" mais rien n arrive.

Panier et tunnel d achat (si WooCommerce). Testez un achat complet en mode sandbox avec votre passerelle de paiement. Les webhooks Stripe ou PayPal pointent peut-être encore vers l ancienne IP.

Redirections 301. Si vous aviez des redirections dans le .htaccess ou via un plugin comme Redirection, vérifiez qu elles fonctionnent toujours. Un .htaccess mal transféré peut perdre toutes vos redirections et détruire votre référencement.

Certificat SSL. Naviguez en HTTPS sur toutes les pages. Cherchez les erreurs de contenu mixte (mixed content) via la console du navigateur. Un seul appel HTTP sur une page HTTPS suffit à afficher l avertissement de sécurité.

Vitesse de chargement. Lancez un test sur PageSpeed Insights et comparez avec les résultats d avant migration. Si le TTFB a augmenté de plus de 200 ms, il y a un problème côté serveur.

Sitemap XML. Accédez à /sitemap.xml et vérifiez qu il se génère correctement. Soumettez-le à nouveau dans la Google Search Console pour accélérer l indexation.

Cron WordPress. Vérifiez que wp-cron fonctionne en consultant la page Outils > Santé du site. Si le nouvel hébergeur bloque les requêtes loopback, configurez un vrai cron système.

Les mu-plugins. Si vous utilisez des mu-plugins pour des fonctions critiques, vérifiez que le dossier wp-content/mu-plugins a bien été transféré. C est un oubli classique car certains plugins de migration l ignorent.

Les erreurs qui plantent 90 % des migrations

Après plus de cent migrations, les mêmes erreurs reviennent sans cesse. Voici les sept que je vois le plus souvent.

Erreur 1 : oublier le search-replace sérialisé. WordPress stocke des données sérialisées dans la base (options de thème, widgets, réglages de plugins). Un simple REPLACE SQL casse la sérialisation. Utilisez toujours WP-CLI ou un outil dédié qui gère la sérialisation.

Erreur 2 : copier le dossier cache. Le dossier wp-content/cache contient des fichiers compilés pour l ancien serveur. Le transférer tel quel sur le nouveau serveur provoque des erreurs 500. Supprimez-le avant ou après le transfert.

Erreur 3 : ne pas vérifier le .htaccess. Le fichier .htaccess de l ancien serveur peut contenir des règles spécifiques (redirections, headers de sécurité, règles mod_rewrite custom). Si le nouveau serveur utilise Nginx au lieu d Apache, ces règles ne fonctionneront plus : il faut les convertir en directives Nginx.

Erreur 4 : négliger les chemins absolus dans le thème. Un thème enfant ou un thème custom peut contenir des chemins codés en dur vers /home/ancien-user/public_html/. Faites un grep récursif pour les détecter.

Erreur 5 : migrer pendant les heures de pointe. Pour un site e-commerce, migrez entre 2 h et 6 h du matin. Chaque commande passée pendant la migration sur l ancien serveur sera perdue si elle n est pas dans le dump final.

Erreur 6 : oublier les tâches planifiées externes. Les intégrations tierces comme Make (ex-Integromat) ou Zapier qui appellent votre site via webhook doivent être mises à jour si l URL change.

Erreur 7 : couper l ancien hébergement trop tôt. J ai eu un client qui a résilié son hébergement OVH le jour même du changement DNS. Résultat : 30 % de ses visiteurs ont eu une page blanche pendant 36 heures. Attendez au minimum 72 heures, idéalement une semaine.

Cas particuliers : WooCommerce, multisite et headless

Migration WooCommerce. La difficulté supplémentaire, c est la base de données vivante. Des commandes arrivent en continu. Ma méthode : mettre le site en mode maintenance, faire le dump, migrer, puis vérifier qu aucune commande n a été passée entre le dump et la coupure. Pour les gros volumes, utilisez la réplication MySQL en temps réel si les deux hébergeurs le permettent.

Les passerelles de paiement méritent une attention particulière. Stripe utilise des webhooks qui pointent vers votre domaine : si le domaine ne change pas, rien à faire. Mais si vous utilisez une IP dans la configuration, mettez-la à jour. PayPal IPN doit être reconfiguré dans le dashboard PayPal si l URL de notification change.

Migration multisite. WordPress multisite ajoute des tables supplémentaires par sous-site (wp_2_posts, wp_3_options, etc.). Le search-replace doit couvrir toutes ces tables. Duplicator Pro gère le multisite ; la version gratuite ne le fait pas. En méthode manuelle, WP-CLI avec --network est votre meilleur allié.

Migration headless. Si votre WordPress sert d API pour un frontend Next.js ou Astro, la migration du back-end WordPress suit le même processus. Mais pensez à mettre à jour l URL de l API dans les variables d environnement de votre frontend. Et si vous utilisez des webhooks de revalidation, vérifiez qu ils pointent vers la bonne URL après migration.

Sites avec CDN (Cloudflare, Bunny, KeyCDN). Si un CDN est en place, purgez le cache CDN après migration. Et si vous utilisez Cloudflare en mode proxy (nuage orange), le changement DNS se fait dans Cloudflare, pas chez le registrar.