Ce que plus de 8 000 tickets de support WordPress révèlent sur les raisons pour lesquelles les migrations échouent
John Turner
John Turner
Lorsqu'une migration WordPress échoue, que se passe-t-il habituellement ? Nous avions les données pour y répondre, alors nous avons regardé.
Duplicator est un plugin de migration et de sauvegarde WordPress utilisé sur plus de 1,5 million de sites. Cette échelle produit quelque chose de spécifique et de rare : un enregistrement large et de première main de ce qui se passe lorsque les gens déplacent un site WordPress.
Au cours des dernières années, nous avons enregistré plus de 8 000 demandes de support structurées. Les problèmes de migration et de restauration constituent notre plus grande catégorie technique, et ces tickets sont ce que ce rapport analyse en profondeur, chacun étant étiqueté, catégorisé et décrit avec les mots du propriétaire du site.
Ce rapport présente ce que ces données révèlent. Certaines informations confirment le savoir conventionnel. Beaucoup d'autres ne le font pas.
Table des matières
- Principales conclusions
- Les migrations sont le plus grand problème technique signalé par les utilisateurs de WordPress
- Être la plus grande catégorie n'est pas la même chose qu'être la plus difficile
- Où les migrations échouent habituellement, et comment chacune est réparée
- L'étape d'installation ou d'extraction bloque
- Vous êtes bloqué hors de wp-admin après le transfert
- La barre de progression se fige à mi-migration
- Erreurs de permissions de fichiers ou de dossiers
- Incompatibilité de version PHP
- Erreur de connexion à la base de données
- Délai d'expiration PHP ou limite d'exécution maximale
- Erreur interne du serveur 500
- Le schéma d'hébergement : la catégorie prime sur la marque
- Comment se préparer aux échecs qui se produisent réellement
- Questions fréquemment posées (FAQ)
- Ce que plus de 8 000 tickets de support changent dans les conseils de migration
- Avant votre prochaine migration, prévoyez un moyen de revenir en arrière
Principales conclusions
Pour ceux qui veulent les chiffres avant l'analyse, voici ce que disent les données sur ce qui se passe mal lors des migrations WordPress. Chaque chiffre provient des propres enregistrements de support de Duplicator.
- Les problèmes de migration et de restauration constituent la plus grande catégorie de support technique. Sur plus de 8 000 demandes de support, environ 4 sur 10 sont techniques, et un peu moins d'un tiers d'entre elles concernent des migrations, plus que toute autre catégorie technique.
- Les migrations échouent rarement à l'étape du téléchargement. Elles échouent lors de l'extraction et à la première connexion sur le nouveau site.
- Le point de défaillance le plus courant est une limite d'hébergement qui se manifeste à l'étape d'extraction. Dans près d'un ticket de migration sur 5, un délai d'attente PHP ou une limite de mémoire sur le serveur de destination bloque le site pendant qu'il se décompresse.
- Être bloqué hors d'un site qui a migré avec succès est le deuxième problème le plus courant, dans près d'un ticket sur 10.
- Les limites d'hébergement sont la cause principale, mais elles ne s'annoncent que rarement. Seulement environ 1 ticket sur 50 mentionne directement un délai d'attente PHP, pourtant la limite PHP ou mémoire d'un hébergeur est à l'origine de la plupart des installations bloquées en haut de la liste.
- Les hébergeurs WordPress gérés sont presque absents de la file d'attente du support de migration. L'hébergement mutualisé à bas prix la domine.
- Environ 1 ticket de migration sur 14 concerne le déplacement d'un site depuis un environnement de développement local.
- Les problèmes de migration sont résolus rapidement. Environ 2 tickets de migration et de restauration sur 3 sont résolus en moins d'une heure.
Une mise en garde concernant tout cela, énoncée d'emblée car elle façonne la manière dont les données doivent être lues. Ce sont des tickets de support. Ils capturent les migrations qui ont rencontré des problèmes, pas les migrations dans leur ensemble.
Les nombreuses migrations qui se sont bien déroulées n'ont jamais généré de ticket. Ces données expliquent donc où les migrations échouent, pas à quelle fréquence elles échouent.
Les migrations sont le plus grand problème technique signalé par les utilisateurs de WordPress
Les tickets de support sont un instrument rudimentaire. Ils sont aussi honnêtes, car personne n'en dépose un lorsque tout va bien.
Nous avons regroupé chaque ticket technique par catégorie. Les problèmes de migration et de restauration sont arrivés en tête, devant les sauvegardes et le stockage cloud.
Lorsque les utilisateurs de WordPress rencontrent un problème technique suffisamment grave pour nous demander de l'aide, une migration est la raison la plus probable.
Cela correspond à la nature de la tâche. Une migration déplace tout en une seule fois : fichiers, bases de données, URL, paramètres du serveur, versions PHP et permissions.
Une seule incompatibilité peut faire échouer le transfert, et souvent plusieurs le font en même temps.
Être la plus grande catégorie n'est pas la même chose qu'être la plus difficile
Une catégorie en tête de la file de support peut sembler alarmante jusqu'à ce que vous regardiez comment ces tickets se clôturent. Le volume et la difficulté ne sont pas la même chose.
Les tickets de migration et de restauration sont les demandes techniques les plus courantes que nous recevons. Ils font également partie des plus rapides à résoudre.
La plupart des tickets de migration sont résolus le jour même, souvent en une seule réponse.
Cette combinaison, volume élevé et résolution rapide, vous dit quelque chose de spécifique sur les problèmes de migration. Ils sont courants, mais rarement mystérieux.
La plupart remontent à une courte liste de causes que l'équipe de support reconnaît à vue, ce qui est exactement la liste sur laquelle ce rapport est basé.
C'est aussi la raison honnête pour laquelle nous pouvons écrire cet article. Nous ne théorisons pas sur les raisons pour lesquelles les migrations échouent. Nous en avons résolu des milliers, la plupart en moins d'une heure.
Où les migrations échouent habituellement, et comment chacune est réparée
De nombreux propriétaires de sites blâment un délai d'expiration PHP, un pare-feu ou un espace disque pour les échecs de migration. Dans nos tickets, ce sont des personnages mineurs.
Ce qui se passe réellement est plus spécifique, et dans presque tous les cas, cela remonte à l'environnement de destination, pas au transfert lui-même.
Voici la répartition classée, avec ce qui se cache généralement derrière chaque élément et comment l'équipe de support le résout.
| Point de défaillance de la migration | Environ à quelle fréquence | Ce qui se cache généralement derrière | Comment cela est résolu |
|---|---|---|---|
| La limite de l'hébergeur bloque l'étape d'installation/extraction | 1 sur 5 | Un délai d'expiration PHP ou une limite de mémoire sur le serveur de destination interrompt le processus à mi-extraction | Augmenter les limites PHP, ou utiliser un installateur conçu pour extraire de grandes archives sans problème (DupArchive) |
| Bloqué hors de wp-admin après le transfert | 1 sur 10 | Une discordance d'URL du site dans la base de données ou une boucle de redirection, pas une migration défectueuse | Corriger les paramètres d'adresse WordPress et d'adresse du site ; vider le cache |
| La barre de progression se fige à mi-migration | Environ 1 sur 10 | Le serveur coupe une requête de longue durée | Augmentez les limites d'exécution ou exécutez la migration en mode segmenté |
| Erreurs de permission de fichier ou de dossier | Environ 1 sur 15 | Mauvaise propriété ou dossiers non inscriptibles sur la destination | Corrigez les permissions des dossiers sur le nouveau serveur |
| Incompatibilité de version PHP | Moins de 1 sur 30 | La source a été construite sur une version PHP plus récente que celle exécutée par la destination | Faites correspondre les versions PHP des deux côtés avant de migrer |
| Erreur de connexion à la base de données | Moins de 1 sur 40 | Identifiants de base de données incorrects dans le fichier wp-config.php | Corrigez les identifiants lors de l'installation |
| Dépassement de délai PHP nommé directement | Environ 1 sur 50 | La limite d'exécution de l'hébergeur est trop basse pour la taille du site | Augmentez la limite ou divisez le travail |
| Erreur interne du serveur 500 | Moins de 1 sur 60 | Généralement un fichier .htaccess obsolète ou un problème de permissions | Régénérez les permaliens et les permissions de fichiers |
L'étape d'installation ou d'extraction bloque
C'est l'échec de migration le plus courant que nous constatons, et c'est une limite d'hébergement déguisée. Les fichiers se téléchargent correctement, le processus démarre, puis il s'arrête à mi-chemin de l'extraction car le délai d'expiration PHP ou la limite de mémoire du serveur de destination interrompt le processus au moment du travail le plus intense.
La solution est plus de marge. Augmentez le max_execution_time et la memory_limit PHP sur le serveur de destination, puis réessayez.
Ces paramètres se trouvent dans le panneau de contrôle de votre hébergeur, généralement sous une section appelée Options PHP, Éditeur MultiPHP INI, ou quelque chose de similaire. Le support de votre hébergeur peut les augmenter si vous ne les trouvez pas.
Vous pouvez également utiliser un programme d'installation conçu pour extraire de grandes archives sans déclencher ces limites. Le programme d'installation autonome de Duplicator Pro et le format DupArchive visent exactement cela, et DupArchive a géré des migrations réelles allant jusqu'à 400 Go.

