Comment effectuer des migrations de base de données WordPress sans endommager votre site 

La migration d'une base de données WordPress semble simple : exporter la base, l'importer ailleurs, et le tour est joué. En pratique, c'est l'étape où la plupart des sites WordPress rencontrent des problèmes.

Les raisons sont précises. WordPress stocke des objets PHP sérialisés dans sa base de données. Une simple opération de recherche et de remplacement dans une URL altère silencieusement ces données sérialisées, ce qui rend votre site dysfonctionnel de manière difficile à identifier. Les mises à jour de plugins déclenchent des migrations de schéma de base de données qui ne peuvent être annulées par une restauration de fichier. Un préfixe de base de données incorrect, une table manquante ou un wp-config.php peuvent chacun générer une erreur différente, indiquant une cause différente.

Ce guide couvre tous les scénarios où vous devez effectuer une migration de base de données WordPress, comment procéder dans chacun d'eux sans perte de données et comment corriger les erreurs qui surviennent fréquemment en cas de problème.

Types de migrations de bases de données WordPress

Les migrations de bases de données ne sont pas toutes identiques. La méthode, les risques et la préparation varient selon le type de migration.

Déplacement de la base de données vers un nouvel hôte ou domaine

Voici le scénario le plus courant : vous changez d’hébergeur, vous passez de HTTP à HTTPS ou vous effectuez un changement de nom de domaine. Le contenu de la base de données est intact, mais toutes les URL qui y sont stockées doivent être mises à jour pour refléter la nouvelle adresse.

Le problème : WordPress stocke les URL à plusieurs endroits dans la base de données, notamment sous forme de tableaux sérialisés dans les tables wp_options et wp_postmeta. Une opération de recherche et de remplacement manuelle dans ces tables, sans tenir compte de la sérialisation, corrompra silencieusement les données.

Passage de la phase de préparation à la production

Lorsqu'un site est déployé en production après sa création en environnement de test, la base de données doit être transférée avec lui et toutes les URL de test doivent être remplacées par les URL de production. C'est l'une des causes les plus fréquentes de problèmes lors de la migration de test vers la production, car les développeurs transfèrent souvent un fichier sans mettre à jour la base de données.

Migrations de schéma déclenchées par plugin

Lorsqu'un plugin modifie la structure de la base de données lors d'une mise à jour, il effectue une migration de schéma : une modification de la structure de la base de données et non seulement des données qu'elle contient. La migration HPOS (High-Performance Order Storage) de WooCommerce en est un exemple actuel. Les plugins de gestion des membres qui déplacent les données des membres vers de nouvelles structures de tables en sont un autre.

Ces migrations s'exécutent dans le cadre du processus de mise à jour du plugin. Vous ne pouvez pas les déclencher manuellement. C'est pourquoi une préparation en environnement de test est nécessaire avant l'application de la mise à jour en production.

  

De quoi avez-vous besoin avant toute migration de base de données ?

Complétez tous les éléments de cette liste avant d'exécuter une seule commande ou de cliquer sur Exporter.

Sauvegarde complète de la base de données. Exportez l'intégralité de votre base de données MySQL depuis votre environnement actuel à l'aide de phpMyAdmin, WP-CLI ou de l'outil de sauvegarde de votre hébergeur. Avant de poursuivre, vérifiez que le fichier de sauvegarde s'ouvre et contient des données. Un fichier d'exportation corrompu, découvert après l'écrasement de la base de données d'origine, est irrécupérable sans une sauvegarde effectuée par votre hébergeur.

Sauvegarde complète des fichiers. Votre base de données ne peut pas fonctionner sans les fichiers WordPress correspondants. Sauvegardez l'intégralité de votre installation WordPress en même temps que votre base de données.

Le fichier wp-config.php contient les informations nécessaires pour la destination. Notez le nom de la base de données, le nom d'utilisateur, le mot de passe et l'hôte de l'environnement de destination. Ces informations sont indispensables pour connecter vos fichiers WordPress à la base de données importée.

Un environnement de test. Toute migration de base de données doit être testée en environnement de test avant d'être déployée en production. Ceci s'applique aussi bien aux migrations entre serveurs qu'aux migrations de schéma liées aux mises à jour de plugins.

