Migrer de WordPress vers Drupal : guide complet

Par Driss Redouane · 20 juin 2026 · 14 min de lecture

En bref

Migrer de WordPress vers Drupal n'est pas une mise à niveau, c'est un changement de CMS. On ne « met pas à jour » WordPress en Drupal : on reconstruit le site et on transfère uniquement les contenus.

Quand c'est justifié : très gros volumes de contenu, multilingue exigeant, droits granulaires, workflows éditoriaux complexes, ou WordPress devenu ingérable à force de greffons.
Quand ça ne l'est pas : blog, vitrine ou petite boutique qui tournent bien — restez sous WordPress, ce sera plus simple et moins cher.
La clé technique : la Migrate API de Drupal lit directement la base WordPress ; le mapping des contenus et la recette pèsent plus lourd que le transfert lui-même.
Le point à ne jamais rater : un plan de redirections 301 exhaustif pour préserver le référencement acquis sous WordPress.

« Faut-il migrer de WordPress vers Drupal ? » C'est une question que l'on me pose souvent, et ma réponse honnête commence presque toujours par : « probablement pas ». WordPress équipe une part énorme du web parce qu'il fait très bien son travail. Drupal n'est pas un « meilleur WordPress » : c'est un outil différent, taillé pour des contenus structurés à grande échelle. Migrer de l'un à l'autre se justifie uniquement quand on bute concrètement sur les limites de WordPress.

Dans ce guide, je pose d'abord les bonnes raisons de franchir le pas — et les cas où il vaut mieux rester là où vous êtes. J'enchaîne ensuite avec la méthode que j'applique réellement sur le terrain : audit, modélisation du contenu, transfert via la Migrate API, mapping des contenus, redirections 301, préservation du SEO et recette. Je termine par les pièges récurrents et des fourchettes de budget. L'objectif : vous donner de quoi décider en connaissance de cause, pas vous vendre une migration dont vous n'avez pas besoin.

Pourquoi migrer de WordPress vers Drupal ?

Drupal brille là où WordPress commence à montrer ses limites. Voici les motifs qui, sur le terrain, justifient réellement une migration. Si aucun ne résonne avec votre situation, sautez directement à la section suivante : elle explique pourquoi rester sous WordPress.

1. Des contenus structurés à grande échelle

WordPress raisonne en « articles » et « pages ». Dès qu'un site doit gérer des dizaines de milliers de fiches aux relations complexes — annuaire, catalogue documentaire, base de connaissances, contenus reliés entre eux — on finit par empiler des extensions de types personnalisés et de champs ACF qui alourdissent l'ensemble. Drupal, lui, modélise nativement les types de contenu, les champs typés et les relations (Entity Reference) : c'est sa raison d'être. Plus le volume et la structure montent, plus l'écart se creuse en faveur de Drupal.

2. Un multilingue réellement natif

Le multilingue de WordPress passe par des extensions tierces (WPML, Polylang) qui dupliquent les contenus et compliquent la maintenance. Drupal embarque la traduction dans son cœur depuis Drupal 8 : chaque entité, chaque champ, chaque élément d'interface se traduit sans greffon. Pour un site déployé en cinq, dix ou vingt langues, cette différence d'architecture change radicalement la vie au quotidien.

3. Des droits et des workflows éditoriaux fins

Le système de rôles de WordPress reste sommaire. Drupal offre des permissions granulaires (qui peut créer, modifier, publier, traduire tel type de contenu), des workflows éditoriaux à plusieurs états (brouillon, relecture, validation, publication) et une gestion de versions intégrée. Pour une rédaction nombreuse, un service de presse ou une administration soumise à des circuits de validation, c'est souvent l'argument décisif.

4. Sécurité et gouvernance

La force de WordPress — son immense écosystème d'extensions — est aussi sa principale surface d'attaque : la plupart des compromissions viennent d'un greffon non maintenu. Drupal concentre davantage de fonctionnalités dans son cœur audité et impose une discipline plus stricte sur les modules contribués. Pour une organisation qui a des exigences de sécurité formelles, ce socle plus maîtrisé pèse dans la balance.

Quand il vaut mieux rester sous WordPress