Vous êtes bloqué hors de wp-admin après le déménagement
C'est l'échec qui panique le plus les gens et dont ils ont le moins besoin. La migration se termine, vous essayez de vous connecter au nouveau site, et la connexion échoue ou lance une boucle de redirection.
Cela ne signifie presque jamais que le déménagement a échoué. Cela signifie qu'un paramètre d'URL est incorrect. L'URL du site stockée dans la base de données ne correspond pas à l'endroit où se trouve maintenant le site, de sorte que WordPress vous redirige continuellement vers un endroit qui n'existe plus.
Vérifiez les champs Adresse WordPress et Adresse du site sous Réglages » Général, corrigez-les avec la nouvelle URL et videz vos cookies.

Si vous ne pouvez pas du tout accéder au tableau de bord, vous pouvez définir temporairement les deux valeurs dans wp-config.php. Deux minutes de vérification, pas une re-migration.
La barre de progression se fige à mi-migration
Proche cousin de l'échec d'extraction, mais il apparaît sous la forme d'une barre de progression qui cesse de bouger et reste indéfiniment au même pourcentage.
La cause est généralement le serveur qui interrompt une requête de longue durée avant que l'étape ne puisse se terminer. Le travail est trop important pour le temps que l'hôte alloue à un seul processus pour s'exécuter.
Augmentez les limites d'exécution sur la destination, ou exécutez la migration dans un mode qui divise le travail en plus petits morceaux afin qu'aucune requête unique ne s'exécute assez longtemps pour être interrompue.
Dans Duplicator, vous définissez cela lors de la création de la sauvegarde. Changez le Mode SQL de la base de données en Code PHP et Multi-threadé.