Compatibilité PHP confirmée. Si vous migrez vers un nouvel hébergeur utilisant une version PHP différente, vérifiez la compatibilité de vos plugins et thèmes avec cette nouvelle version avant la migration. Les incompatibilités de versions PHP après la migration génèrent des erreurs qui semblent être des problèmes de base de données, mais qui sont en réalité des problèmes de compatibilité.

Comment migrer une base de données WordPress : 3 méthodes

La méthode appropriée dépend de votre niveau de maîtrise technique et de la taille de votre base de données. Les trois méthodes gèrent correctement les données sérialisées lorsqu'elles sont utilisées comme décrit ci-dessous.

Méthode 1 : Plugin de migration (la plus simple)

Les plugins de migration gèrent l'exportation, l'importation, le transfert de fichiers et le remplacement d'URL en une seule opération. Ils constituent la solution idéale pour la plupart des propriétaires de sites web n'ayant aucune connaissance de la ligne de commande.

Plugins recommandés :

Duplicator Pro gère des bases de données jusqu'à plusieurs gigaoctets, prend en charge les migrations planifiées et génère un fichier d'installation qui gère automatiquement le remplacement des URL. C'est la solution la plus fiable pour les sites volumineux ou complexes.

All-in-One WP Migration crée une archive unique contenant l'intégralité de votre installation WordPress, base de données comprise. La version gratuite est limitée à 512 Mo. La version premium supprime cette limite. L'extension gère le remplacement des données sérialisées lors de l'importation.

WP Migrate (anciennement WP Migrate DB) est spécialement conçu pour les migrations de bases de données uniquement et les transferts entre environnements (push/pull). Il gère correctement les données sérialisées et prend en charge la migration sélective de tables, ce qui est utile pour transférer uniquement la base de données de contenu de l'environnement de production vers l'environnement de test sans écraser les paramètres de vos plugins de test.

Migration WordPress tout-en-un étape par étape :

• Installez et activez All-in-One WP Migration sur votre site source

• Accédez à Migration WordPress tout-en-un > Exporter

• Sélectionnez Exporter vers > Fichier

• Attendez que l'exportation soit terminée et téléchargez le fichier .wpress

• Installez All-in-One WP Migration sur votre site de destination

• Accédez à Migration WordPress tout-en-un > Importer

• Glissez-déposez le fichier .wpress ou cliquez pour le rechercher

• Confirmez l'importation lorsque vous y êtes invité. Le plugin vous avertit que cela écrasera tout le contenu existant

• Une fois l'importation terminée, accédez à Paramètres > Permaliens et cliquez sur Enregistrer les modifications sans rien modifier. Cela efface les règles de réécriture et résout la plupart des erreurs 404 qui apparaissent après la migration

Méthode 2 : phpMyAdmin (Manuel)

phpMyAdmin est la méthode appropriée lorsque vous avez besoin d'un contrôle total sur la migration, lorsque vous migrez une base de données volumineuse que les outils de plugins ne peuvent pas gérer, ou lorsque vous devez migrer une base de données indépendamment des fichiers WordPress.

Exportation de la base de données :

• Connectez-vous à phpMyAdmin sur votre environnement d'hébergement source via votre panneau de contrôle d'hébergement

• Sélectionnez votre base de données WordPress dans la barre latérale gauche

• Cliquez sur l'onglet Exporter

• Sélectionnez la méthode d'exportation personnalisée

• Assurez-vous que toutes les tables sont sélectionnées

• Dans les options spécifiques au format, cochez la case Ajouter l'instruction DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER. Cela garantit que l'importation écrase correctement les tables existantes, plutôt que de provoquer des erreurs de saisie en double

• Dans les options de création de données, cochez Insertions complètes et Insertions étendues

• Cliquez sur Exporter et enregistrez le fichier .sql

Importation de la base de données :

• Connectez-vous à phpMyAdmin sur votre environnement d'hébergement de destination

• Sélectionnez ou créez la base de données de destination

• Cliquez sur le tableau Importer