C'est la section que la plupart des prestataires omettent, parce qu'elle ne vend rien. Pourtant, dans une bonne partie des cas que l'on me soumet, mon conseil est de ne pas migrer. Voici les situations où WordPress reste le bon choix.

Votre site fonctionne et vous le maîtrisez

Un blog, un site vitrine, le site d'un cabinet ou d'un artisan, dont l'équipe sait publier en autonomie : il n'y a aucune raison technique de migrer. Changer de CMS pour le plaisir de changer revient à payer cher pour reconstruire ce que vous avez déjà, avec une courbe d'apprentissage à la clé. Si rien ne casse, ne réparez rien.

Votre boutique tourne sous WooCommerce

Pour le e-commerce de petite et moyenne taille, WooCommerce et son écosystème sont matures, bien documentés et abordables. Drupal Commerce est puissant mais plus exigeant à mettre en œuvre. La migration ne se justifie que pour des catalogues très volumineux ou des règles métier que WooCommerce ne sait pas tenir proprement.

Votre équipe est attachée à l'éditeur WordPress

Gutenberg et les page builders ont rendu WordPress très confortable pour les rédacteurs. L'administration de Drupal, plus austère, demande un temps d'adaptation. Si l'autonomie de vos contributeurs est une priorité et que vos besoins de structuration restent simples, ce confort a une vraie valeur qu'une migration mettrait à mal.

Votre budget est serré

Une migration de WordPress vers Drupal n'est pas une opération marginale : c'est une reconstruction du site. Si le budget ne le permet pas, mieux vaut investir dans le nettoyage et l'optimisation de l'existant WordPress — alléger les extensions, améliorer les performances, renforcer la sécurité — plutôt que dans un changement de plateforme à moitié financé, qui finit toujours mal.

La bonne question à se poser

Avant tout projet, je pose une seule question : « Quelle limite précise de WordPress vous bloque aujourd'hui ? » Si la réponse est claire et concrète, la migration a du sens. Si elle reste vague (« on nous a dit que Drupal était plus pro »), c'est le signal qu'il faut creuser avant d'engager quoi que ce soit.

La méthode, étape par étape

Migrer de WordPress vers Drupal n'est pas un transfert de fichiers : on reconstruit le site sous Drupal, puis on y déverse les contenus de WordPress. Voici les cinq étapes que je déroule sur chaque projet.

Étape 1 : auditer le WordPress existant

Je commence par cartographier le site source : combien d'articles, de pages, de types personnalisés, quels champs ACF, quelles taxonomies (catégories, étiquettes), quels médias, quelles extensions actives et que fait chacune. Je crawle aussi l'intégralité des URL avec un outil type Screaming Frog pour figer la liste exhaustive — elle servira au plan de redirections. Cet inventaire est la fondation : on ne migre bien que ce que l'on a d'abord compris.

Étape 2 : modéliser le contenu sous Drupal

C'est l'étape qui fait la qualité du résultat. Plutôt que de recopier bêtement la structure WordPress, je conçois les types de contenu Drupal qui correspondent à la réalité éditoriale : un type « Article », un type « Étude de cas », un type « Membre de l'équipe » avec des champs typés (date, image, référence, lien) plutôt que du texte libre. Les champs ACF de WordPress trouvent ici leur équivalent propre. Bien faite, cette modélisation transforme un contenu plat en données réellement exploitables.

Étape 3 : transférer avec la Migrate API

Le cœur de Drupal embarque une Migrate API capable de lire directement la base MySQL de WordPress. Je décris des migrations en YAML qui associent chaque source (table wp_posts, wp_terms, métadonnées ACF, médias) à sa destination Drupal et à ses champs. Pour les structures atypiques, je bascule sur un export CSV ou sur l'API REST de WordPress. La migration est rejouable à volonté : je la lance, je vérifie, je corrige le mapping, et je recommence jusqu'à ce que tout tombe juste.

Étape 4 : poser les redirections 301

Les URL de Drupal ne ressemblent pas forcément à celles de WordPress. Pour ne pas sacrifier le référencement acquis, je construis un plan de redirections 301 qui relie chaque ancienne URL à sa nouvelle adresse, à partir du crawl réalisé à l'étape 1. Le module Redirect de Drupal gère ces correspondances, et le module Pathauto génère des URL propres et cohérentes pour les nouveaux contenus.