Pour des ressources serveur limitées, nous conseillons souvent de régler le Limiteur de serveur sur Moyen ou Élevé dans les mêmes paramètres.

Erreurs de permissions de fichiers ou de dossiers
La migration signale qu'elle ne peut pas écrire un fichier ou créer un dossier sur le nouveau serveur, et le processus s'arrête.
Cela se résume à la propriété et aux droits d'écriture sur la destination. Si l'utilisateur du serveur web ne possède pas les dossiers cibles ou s'ils ne sont pas inscriptibles, vous ne pouvez pas déposer les fichiers là où ils doivent aller.
Définissez les dossiers de destination avec la propriété correcte pour votre hôte, et assurez-vous que les répertoires sont inscriptibles (typiquement 755 pour les dossiers et 644 pour les fichiers).
Vous modifiez cela via un client FTP ou le gestionnaire de fichiers de votre hôte, qui tous deux affichent une option de permissions ou CHMOD lorsque vous faites un clic droit sur un dossier. La documentation de votre hôte confirmera l'utilisateur du serveur web approprié si vous n'êtes pas sûr.
Incompatibilité de version PHP
Tout semble bien se passer jusqu'à ce que le site restauré commence à générer des erreurs sur les pages qui utilisent des fonctionnalités spécifiques d'un plugin ou d'un thème.
La cause habituelle est un écart de version PHP entre les environnements. Le site a été construit sur une version PHP plus récente que celle du serveur de destination, de sorte que les fonctions qui fonctionnaient sur l'ancien hôte sont obsolètes ou manquantes sur le nouveau.
Vérifiez la version PHP des deux côtés avant de migrer. Si elles sont différentes, mettez à jour le PHP du nouveau serveur ou mettez à jour le PHP de votre sauvegarde.
Vous trouverez cela dans le panneau de contrôle de votre hébergement, où la plupart des hôtes vous permettent de le changer en quelques clics.