• Cliquez sur Choisir un fichier et sélectionnez votre fichier .sql

• Cliquez sur « Exécuter » pour lancer l'importation

Mise à jour des URL :

Après l'importation, vous devez mettre à jour l'URL du site enregistrée dans la base de données. La méthode la plus simple pour les utilisateurs non techniques consiste à exécuter les requêtes SQL suivantes dans l'onglet SQL de phpMyAdmin, en remplaçant old-domain.com et new-domain.com par vos noms de domaine :

UPDATE wp_options SET option_value = replace(option_value, 'https://old-domain.com', 'https://new-domain.com') WHERE option_name = 'siteurl' OR option_name = 'home';

N’effectuez pas de remplacement complet dans toutes les tables en utilisant uniquement SQL. Cela corrompra les données sérialisées. Utilisez la méthode WP-CLI ci-dessous pour un remplacement complet.

Méthode 3 : WP-CLI (la plus fiable pour les utilisateurs techniques)

WP-CLI est l'interface en ligne de commande de WordPress. Sa commande de recherche et de remplacement est la méthode la plus fiable pour remplacer les URL dans une base de données WordPress, car elle gère correctement les données sérialisées par défaut.

Prérequis : accès SSH à votre serveur et WP-CLI installé. La plupart des hébergeurs WordPress gérés (Kinsta, WP Engine, Cloudways) proposent WP-CLI par défaut.

Exporter la base de données :

wp db export backup-$(date +%Y%m%d).sql

Cette opération exporte la base de données complète vers un fichier .sql daté dans votre répertoire actuel.

Importez la base de données dans le répertoire de destination :

wp db import backup-20260101.sql

Remplacez backup-20260101.sql par le nom de votre fichier réel.

Exécutez le remplacement d'URL :

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables

L'option `--precise` garantit le traitement correct des données sérialisées. L'option `--all-tables` applique le remplacement à toutes les tables de la base de données, y compris celles créées par les extensions.

Vérifiez le remplacement :

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

L'option `--dry-run` permet de visualiser le nombre de remplacements qui seraient effectués sans les réaliser réellement. Lancez-la d'abord pour vérifier que le résultat est correct avant de procéder au remplacement réel.

Vider le cache et réécrire les règles :

vider le cache wp

wp rewrite flush

Comment gérer les données sérialisées lors d'une migration ?

Il s'agit de la partie la plus mal comprise de la migration de bases de données WordPress et de la cause la plus fréquente de dysfonctionnements après la migration.

Pourquoi la simple fonction Rechercher/Remplacer perturbe-t-elle WordPress ?

WordPress stocke certaines données au format PHP sérialisé. Une chaîne sérialisée ressemble à ceci :

a:2:{s:4:"home";s:22:"https://old-domain.com";}

L'indication « s:22 » signifie « chaîne de 22 caractères ». Si vous effectuez une recherche et un remplacement pour remplacer old-domain.com par new-domain.com, la longueur de la chaîne change, mais le nombre de caractères « s:22 » reste inchangé. WordPress tente de lire une chaîne de 22 caractères, en trouve une de longueur différente et génère une erreur.

L'erreur se manifeste souvent par un écran blanc, des zones de widgets défectueuses ou des paramètres de plugins vides après la migration. Il est difficile de la diagnostiquer sans connaître les données sérialisées.

Comment effectuer une recherche-remplacement sécurisée ?

Utilisez l'une de ces méthodes prenant en charge la sérialisation :

WP-CLI (recommandé) :

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables

Extension Better Search Replace : Installez l’ extension Better Search Replace sur WordPress. Elle gère les données sérialisées par défaut et propose une fonction de test pour prévisualiser les modifications avant leur application. C’est la solution idéale si vous n’avez pas accès à WP-CLI.

Interconnect/it Search Replace DB : un script PHP à téléverser à la racine de votre serveur, à exécuter via un navigateur, puis à supprimer après utilisation. Il gère les données sérialisées et prend en charge les modes de fonctionnement réel et simulé.

Comment vérifier que la fonction Rechercher-Remplacer a fonctionné ?