Étape 5 : recetter avant la bascule

Avant toute mise en ligne, je vérifie sur un environnement de test : intégrité des contenus migrés, médias bien rattachés, redirections fonctionnelles, balises SEO reportées, accessibilité RGAA et performances. Ce n'est qu'une fois cette recette validée, et après une ultime migration des contenus créés entre-temps, que l'on bascule le DNS vers le nouveau site Drupal.

Extensions, thème et SEO : ce qui se transfère (et ce qui se reconstruit)

L'idée fausse la plus tenace : « on migre tout ». En réalité, seuls les contenus passent. Tout ce qui fait le comportement et l'apparence du site WordPress doit être ré-implémenté côté Drupal. Voici le partage clair.

Les extensions ne suivent pas

Drupal n'exécute pas les extensions WordPress : ce sont deux univers de code distincts. Pour chaque extension utile, on cherche l'équivalent fonctionnel côté Drupal. Contact Form 7 devient un formulaire Webform ; Yoast SEO se remplace par les modules Metatag, Pathauto et Simple XML Sitemap ; un slider devient un champ média Drupal ; une extension de cache cède la place au cache interne de Drupal et à un reverse proxy. Cet inventaire des correspondances fait partie de l'audit initial.

Le thème est reconstruit en Twig

Le thème WordPress (PHP, functions.php, fichiers de template) n'est pas portable. L'habillage est rebâti dans le système de templates Twig de Drupal. C'est l'occasion d'assainir le balisage, d'améliorer l'accessibilité et les performances plutôt que de traîner la dette du thème d'origine. Selon le projet, on repart d'un thème de base Drupal ou l'on réintègre la maquette existante au pixel près.

Le SEO se préserve, à condition de le préparer

C'est le point le plus sensible. Le référencement acquis tient à trois choses qu'il faut transposer fidèlement : les URL (via le plan de redirections 301), les balises (title, méta-description, données structurées, balises Open Graph) et le contenu lui-même (titres, textes, attributs alt des images). Je reporte les balises Yoast vers Metatag, je vérifie le sitemap et je contrôle après bascule qu'aucune URL importante ne renvoie de 404. Bien menée, la migration est neutre pour le SEO ; bâclée, elle coûte des mois de trafic.

Les médias et la bibliothèque

Les fichiers de la médiathèque WordPress (images, PDF) sont transférés et rattachés aux contenus via la Migrate API, puis convertis en entités Media de Drupal pour bénéficier de sa gestion des styles d'image et des formats responsives. C'est aussi un bon moment pour purger les médias orphelins qui s'accumulent sous WordPress.

Le déroulé d'un projet de migration

Concrètement, une migration de WordPress vers Drupal s'organise en quatre phases qui s'enchaînent. Voici ce que contient chacune, à ajuster selon la taille du site et vos contraintes éditoriales.

Phase 1 - Audit et cadrage

Inventaire des contenus WordPress : articles, pages, types personnalisés, champs ACF, taxonomies
Recensement des extensions actives et de leur équivalent fonctionnel Drupal
Crawl complet des URL pour préparer le plan de redirections 301
Relevé des balises SEO et des contenus les mieux référencés à préserver en priorité
Devis et planning hiérarchisant les contenus et les risques identifiés

Phase 2 - Modélisation et construction

Conception des types de contenu Drupal et de leurs champs typés
Réimplémentation des fonctions des extensions (Webform, Metatag, Pathauto, etc.)
Reconstruction du thème en Twig, ou réintégration de la maquette existante
Mise en place des rôles, permissions et workflows éditoriaux
Configuration du multilingue lorsque le site le requiert

Phase 3 - Migration des données

Écriture des migrations YAML reliant chaque source WordPress à sa destination Drupal
Transfert des médias et conversion en entités Media
Migrations à blanc répétées sur copie, contrôle et correction du mapping
Mise en place des redirections 301 à partir du crawl initial
Vérification de l'intégrité : volumes, liens internes, médias rattachés

Phase 4 - Recette et mise en ligne

Recette fonctionnelle complète : contenus, formulaires, recherche, accessibilité, performance
Contrôle des redirections et chasse aux 404 sur les URL importantes
Ultime migration des contenus créés sous WordPress depuis le dernier essai
Bascule du DNS sur un créneau calme, avec scénario de retour arrière
Surveillance des premiers jours, suivi de l'indexation et documentation transmise