Erreur de connexion à la base de données
Le nouveau site affiche le message « Erreur lors de l’établissement de la connexion à la base de données » au lieu de votre contenu.
Après une migration, il s'agit presque toujours de mauvais identifiants de base de données dans les fichiers de configuration, plutôt que d'une base de données corrompue. Le nom de la base de données, l'utilisateur ou le mot de passe dans wp-config.php ne correspond pas à ce que le nouvel hôte a réellement créé.
Confirmez le nom de la base de données, le nom d'utilisateur, le mot de passe et la valeur de l'hôte à partir de votre nouveau compte d'hébergement, puis mettez à jour wp-config.php pour qu'il corresponde.
Ce fichier se trouve dans le dossier racine de votre site, que vous pouvez atteindre via le gestionnaire de fichiers de votre hôte ou un client FTP. Si vous avez utilisé l'installateur de Duplicator, ces valeurs sont définies pendant l'étape d'installation, alors vérifiez bien ce qui a été saisi.

Délai d'expiration PHP ou limite d'exécution maximale
Moins courant comme plainte explicite, mais digne d'être nommé car c'est la cause cachée derrière plusieurs des échecs ci-dessus.
La limite d'exécution de l'hôte est trop basse pour la taille du site, de sorte qu'une étape longue est terminée avant qu'elle ne puisse s'achever.
Augmentez max_execution_time sur la destination, ou divisez la migration afin qu'aucune étape individuelle ne s'exécute trop longtemps pour atteindre le plafond. Sur un hébergement mutualisé très restrictif, demandez au support quelle est la limite stricte, car certains hébergeurs la limitent indépendamment de vos réglages.
Erreur interne du serveur 500
Le nouveau site renvoie une erreur générique 500 sans détail, ce qui donne l'impression qu'elle est pire qu'elle ne l'est habituellement.
Après une migration, le coupable est le plus souvent un fichier .htaccess obsolète ou un problème de permissions de fichiers, pas un site corrompu.
Régénérez vos permaliens en visitant Réglages » Permaliens et en enregistrant sans rien modifier. Cela réécrit votre fichier .htaccess.

