Ma migration WordPress a échoué : que faire ?

Une migration WordPress consiste à déplacer un site vers un nouveau serveur, un nouvel hébergeur ou un nouveau domaine. Quand elle échoue, le site peut se retrouver dans un entre-deux inconfortable : en partie sur l’ancien serveur, en partie sur le nouveau, et pleinement fonctionnel sur aucun des deux.

Vous pouvez remarquer que :

• le nouveau site affiche des erreurs ou une page blanche
• les pages se chargent, mais des images manquent
• des liens ou la page de connexion vous renvoient vers l’ancien domaine
• le navigateur affiche un avertissement « non sécurisé »
• certains visiteurs voient l’ancien site et d’autres le nouveau
• l’import de la base de données s’est arrêté avec une erreur
• le tableau de bord n’est pas accessible

Une migration échouée peut être stressante, surtout si le site fait partie de votre activité. Cependant, tant que le site d’origine et une sauvegarde existent encore, la situation peut presque toujours être rattrapée.

La règle la plus importante est simple : ne supprimez pas l’ancien site tant que le nouveau n’a pas été entièrement vérifié.

Ce guide explique ce qui tourne généralement mal pendant une migration, ce que vous pouvez vérifier sans risque, ce qu’il faut éviter et quand il vaut mieux demander une assistance technique.

Que signifie généralement une migration échouée ?

Un site WordPress se compose de deux parties principales :

• les fichiers : WordPress lui-même, les thèmes, les plugins et les médias téléversés
• la base de données : pages, articles, réglages, utilisateurs, commandes et bien plus encore

Une migration copie ces deux parties vers le nouvel emplacement, les relie, puis fait pointer le domaine vers le nouveau serveur.

Une migration échoue lorsque l’une de ces étapes est incomplète ou incorrecte. Par exemple :

• certains fichiers n’ont pas été copiés
• la base de données n’a été importée qu’en partie
• les réglages du site font encore référence à l’ancienne adresse
• le domaine pointe encore vers l’ancien serveur
• le nouveau serveur est configuré différemment

La bonne nouvelle, c’est que chacun de ces problèmes peut être vérifié séparément.

Qu’est-ce qui a pu mal tourner ?

Le site n’a été migré qu’à moitié

Les sites volumineux peuvent dépasser le délai d’attente pendant le transfert. Un plugin de migration ou un envoi manuel peut s’arrêter sans erreur claire, en laissant derrière lui certains fichiers ou certaines tables de la base de données.

Les signes typiques sont des images manquantes, des plugins manquants, un thème qui semble cassé ou des pages qui n’existent pas sur le nouveau site.

Les liens et les images pointent vers l’ancien domaine

WordPress enregistre l’adresse du site dans ses réglages et dans le contenu : dans les liens, les chemins des images et certains réglages de plugins. Si le domaine a changé et que ces références n’ont pas été mises à jour, le nouveau site peut charger les images depuis l’ancien serveur, ou y renvoyer les visiteurs.

Tout peut sembler fonctionner tant que l’ancien site est en ligne, puis casser au moment où il est désactivé.

Les avertissements de contenu mixte

Si le nouveau site utilise le HTTPS mais qu’une partie du contenu est encore chargée en HTTP, les navigateurs peuvent afficher un avertissement « non sécurisé » ou bloquer des parties de la page. Cela arrive souvent après un passage à un nouveau domaine ou l’activation d’un certificat SSL pendant la migration.

Le DNS n’est pas encore propagé

Lorsque le domaine est dirigé vers un nouveau serveur, le changement n’est pas visible partout en même temps. Pendant un moment, certains visiteurs peuvent atteindre l’ancien serveur et d’autres le nouveau. C’est normal, mais cela peut prêter à confusion pendant les tests.

L’ancien site est toujours en ligne et reçoit des commandes

C’est le risque le plus important pour les sites ecommerce et les sites à abonnement.

Si des clients continuent à passer des commandes, à s’inscrire ou à envoyer des formulaires sur l’ancien site après la copie de la base de données, ces nouvelles données n’existent que sur l’ancien serveur. Si l’ancien site est ensuite supprimé, les données peuvent être perdues. Si les deux sites restent en ligne, vos données se retrouvent réparties entre deux endroits.

Les erreurs d’import de la base de données

L’import de la base de données peut échouer parce que :

• le fichier dépasse la limite d’envoi
• l’import dépasse le délai d’attente
• le nouveau serveur de base de données utilise une autre version
• un jeu de caractères ou une collation n’est pas pris en charge
• le préfixe des tables ne correspond pas à wp-config.php