Budget et délais : à quoi s'attendre

Voici les fourchettes que j'observe pour une migration de WordPress vers Drupal menée par un intervenant expérimenté. Le poste le plus lourd n'est jamais le transfert des données : ce sont la modélisation du contenu et la recette. Plus le site est structuré, plus ces deux étapes pèsent.

Site de contenu simple

Blog ou site éditorial, articles et pages, peu de champs personnalisés, structure proche du standard WordPress. 6 000 à 15 000 € HT, 4 à 7 semaines. La migration des contenus est rapide ; l'essentiel du temps va à la reconstruction du thème et au plan de redirections.

Site structuré, multilingue ou riche en ACF

Nombreux types de contenu personnalisés, champs ACF complexes, multilingue, quelques intégrations métier. 15 000 à 40 000 € HT, 8 à 16 semaines. La modélisation du contenu et le mapping des champs ACF deviennent le cœur du chantier, avec plusieurs migrations à blanc avant validation.

Grande plateforme ou e-commerce

Très gros volume de contenus, workflows éditoriaux complexes, reprise d'un WooCommerce vers Drupal Commerce, intégrations CRM/ERP. 40 000 à 90 000 € HT et au-delà, 16 à 30 semaines. Le tarif dépend surtout du nombre de types de contenu, du volume migré et de la complexité des règles métier à reconstruire.

Le poste qu'on sous-estime toujours

La recette. Vérifier que chaque contenu est arrivé intact, que les redirections fonctionnent, que les médias sont rattachés et que le SEO est préservé prend souvent plus de temps que la migration elle-même. Je réserve au minimum 25 à 35 % de l'enveloppe à cette étape : c'est elle qui fait la différence entre une migration réussie et un site qui perd des contenus et du trafic en silence.

Les pièges à éviter

Migrer sans plan de redirections

C'est de très loin l'erreur la plus coûteuse. Mettre en ligne le Drupal sans relier chaque ancienne URL WordPress à sa nouvelle adresse, c'est offrir à Google une avalanche de 404 et voir le trafic organique s'effondrer le temps de la réindexation. Le plan de redirections 301 se prépare dès l'audit, à partir d'un crawl exhaustif de l'existant. Aucune URL référencée ne doit rester orpheline.

Recopier la structure WordPress à l'identique

Transposer mécaniquement les « articles » et « pages » de WordPress en l'état, c'est passer à côté de tout l'intérêt de Drupal. Si l'on migre pour structurer le contenu, autant le faire : c'est le moment de penser de vrais types de contenu et des champs typés. Une migration qui se contente de déplacer un contenu plat d'un CMS à l'autre coûte cher pour un bénéfice nul.

Sous-estimer le remplacement des extensions

Chaque extension WordPress active rend un service qu'il faudra reproduire côté Drupal. Oublier d'en inventorier une au moment de l'audit, c'est découvrir en pleine recette qu'un formulaire, un calcul ou une intégration manque. Le tableau de correspondance extension WordPress / module Drupal doit être dressé dès le départ, sans exception.

Migrer sans faire le ménage

Beaucoup de sites WordPress accumulent des brouillons, des révisions, des médias orphelins et des extensions désactivées. Migrer cette accumulation telle quelle, c'est polluer le nouveau site et alourdir le chantier. La migration est l'occasion idéale de trier : on ne transfère que ce qui a de la valeur, on archive le reste.

Couper le WordPress trop tôt

Tant que la recette du Drupal n'est pas pleinement validée et que les redirections ne sont pas contrôlées, le WordPress d'origine reste votre filet de sécurité. Je conserve toujours une sauvegarde complète et fonctionnelle de l'ancien site pendant plusieurs semaines après la bascule, le temps de s'assurer qu'aucun contenu ni aucune URL n'a été perdu.

Ma façon de mener une migration

Je connais les deux mondes : j'ai créé et maintenu des sites WordPress, et je développe sous Drupal depuis des années. C'est ce double regard qui me permet de vous dire honnêtement si la migration vaut le coup — ou non. Je reste votre interlocuteur unique, de l'audit du WordPress existant jusqu'au suivi de l'indexation après la bascule. Pas d'agence ni d'équipe à coordonner : un seul expert senior qui prend personnellement votre projet en main.