Si cela ne résout pas le problème, vérifiez que vos permissions de fichiers sont correctes (dossiers 755, fichiers 644), car un problème de permissions génère la même erreur générique. Si vous pouvez accéder au journal d'erreurs de votre serveur, il peut indiquer la ligne exacte à l'origine de la 500.
Le schéma d'hébergement : la catégorie prime sur la marque
Nous avons également examiné les hébergeurs d'où provenaient ces tickets de migration. C'est la partie la plus facile à mal interpréter, nous allons donc y faire attention.
Le piège est simple. L'hébergeur qui génère le plus de tickets de migration est aussi l'un des plus utilisés.
Plus de sites produisent plus de tickets, même avec un taux d'échec parfaitement moyen. Le volume brut de tickets n'est pas un classement de qualité, et nous ne le présenterons pas comme tel.
Ce qui survit à cette mise en garde, c'est le schéma par catégorie, pas par marque :
- L'hébergement mutualisé économique remplit le haut de la file de migration, ce qui reflète en partie le nombre de sites WordPress qui y résident en premier lieu.
- Les hébergeurs WordPress gérés sont quasiment absents. Les principales plateformes gérées n'apparaissent que quelques fois chacune dans l'ensemble des données de migration.
- Les environnements Cloud et VPS se situent au milieu, avec leurs propres problèmes de configuration.
Il y a aussi un schéma qui mérite d'être souligné. Environ 1 ticket de migration sur 14 provient de personnes déplaçant un site d'un environnement de développement local, d'outils comme Local, XAMPP ou MAMP.
Passer d'un ordinateur portable à un serveur en ligne comporte ses propres modes d'échec, et cela se manifeste plus souvent que vous ne le pensez.
Nous n'affirmons pas que les hébergeurs gérés n'ont jamais de problèmes de migration. Mais le silence quasi total dans notre file d'attente de support correspond à ce que vous attendriez de configurations de serveur plus strictes et de versions PHP cohérentes : moins de surprises qui font dérailler un déménagement.
Comment se préparer aux échecs qui se produisent réellement
Parce que les données indiquent clairement deux points de défaillance, c'est là que la préparation doit se concentrer. Concentrez-vous sur ce que les tickets disent qui casse réellement.
- Faites correspondre les versions de PHP des deux côtés. Un site construit sur PHP 8.2 arrivant sur un serveur exécutant encore la version 7.4 générera des erreurs après le déménagement. Vous pouvez vérifier la version dans le panneau de contrôle de chaque hébergeur. Confirmez les deux avant de commencer.
- Assurez-vous que la destination peut terminer l'extraction. C'est le principal point de défaillance. Donnez-lui suffisamment d'espace disque, de mémoire PHP et un temps d'exécution qui ne coupe pas le processus en cours de route.
- Préparez les identifiants de connexion de votre nouveau site avant de migrer. Le deuxième échec le plus courant est un blocage post-migration. Connaissez vos identifiants administrateur et l'URL du nouveau site à l'avance.
- Vérifiez les permissions des fichiers sur la destination. Les propriétaires incorrects ou les dossiers non inscriptibles apparaissent assez souvent pour mériter un coup d'œil rapide. Un client FTP ou le gestionnaire de fichiers de votre hébergeur affichera les permissions d'un dossier lorsque vous cliquerez dessus avec le bouton droit.
C'est aussi là que l'outil de migration lui-même fait le gros du travail. L'installateur autonome de Duplicator Pro est conçu pour déplacer un site vers un serveur vierge, même un serveur sans WordPress installé. Cela élimine toute une catégorie de problèmes d'extraction.
Son format DupArchive n'a pas de limite théorique de taille de fichier et a géré des migrations réelles de 400 Go, de sorte que les grands sites ne s'étouffent pas à l'étape où la plupart des migrations stagnent.
Et lorsqu'un déménagement bloque quelqu'un, l'URL de récupération d'urgence peut restaurer un site fonctionnel même lorsque WordPress ne vous laisse pas accéder du tout.