Après avoir effectué le remplacement, vérifiez les emplacements suivants :

• Accédez à Réglages > Général dans votre tableau de bord WordPress. Vérifiez que l'adresse WordPress et l'adresse du site affichent bien votre nouveau domaine

• Accédez à l'interface publique de votre site et vérifiez la console de développement du navigateur pour détecter les avertissements de contenu mixte (ressources HTTP chargées sur un domaine HTTPS)

• Vérifiez votre médiathèque : cliquer sur une image affiche-t-il l’URL correcte ?

• Lancez une analyse avec Screaming Frog ou utilisez Broken Link Checker pour rechercher les URL de l'ancien domaine restantes.

Migrations de base de données déclenchées par des plugins dans WordPress

Contrairement aux migrations d'un hôte à l'autre, ces opérations ne sont pas déclenchées manuellement. Elles s'exécutent automatiquement lors de la mise à jour des plugins, ce qui explique pourquoi la préparation de l'environnement de test est ici primordiale.

Comment fonctionnent les migrations de base de données WooCommerce ?

WooCommerce a introduit HPOS (High-Performance Order Storage) comme une modification structurelle majeure de la façon dont les commandes sont stockées. Lors de la migration vers HPOS, WooCommerce crée de nouvelles tables de commandes dédiées et y transfère toutes les données historiques des commandes.

Cette migration s'exécute automatiquement lorsque vous activez HPOS dans les paramètres WooCommerce ou lorsque vous mettez à jour WooCommerce sur un site dont la migration est en cours. Elle est irréversible. Si la migration s'exécute sur un site où certains plugins ne sont pas compatibles avec HPOS, ces plugins cesseront de fonctionner correctement.

Préparation : Avant d’activer HPOS ou de mettre à jour WooCommerce vers une version majeure, exécutez l’outil de vérification de compatibilité de WooCommerce en accédant à WooCommerce > État > HPOS. Il répertorie tous les plugins installés et indique s’ils sont compatibles avec HPOS. Résolvez les incompatibilités avant la migration.

Comment fonctionnent les migrations de plugins d'adhésion ?

Les extensions de gestion des adhésions, telles que MemberPress, Paid Memberships Proet Restrict Content Pro, créent leurs propres tables de base de données personnalisées pour les fiches des membres, les données d'abonnement et l'historique des transactions. Lors des mises à jour majeures de ces extensions, la structure de ces tables peut parfois être modifiée.

Les données d'adhésion étant stockées dans des tables personnalisées et non dans les tables standard de WordPress, les extensions de migration peuvent ne pas toujours les inclure par défaut dans leurs exportations. Avant de migrer un site d'adhésion, vérifiez explicitement que votre outil de sauvegarde prend bien en charge les tables personnalisées des extensions.

Comment se préparer avant qu'un plugin ne déclenche une migration ?

• Mettez en place un environnement de test qui reflète exactement votre base de données de production.

• Appliquez d'abord la mise à jour du plugin sur l'environnement de test

• Vérifiez toutes les fonctionnalités affectées (paiement, connexion des membres, gestion des abonnements) sur l'environnement de test après la mise à jour

• Si la phase de test réussit, appliquez la même mise à jour en production pendant une période de faible trafic

• Conservez une sauvegarde vérifiée datant d'immédiatement avant la mise à jour de production

Liste de contrôle de la base de données post-migration

Après une migration de base de données, vérifiez chaque élément avant d'annoncer à quiconque que la migration est terminée.

• L'interface d'administration WordPress se charge sans erreur à la nouvelle URL

• La partie publique du site se charge correctement à la nouvelle URL

• Tous les fichiers multimédias se chargent correctement (aucune image cassée)

• Les formulaires de contact sont soumis et des e-mails de confirmation sont envoyés

• La connexion utilisateur fonctionne pour tous les types de comptes

• Si WooCommerce : effectuez un test de paiement de bout en bout

• Si vous êtes sur un site réservé aux membres : connectez-vous en tant que membre et vérifiez votre accès au contenu

• Google Search Console n'affiche aucune erreur de couverture d'index après la nouvelle soumission du sitemap