Mon credo, c'est la prévisibilité. Tout démarre par un audit chiffré du site WordPress, suivi d'une modélisation de contenu écrite noir sur blanc, de migrations à blanc rejouées sur copie, d'un plan de redirections vérifié et d'une recette complète conduite sans exception avant la mise en ligne. Aucun « big-bang », aucune URL sacrifiée, aucune rallonge tarifaire qui tombe en cours de route.

Une migration de WordPress vers Drupal réussie ne se mesure pas au jour de la bascule, mais trois mois plus tard : le trafic est intact, aucun contenu n'a disparu, et l'équipe travaille mieux qu'avant. Tout se joue dans la préparation, jamais dans la précipitation.
Driss Redouane, expert web indépendant — ReydenWeb

Mon offre Drupal

FAQ

Questions fréquentes

Dans la majorité des cas, non. WordPress fait très bien le travail pour un blog, un site vitrine ou une boutique WooCommerce de taille modeste. Migrer de WordPress vers Drupal n'a de sens que lorsqu'on bute sur des limites précises : des dizaines de milliers de contenus à organiser finement, un multilingue exigeant, des rôles et permissions très granulaires, des workflows éditoriaux à plusieurs validations, ou une plateforme assemblée à coups de greffons qui devient ingérable. Si rien de tout cela ne vous concerne, restez sous WordPress : ce sera moins cher et plus simple à maintenir.

Pas si elle est préparée correctement. Le SEO se préserve grâce à un plan de redirections 301 qui relie chaque ancienne URL WordPress à son équivalent Drupal, au report fidèle des balises title, méta-description et données structurées, et au maintien des titres et du contenu. Je crawle le site WordPress avant la bascule pour figer la liste exhaustive des URL, puis je contrôle après mise en ligne qu'aucune ne renvoie d'erreur 404. Un site migré sans plan de redirection, en revanche, perd presque toujours du trafic le temps que Google réindexe.

Le cœur de l'opération repose sur la Migrate API de Drupal, qui sait lire directement la base de données MySQL de WordPress. On décrit des fichiers de migration (en YAML) qui associent chaque table WordPress — articles, pages, catégories, étiquettes, champs personnalisés ACF, médias — à un type de contenu Drupal et à ses champs. Pour les structures atypiques, j'exporte plutôt en CSV ou je passe par l'API REST de WordPress. La règle d'or : tout faire tourner d'abord sur une copie, rejouer la migration autant de fois que nécessaire, puis ne la lancer en réel qu'une fois le mapping verrouillé.

Pour un site de contenu classique, peu de champs personnalisés : 6 000 à 15 000 € HT. Dès qu'apparaissent de nombreux types de contenu ACF, du multilingue ou des intégrations métier : 15 000 à 40 000 € HT. Pour une grande plateforme avec gros volume de contenus, workflows complexes et reprise de WooCommerce : 40 000 à 90 000 € HT et au-delà. Le poste qui pèse le plus n'est pas le transfert des données mais la modélisation du contenu et la recette.

Elles ne sont pas transférables : Drupal n'exécute pas les extensions ni les thèmes WordPress. Il faut retrouver l'équivalent fonctionnel côté Drupal — un formulaire Contact Form 7 devient un formulaire Webform, Yoast SEO se remplace par les modules Metatag et Pathauto, WooCommerce par Drupal Commerce. Le thème, lui, est reconstruit dans le système de templates Twig de Drupal. C'est précisément ce travail de réimplémentation, plus que le déplacement des données, qui constitue le gros du chantier d'une migration.

Oui. La migration se prépare en parallèle, sur un environnement séparé, sans jamais toucher au WordPress en production. Vos visiteurs continuent d'utiliser le site existant pendant que je construis et que je remplis le Drupal de côté. La bascule proprement dite — bascule du DNS ou du serveur web vers le nouveau site — ne dure que quelques minutes et se planifie sur un créneau calme. Une ultime migration des contenus créés depuis le dernier essai garantit que rien de récent n'est oublié au moment du basculement.

Me contacter

Me suivre