Questions fréquemment posées (FAQ)
À quelle fréquence les migrations WordPress échouent-elles ?
Ces données ne peuvent pas répondre à cela, et aucun ensemble de données de support ne le peut. Les tickets de support ne capturent que les migrations qui ont rencontré des problèmes ; les réussites ne génèrent jamais de ticket. Ce que les données montrent, c'est que parmi les personnes qui demandent de l'aide pour la migration, les problèmes se concentrent étroitement autour de l'étape d'extraction et de la première connexion sur le nouveau site.
Quelle est l'erreur de migration WordPress la plus courante ?
Dans nos données de support, l'erreur la plus courante est une limite d'hébergement qui bloque la migration pendant l'étape d'installation ou d'extraction, présente dans près de 1 ticket de migration sur 5. Cela se produit lorsque le délai d'attente PHP ou la limite de mémoire du serveur de destination coupe le processus pendant que le site se décompresse. La deuxième cause la plus fréquente est l'impossibilité de se connecter au nouveau site après un déménagement par ailleurs réussi.
Les délais d'expiration PHP causent-ils la plupart des échecs de migration ?
Plus qu'il n'y paraît. Les propriétaires de sites mentionnent explicitement un délai d'attente PHP dans seulement environ 1 ticket sur 50, mais la limite PHP ou mémoire d'un hébergeur est la cause la plus fréquente derrière les installations bloquées qui dominent notre liste. La plupart des gens ne le reconnaissent pas, car cela se manifeste par le gel de l'installateur plutôt que par une erreur de délai d'attente nommée.
L'hébergement WordPress géré est-il meilleur pour les migrations ?
Les hébergeurs WordPress gérés apparaissent à peine dans notre file d'attente de support de migration, ce qui suggère moins de problèmes de migration sur ces plateformes. Les raisons probables sont des configurations de serveur et des versions PHP cohérentes. Ce n'est pas la preuve que l'hébergement géré est immunisé, mais le schéma est constant dans l'ensemble des données.
Pourquoi ne puis-je pas me connecter après avoir migré mon site WordPress ?
C'est l'un des problèmes post-migration les plus courants que nous rencontrons. Il s'agit généralement d'une discordance d'URL dans la base de données, d'une boucle de redirection ou d'un problème de permissions, et non d'une migration défectueuse. Vérifiez vos paramètres d'adresse WordPress et d'adresse du site et effacez vos cookies avant de supposer que le déménagement a échoué.
Ce que plus de 8 000 tickets de support changent dans les conseils de migration
La valeur de ces données n'est pas une statistique unique. C'est une correction quant à l'orientation à donner.
Les données continuent de pointer vers les mêmes deux moments : l'étape d'extraction et la première connexion. C'est là que les gens se retrouvent réellement bloqués, pas dans le transfert de fichiers dont la plupart des préparations se soucient.
Les gens se retrouvent souvent bloqués parce que le transfert a échoué à mi-chemin ou parce qu'une page de connexion les empêche de revenir.
Il y a une raison pour laquelle nous pouvons être aussi précis sur ce qui ne va pas. Ces problèmes arrivent constamment dans notre file d'attente de support, et la plupart d'entre eux sont résolus dans l'heure.
Lorsque vous résolvez des milliers de problèmes de migration, les schémas cessent d'être des suppositions et deviennent une carte. Ce rapport est cette carte.
Nous énoncerons la limite une dernière fois, car c'est ce qui maintient l'honnêteté. Ceci est un enregistrement des échecs, pas des succès. Il s'appuie sur les mots que les gens utilisent pour décrire leurs propres difficultés, ce qui est imparfait. Mais c'est réel, et c'est de première main.
Avant votre prochaine migration, prévoyez un moyen de revenir en arrière
La plupart des problèmes de migration sont rapides à résoudre une fois que vous connaissez la cause, et les données le confirment : la majorité des problèmes de migration que nous rencontrons sont résolus dans l'heure.
Le stress vient du fait de ne pas avoir de retour en arrière lorsque quelque chose bloque.
Duplicator Pro est utilisé par plus de 1,5 million de professionnels WordPress pour sauvegarder, migrer et récupérer leurs sites. Son programme d'installation autonome et ses outils de reprise après sinistre sont conçus pour les deux points de défaillance mis en évidence par ces données : l'étape d'extraction et le verrouillage de la connexion.
Pendant que vous êtes ici, je pense que vous trouverez ces autres ressources WordPress utiles :
- Votre migration de site va échouer (sauf si vous évitez ces erreurs)
- Migration DNS effectuée correctement : Comment éviter les erreurs les plus courantes
- Votre liste de contrôle complète pour la migration WordPress (du début à la fin)
- Comment migrer un site WordPress GRATUITEMENT
- Comment déplacer un site WordPress vers un nouvel hébergeur