Une base de données importée en partie peut provoquer des erreurs, du contenu manquant ou le message « Error establishing a database connection » (Erreur lors de la connexion à la base de données).

Les permissions de fichiers et la configuration du serveur

Sur le nouveau serveur, les fichiers peuvent appartenir au mauvais utilisateur ou avoir de mauvaises permissions. Cela peut empêcher WordPress de téléverser des médias, d’installer des mises à jour, voire de se charger. Des différences de version PHP ou de règles serveur peuvent aussi provoquer des erreurs qui n’existaient pas auparavant.

Ne supprimez pas l’ancien site

Tant que le nouveau site n’a pas été entièrement testé, l’ancien site est votre filet de sécurité.

Conservez :

• l’ancien compte d’hébergement actif
• les anciens fichiers et l’ancienne base de données
• une sauvegarde complète réalisée avant le début de la migration

Si l’ancien site reçoit encore des commandes ou des inscriptions, demandez à un développeur comment gérer la situation. Selon le cas, il peut être préférable de le mettre en mode maintenance, de le rediriger ou de prévoir une synchronisation finale des données. Évitez de prendre cette décision dans la précipitation, car elle détermine où vos données finiront.

D’abord, comprenez où la migration s’est arrêtée

Essayez de répondre à ces questions :

• Quelle méthode a été utilisée : un plugin de migration, un outil de l’hébergeur, une copie manuelle ?
• Le domaine a-t-il changé, ou seulement le serveur ?
• Le domaine pointait-il déjà vers le nouveau serveur ?
• Le processus a-t-il affiché un message d’erreur ?
• Quand la base de données a-t-elle été copiée ?
• Quelqu’un a-t-il passé des commandes ou modifié du contenu depuis ?
• L’ancien site est-il toujours en ligne ?

Notez ce que vous savez. Même une chronologie partielle est très utile.

Que pouvez-vous vérifier sans risque ?

Vérifiez quel serveur vous voyez réellement

À cause de la propagation DNS et du cache, vous regardez peut-être l’ancien site sans le savoir. Demandez à votre hébergeur comment prévisualiser le nouveau site, ou vérifiez vers où pointe le domaine (voir la section pour les utilisateurs autonomes).

Comparez l’ancien et le nouveau site

Ouvrez les mêmes pages sur les deux versions et comparez :

• la page d’accueil et quelques pages internes
• les images et les téléchargements
• les formulaires et la recherche
• la page de connexion et le tableau de bord
• la boutique, le panier et le checkout, si vous en avez un

Notez les pages différentes ou cassées.

Vérifiez les réglages d’adresse du site

Si vous pouvez accéder au tableau de bord du nouveau site, allez dans Settings > General (Réglages > Général) et regardez l’adresse web de WordPress (URL) et l’adresse web du site (URL). Elles doivent indiquer la nouvelle adresse.

Ne les modifiez pas si vous n’êtes pas sûr de vous, car une mauvaise valeur peut vous empêcher d’accéder au tableau de bord.

Contactez l’hébergeur

Le nouvel hébergeur peut souvent confirmer si les fichiers et la base de données ont été importés intégralement, fournir des logs d’erreurs et vérifier les permissions ou les réglages PHP. De nombreux hébergeurs proposent aussi une aide à la migration.

Que faut-il éviter ?

Évitez de :

• supprimer l’ancien site, sa base de données ou son compte d’hébergement
• relancer la migration par-dessus un site qui fonctionne en partie sans sauvegarde
• faire un rechercher-remplacer dans la base de données avec un éditeur de texte ou une simple requête SQL
• modifier le DNS dans un sens puis dans l’autre à répétition
• laisser l’ancien et le nouveau site ouverts aux commandes
• passer les permissions de fichiers au réglage le plus ouvert pour « que ça marche »
• modifier wp-config.php sans conserver une copie de l’original

Le rechercher-remplacer simple est particulièrement risqué. Certaines données WordPress sont stockées dans un format sérialisé, qui enregistre la longueur de chaque texte. Modifier le texte sans mettre à jour la longueur peut casser les réglages des plugins, les widgets et les options du thème. Les outils conçus pour WordPress gèrent cela correctement.

Quand faut-il demander une assistance technique ?

Une assistance technique est recommandée lorsque :

• le site est une boutique en ligne, un site à abonnement ou un système de réservation
• des commandes ou des inscriptions ont pu être enregistrées sur l’ancien site après la copie
• l’import de la base de données a échoué ou vous n’êtes pas sûr qu’il soit complet
• le domaine a changé et des liens pointent encore vers l’ancien
• vous ne pouvez pas accéder au tableau de bord du nouveau site
• l’ancien site a déjà été supprimé
• vous ne disposez pas d’une sauvegarde vérifiée
• la migration a été faite par quelqu’un qui n’est plus disponible