• Aucune alerte de contenu mixte (ressources HTTP sur un site HTTPS) dans la console du navigateur

• Aucune ancienne URL de domaine n'est visible dans le code source de la page ni dans l'onglet Réseau du navigateur

• Cache du plugin en cache effacé

• Structure des liens permanents mise à jour : Paramètres > Liens permanents > Enregistrer les modifications

Erreurs courantes de migration de base de données WordPress et comment les corriger

Ne tentez pas de relancer la migration avant d'avoir identifié l'erreur. Chaque erreur ci-dessous vous indique précisément ce qui s'est mal passé et ce qu'il faut modifier avant de réessayer.

Erreur 1062 : Entrée dupliquée pour la clé PRIMARY

Cette erreur se produit lors de l'importation d'une base de données dans un répertoire de destination contenant déjà des données. Le script d'importation tente d'insérer une ligne avec un identifiant déjà existant.

Correction : Avant l’importation, supprimez toutes les tables existantes dans la base de données de destination ou assurez-vous que votre fichier d’exportation inclut des instructions DROP TABLE. Dans phpMyAdmin, lors de l’exportation, cochez l’option permettant d’inclure les instructions DROP TABLE. Dans WP-CLI : exécutez `wp db reset --yes`, puis `wp db import backup.sql`.

Erreur 2002 : Impossible de se connecter au serveur MySQL

Cette erreur indique que WordPress ne parvient pas à se connecter au serveur de base de données. Elle survient généralement après une migration, lorsque le nom d'hôte de la base de données dans wp-config.php ne correspond pas au nom d'hôte réel sur le nouveau serveur.

Solution : Ouvrez le fichier wp-config.php et vérifiez la valeur de DB_HOST. Sur la plupart des hébergements mutualisés, il s’agit de localhost. Sur les hébergements WordPress gérés, il peut s’agir d’un nom d’hôte spécifique indiqué dans votre tableau de bord d’hébergement. Mettez à jour la valeur de DB_HOST pour qu’elle corresponde au nom d’hôte MySQL de votre serveur de destination.

Erreur 1045 : Accès refusé à l’utilisateur

Cette erreur signifie que le nom d'utilisateur ou le mot de passe de la base de données dans wp-config.php ne correspond pas aux identifiants de la base de données sur le serveur de destination.

Solution : Ouvrez le fichier wp-config.php et vérifiez que les valeurs de DB_USER et DB_PASSWORD correspondent aux identifiants de l’utilisateur de la base de données sur votre serveur de destination. Dans cPanel, accédez à la section « Bases de données MySQL » et assurez-vous que l’utilisateur est bien associé à la base de données appropriée et dispose de tous les privilèges.

Dernières réflexions sur les migrations de bases de données WordPress

Les migrations de bases de données WordPress échouent le plus souvent pour deux raisons : les données sérialisées qu’une simple opération de recherche et de remplacement corrompt silencieusement, et les migrations de schéma déclenchées par des plugins qui s’exécutent automatiquement lors des mises à jour sur des sites non préparés.

Ces deux problèmes ont des solutions claires. Utilisez WP-CLI ou un outil de recherche et remplacement prenant en charge la sérialisation plutôt que la fonction de recherche et remplacement SQL. Préparez un environnement de test avant d'appliquer les mises à jour de plugins qui déclenchent des migrations de schéma. Effectuez une sauvegarde vérifiée avant chaque étape de migration et testez-la avant de vous y fier.

Les trois méthodes de migration présentées ci-dessus conviennent à tous les niveaux de compétence : les plugins pour ceux qui souhaitent une procédure guidée, phpMyAdmin pour ceux qui ont besoin d’un contrôle précis et WP-CLI pour ceux qui ont accès à la ligne de commande. Choisissez la méthode la plus adaptée à votre environnement et suivez la liste de vérification post-migration avant de clôturer le projet.

Si vous avez besoin d'une migration de base de données WordPress gérée par une équipe expérimentée, Seahawk a géré des migrations pour des centaines de sites WordPress de tous niveaux de complexité.

Questions fréquentes sur les migrations de bases de données WordPress