À mesure qu'un site web se développe, les limites de la plateforme sur laquelle il a été construit commencent à se faire sentir. De nombreux projets institutionnels lancés sur WordPress inscrivent un passage à Drupal à l'ordre du jour dès que des besoins tels que des structures multilingues, des permissions granulaires, des intégrations d'entreprise et des exigences multisite entrent en jeu. À ce stade, la vraie question n'est généralement plus « devons-nous migrer ? » mais « comment déplacer des années de contenu, d'utilisateurs et de médias sans rien perdre ? »
La réponse se trouve dans le noyau de Drupal : l'API Migrate. Elle lit les données provenant de sources externes, les transforme, et les convertit en entités Drupal grâce à un framework de migration à la fois réversible et reproductible. Ce guide explique pourquoi les organisations migrent de WordPress vers Drupal, comment fonctionne l'API Migrate, quels modules sont impliqués, les trois méthodes de migration disponibles, le processus étape par étape, et comment préserver intact votre référencement (SEO) pendant la transition.
Pourquoi migrer de WordPress vers Drupal ?
WordPress offre un démarrage rapide et pratique pour les sites petits et moyens, ce qui explique précisément pourquoi c'est le CMS le plus utilisé au monde. Cependant, une fois qu'un projet atteint une échelle institutionnelle, certaines limites structurelles ont tendance à déclencher la décision de migrer.
- Lorsque l'architecture de contenu devient complexe : lorsque vous avez besoin de dizaines de types de contenu, de structures de champs et de relations entre contenus, l'architecture de contenu structurée de Drupal offre un avantage net.
- Lorsque vous avez besoin d'une structure multilingue : le noyau de Drupal prend en charge plus de 110 langues sans aucun module complémentaire ; sur WordPress, le contenu multilingue ne peut être géré que via des extensions tierces.
- Lorsque les permissions doivent être granulaires : des structures de rôles à plusieurs niveaux — éditeur de faculté, responsable de département, valideur de contenu — sont définies au niveau du noyau dans Drupal.
- Lorsque le multisite est l'objectif : regrouper des installations WordPress éparpillées sous une seule structure multisite Drupal réduit considérablement la charge de maintenance et les risques de sécurité.
- Lorsque la sécurité et l'intégration sont des priorités : un noyau auditable plutôt qu'un risque de sécurité lié aux extensions, ainsi qu'une intégration basée sur des API avec des systèmes d'entreprise tels que les systèmes d'information étudiants, les CRM et LDAP/CAS.
Nous avons détaillé cette comparaison dans notre article Drupal vs WordPress vs Joomla : comment choisir le bon CMS. Une fois la décision de migrer prise, la question suivante est de savoir comment la gérer techniquement.
Qu'est-ce que l'API Drupal Migrate ?
L'API Migrate est le framework de migration intégré au noyau de Drupal, qui convertit des données provenant de sources externes en entités Drupal — nœuds (nodes), utilisateurs, taxonomie, médias, commentaires. Elle n'est pas spécifique à WordPress : la même infrastructure gère la migration de contenu depuis d'anciennes versions de Drupal, depuis des fichiers CSV, JSON ou XML, ou depuis n'importe quelle autre base de données.
Trois caractéristiques distinguent l'API Migrate d'un simple outil d'import. Premièrement, les migrations sont définies dans des fichiers de configuration (YAML), ce qui rend le processus documentable et reproductible. Deuxièmement, chaque migration est réversible : lorsqu'un problème survient, une commande de retour en arrière (rollback) retire proprement le contenu importé afin qu'il puisse être relancé avec des correspondances corrigées. Troisièmement, les données peuvent être transformées pendant la migration — les shortcodes WordPress peuvent être supprimés, les formats de date corrigés, les comptes d'auteurs mappés.
Source – Traitement – Destination : un modèle ETL en trois étapes
L'API Migrate applique le modèle connu en ingénierie logicielle sous le nom d'ETL (Extraction – Transformation – Chargement), en définissant chaque migration selon trois couches.
- Source : l'endroit d'où les données sont lues. Dans un scénario WordPress, il s'agit soit d'un fichier d'export WXR, soit de la base de données WordPress elle-même.
- Traitement (Process) : la transformation des données source dans le format attendu par Drupal. Les correspondances de champs, les conversions de format et le nettoyage des données ont lieu à cette étape.
- Destination : l'entité Drupal dans laquelle les données transformées sont enregistrées — le contenu devient des nœuds, les catégories deviennent des termes de taxonomie, les auteurs deviennent des comptes utilisateurs.
La signification pratique de cette architecture est simple : une migration n'est pas une opération risquée de copier-coller réalisée en une seule fois, mais un processus d'ingénierie contrôlé qui peut être testé, annulé, et mené par étapes.
Les modules essentiels utilisés lors d'une migration
La migration de WordPress vers Drupal ne repose pas sur un seul module, mais sur un ensemble de modules qui fonctionnent ensemble.
| Module | Ce qu'il fait | Où il se trouve |
|---|---|---|
| Migrate | L'API qui constitue le socle du framework de migration. | Noyau de Drupal |
| Migrate Plus | Étend les définitions de migration ; ajoute la gestion de groupes et des plugins de source supplémentaires. | Module contribué |
| Migrate Tools | Fournit des commandes Drush pour exécuter les migrations, surveiller leur statut et effectuer des retours en arrière. | Module contribué |
| WordPress Migrate | Lit les fichiers WXR (XML) et mappe les articles, pages, commentaires, étiquettes et catégories vers des entités Drupal. | Module contribué |
| Pathauto + Redirect | Génère les nouvelles URL et redirige en 301 les anciennes URL WordPress. | Modules contribués |
Le module WordPress Migrate déplace les exports WordPress au format WXR vers Drupal via l'API Migrate intégrée au noyau ; il prend en charge les articles, pages, commentaires, pièces jointes, étiquettes et catégories, et ses migrations sont entièrement réversibles. Les versions actuelles sont développées pour être compatibles avec Drupal 10 et 11 ; il est donc important de sélectionner la version correspondant à votre version cible de Drupal avant l'installation.
Trois façons de migrer de WordPress vers Drupal
Tous les projets ne migrent pas de la même manière. La taille du site, la possibilité d'accéder à la base de données WordPress, et le type d'installation Drupal ciblée déterminent tous la voie à privilégier.
Migrer avec un fichier d'export WXR (XML)
C'est la méthode la plus courante et la plus accessible. En utilisant Outils → Exporter dans l'administration WordPress, l'intégralité du contenu du site est téléchargée sous forme de fichier XML appelé WXR ; le module WordPress Migrate lit ensuite ce fichier et importe le contenu dans Drupal. Comme elle ne nécessite aucun accès à la base de données, c'est la solution idéale pour les projets soumis à des restrictions d'hébergement ou hébergés sur des serveurs distincts. Sur les sites petits et moyens, le processus se déroule rapidement, bien que le fichier XML puisse devenir difficile à gérer lorsque les archives média sont très volumineuses.
Migrer via une connexion directe à la base de données
La méthode la plus performante sur les grands sites consiste à faire en sorte que Drupal se connecte directement à la base de données WordPress et lise les données en direct. Dans cette approche, les utilisateurs, articles, pages, catégories, étiquettes, médias et commentaires sont lus directement depuis la base de données MySQL de WordPress et convertis en leurs équivalents Drupal sans aucun export XML intermédiaire — et sur les grands sites, cette méthode est plus rapide qu'un import basé sur des fichiers. Le prérequis est un accès sécurisé à la base de données WordPress pendant toute la durée de la migration.
La recette WordPress Migrate pour Drupal CMS
La distribution Drupal CMS, sortie en 2025, a radicalement simplifié l'installation grâce à son architecture de recettes (Recipes). Pour les projets fonctionnant sous Drupal CMS, la WordPress Migrate Recipe regroupe les modules et la configuration nécessaires à une migration dans un ensemble prêt à l'emploi. En réduisant le besoin d'une équipe technique pour les petits projets à démarrage rapide, cette option contribue également à atténuer la réputation de Drupal jugé « difficile à configurer » dans les scénarios de migration.
Le processus de migration de WordPress vers Drupal, étape par étape
Un projet de migration professionnel commence bien avant que quiconque n'appuie sur un bouton d'import. Le cadre ci-dessous propose une feuille de route adaptée à l'échelle institutionnelle.
- Réaliser un inventaire du contenu. Combien d'articles, de pages, de catégories, d'utilisateurs et de fichiers média existe-t-il ? Lesquels seront transférés, et lesquels seront archivés ? Une migration est aussi le meilleur moment possible pour faire le ménage dans le contenu.
- Effectuer une sauvegarde complète. Avant la migration, réalisez une sauvegarde complète de la base de données WordPress, des fichiers média et de la configuration des thèmes/extensions. Pour la méthodologie détaillée de cette étape, consultez notre guide sur les stratégies de sauvegarde et de reprise après sinistre pour Drupal.
- Concevoir l'architecture Drupal cible. Les types de contenu, les champs, les taxonomies et les rôles doivent être construits autour des besoins réels de l'organisation — et non comme une copie conforme de la configuration WordPress.
- Installer les modules de migration et définir la correspondance. Migrate Plus, Migrate Tools et WordPress Migrate sont installés, et les correspondances source-destination sont configurées.
- Exécuter une migration test en environnement de préproduction. La première migration n'est jamais exécutée directement sur le site en production. Dans l'environnement de préproduction, l'intégrité du contenu, les images, les correspondances d'auteurs et l'encodage des caractères sont chacun vérifiés individuellement.
- Corriger, annuler, répéter. Grâce à la capacité de retour en arrière de l'API Migrate, les erreurs de correspondance peuvent être corrigées sans aucun coût.
- Mettre en place les redirections d'URL. Les anciennes URL WordPress sont associées à leurs nouvelles adresses via des redirections 301, à l'aide du module Redirect.
- Mettre en ligne et surveiller. Le delta final de contenu est importé et le DNS est basculé ; pendant les premières semaines, les rapports d'erreurs 404 et la Search Console sont surveillés de près.
Correspondance des contenus : concepts WordPress et leurs équivalents Drupal
Ce avec quoi les équipes ont le plus de mal dans les projets de migration, ce ne sont pas les commandes techniques, mais la traduction entre les vocabulaires conceptuels des deux plateformes. Le tableau ci-dessous résume cette correspondance.
| WordPress | Équivalent Drupal | Remarque |
|---|---|---|
| Post | Nœud (type de contenu Article) | Les types d'articles personnalisés sont mappés vers des types de contenu distincts. |
| Page | Nœud (type de contenu Basic Page) | La hiérarchie est construite via les menus et Pathauto. |
| Catégorie / Étiquette | Taxonomie (vocabulaire + terme) | La taxonomie de Drupal prend en charge des relations bien plus flexibles. |
| Champ personnalisé (ACF) | Champs de l'API Field | Les types de champs sont mappés de manière fonctionnelle plutôt que biunivoque. |
| Bibliothèque de médias | Entités média | Les images deviennent des éléments média réutilisables. |
| Utilisateur / Auteur | Comptes utilisateurs et rôles | Les rôles sont repensés autour du modèle de permissions granulaires de Drupal. |
| Extension (Plugin) | Module | Les extensions ne sont pas transférées ; l'équivalent Drupal de la fonction est reconstruit. |
| Thème | Thème | Les thèmes ne sont pas transférés ; le design est reconstruit dans la couche de thème de Drupal. |
Les deux dernières lignes sont les plus déterminantes : les extensions et thèmes WordPress ne « migrent » pas vers Drupal. Ce qui migre, c'est le contenu. Les fonctionnalités et le design sont reconstruits avec les outils propres à l'écosystème Drupal — généralement sur des bases plus solides.
Migrer sans perdre son référencement : URL, redirections et métadonnées
La plus grande inquiétude des organisations lors d'un changement de CMS est de perdre le trafic organique accumulé au fil des années. Cette préoccupation est légitime, mais elle est gérable : dans une migration bien planifiée, toute perte de positionnement est temporaire et minime.
- Construire une carte des URL. Avant la migration, exportez la liste complète des URL WordPress et définissez l'équivalent Drupal de chacune dans un tableau de correspondance.
- Mettre en place des redirections 301. Le module Redirect pointe de façon permanente les anciennes URL vers leurs nouvelles adresses, préservant ainsi la valeur des backlinks accumulée au fil des années sur des sites externes.
- Transférer les métadonnées. Les titres et descriptions méta produits avec Yoast ou Rank Math sont transférés vers le module Metatag côté Drupal.
- Actualiser le plan de site. Le nouveau plan de site généré par Simple XML Sitemap est soumis à Google Search Console, et l'ancien est supprimé.
- Surveiller les quatre à six premières semaines. Surveillez régulièrement les erreurs 404, les statistiques d'exploration et les mouvements de positionnement, et ajoutez rapidement toute redirection manquante.
Nous avons traité en détail le niveau des modules pour cette couche dans notre article SEO Drupal : ce qu'il faut savoir pour la visibilité dans les moteurs de recherche.
Migration de WordPress vers Drupal pour les universités : qu'est-ce qui change ?
Dans les établissements d'enseignement, une migration est une transformation bien plus vaste que le déplacement d'un seul site. Le scénario typique ressemble à ceci : au fil des années, des dizaines de sites WordPress indépendants ont été créés pour les facultés, les centres de recherche et les événements — chacun sur une version différente, avec des extensions différentes et des postures de sécurité différentes. Le projet de migration est l'occasion de regrouper cette dispersion sous une seule structure multisite Drupal.
Les principales différences à prendre en compte dans ce scénario sont :
- Un plan de consolidation : quels sites WordPress resteront des sous-sites indépendants, et lesquels deviendront des sections du site principal ? Cette décision doit précéder la carte de migration.
- Migration du contenu multilingue : les paires de langues gérées par des extensions côté WordPress doivent être correctement mappées vers le système de traduction intégré au noyau de Drupal ; sinon, les versions linguistiques arriveront sous forme de contenu déconnecté et sans lien entre elles.
- La valeur de l'archive académique : des années d'actualités, d'annonces et de publications portent à la fois la mémoire institutionnelle et la visibilité dans les classements Webometrics. Prendre la solution de facilité en abandonnant l'ancien contenu détruit la valeur SEO à long terme.
- Transformation des utilisateurs et des rôles : les comptes éditeurs dispersés sur des dizaines de sites peuvent être regroupés dans une gestion d'identité centralisée grâce à une intégration LDAP/CAS côté Drupal.
- Le calendrier : la mise en ligne doit être planifiée en dehors des périodes de forte affluence telles que les périodes d'inscription, la publication des décisions d'admission et les jours de résultats.
Erreurs courantes dans les projets de migration
- Copier la structure WordPress à l'identique : une migration est une occasion de reconstruire l'architecture de contenu, pas de transposer un désordre existant sur une nouvelle plateforme.
- Mettre en ligne sans migration test : la première migration doit toujours être exécutée en préproduction, avec vérification du contenu, des médias et de l'encodage des caractères.
- Négliger les redirections d'URL : une migration sans carte de redirections 301 peut anéantir des années de trafic organique et de valeur de backlinks en l'espace de quelques semaines.
- Oublier les fichiers média : si le texte du contenu est transféré mais que les images restent sur l'ancien serveur, le site sera lancé avec des images cassées partout.
- Traiter la migration comme un projet purement technique : si les équipes éditoriales ne reçoivent aucune formation sur l'interface Drupal, même la migration technique la plus réussie finit par être sous-exploitée.
Questions fréquentes sur la migration de WordPress vers Drupal
Combien de temps prend une migration de WordPress vers Drupal ?
Cela dépend de l'ampleur du site. Un blog d'entreprise avec une structure de contenu standard peut être migré en quelques semaines, tandis qu'un projet à l'échelle d'une université impliquant plusieurs langues, plusieurs sites et des structures de champs personnalisées peut prendre de deux à quatre mois, incluant la planification, la migration, les tests et la mise en ligne. Le facteur principal n'est pas le volume de contenu mais la complexité de sa structure.
Vais-je perdre du contenu pendant la migration ?
Pas dans une migration correctement planifiée. La plus grande force de l'API Migrate est que les migrations sont réversibles et reproductibles : lorsqu'une erreur de correspondance est détectée, vous revenez en arrière, vous la corrigez, et vous relancez la migration. La sauvegarde complète réalisée au préalable agit comme un filet de sécurité dans tous les scénarios.
Mon positionnement SEO va-t-il chuter lors du changement de CMS ?
Avec une correspondance d'URL et des redirections 301 correctement mises en place, il n'y a pas de baisse durable. De légères fluctuations dans les premières semaines suivant une migration sont normales et se rétablissent généralement rapidement. En réalité, l'architecture de mise en cache robuste de Drupal et son modèle de contenu structuré peuvent améliorer les Core Web Vitals et les performances d'indexation à moyen terme, contribuant ainsi positivement au SEO.
Mon thème et mes extensions WordPress peuvent-ils être migrés vers Drupal ?
Non — les architectures de thèmes et d'extensions des deux plateformes sont entièrement différentes. Ce qui est migré, c'est le contenu, les utilisateurs, les médias et la taxonomie. Le design est reconstruit dans la couche de thème de Drupal, et les fonctions que vos extensions fournissaient sont reconstruites à l'aide d'équivalents issus de l'écosystème de modules Drupal. Dans la plupart des projets, cela devient une occasion naturelle de moderniser à la fois le design et les fonctionnalités.
Dois-je migrer avec un fichier WXR ou via une connexion à la base de données ?
Sur les sites petits et moyens, migrer avec un fichier WXR est pratique et suffisant, et ne nécessite aucun accès à la base de données. Sur les sites à fort volume avec de vastes archives de contenu, une connexion directe à la base de données est plus rapide et plus fiable. Pour les nouveaux projets construits sur Drupal CMS, la WordPress Migrate Recipe rend le processus gérable avec un minimum de connaissances techniques. Le bon choix doit être arrêté durant la phase de découverte, en fonction du volume de contenu, de l'accès disponible et de l'architecture cible.