Vous n’avez pas besoin de comprendre exactement où la migration a échoué. Une description de ce que vous voyez sur l’ancien et le nouveau site suffit pour commencer.

Quelles informations rassembler ?

Les éléments utiles sont notamment :

• l’ancien et le nouveau domaine, s’ils sont différents
• l’ancien et le nouvel hébergeur
• la méthode ou le plugin de migration utilisé
• la date et l’heure de la migration
• tout message d’erreur, avec des captures d’écran
• si le domaine a été dirigé vers le nouveau serveur
• si l’ancien site est toujours en ligne
• si de nouvelles commandes, de nouveaux utilisateurs ou du nouveau contenu ont été ajoutés après la copie
• où sont stockées les sauvegardes et quand elles ont été réalisées

N’envoyez pas de mots de passe ni d’identifiants d’hébergement par simple e-mail. D4Hub peut vous expliquer comment partager des accès en toute sécurité.

Comment D4Hub peut vous aider

L’objectif est de terminer le déménagement sans perdre de données et de s’assurer que le nouveau site fonctionne aussi bien que l’ancien.

Selon la situation, D4Hub peut vous aider à :

• vérifier si les fichiers et la base de données ont été copiés intégralement
• corriger les erreurs d’import de la base de données
• mettre à jour les anciennes adresses en toute sécurité, y compris dans les données sérialisées
• résoudre les problèmes de contenu mixte et de SSL
• vérifier les enregistrements DNS et planifier la bascule
• protéger les commandes et les inscriptions reçues sur l’ancien site pendant le déménagement
• corriger les permissions de fichiers et la configuration du serveur
• comparer l’ancien et le nouveau site page par page
• assurer la coordination avec l’ancien et le nouvel hébergeur
• tester les formulaires, la connexion, le checkout et les autres fonctions importantes
• décider à quel moment l’ancien site peut être retiré sans risque

Vous pouvez demander un accompagnement à n’importe quelle étape du processus.

Par exemple, D4Hub peut :

• examiner le plan avant une nouvelle tentative
• reprendre une migration arrêtée à mi-chemin
• réaliser l’intégralité du déménagement et des tests
• vérifier le nouveau site une fois que vous avez terminé

dig example.com A +short
dig www.example.com +short

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

wp option get siteurl
wp option get home

wp db export before-search-replace.sql

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

find wp-content -type f | wc -l

wp db tables --all-tables | wc -l

du -sh wp-content/uploads

wp db check

Questions fréquentes

Mon ancien site a-t-il disparu ?

Pas s’il n’a pas été supprimé. La plupart des migrations copient les données plutôt que de les déplacer : le site d’origine reste donc normalement sur l’ancien serveur jusqu’à ce que quelqu’un le supprime. Conservez-le jusqu’à ce que le nouveau site ait été entièrement vérifié.

Combien de temps dure la propagation DNS ?

Cela dépend des réglages DNS et de la durée pendant laquelle les résolveurs conservent les anciennes informations. Elle peut être rapide ou prendre plus de temps. Pendant cette période, certains visiteurs peuvent encore atteindre l’ancien serveur : planifiez la bascule en conséquence.

Puis-je simplement relancer la migration ?

Parfois, mais assurez-vous d’abord de comprendre pourquoi elle a échoué, et sauvegardez le nouveau site dans son état actuel. Relancer le même processus peut se heurter au même problème, ou écraser les modifications faites depuis la première tentative.

Des commandes sont arrivées sur l’ancien site après la migration. Que faire ?

Ne supprimez pas l’ancien site. Ces commandes n’existent que dans l’ancienne base de données et doivent être transférées ou consignées manuellement. C’est un travail délicat, surtout pour les boutiques avec gestion des stocks et abonnements, et c’est le bon moment pour demander de l’aide.

Pourquoi les images se chargent-elles encore depuis l’ancien domaine ?

Les adresses des images sont enregistrées dans le contenu et dans certains réglages. Si le domaine a changé, elles doivent être mises à jour avec un outil qui gère les données sérialisées de WordPress, comme wp search-replace. Elles fonctionnent peut-être en ce moment uniquement parce que l’ancien site est toujours en ligne.

D4Hub peut-il m’aider si la migration a été faite par quelqu’un d’autre ?

Oui. Partagez ce que vous savez de la manière dont la migration a été réalisée et ce que vous voyez maintenant. D4Hub peut examiner les deux sites et déterminer la façon la plus sûre de terminer le déménagement.