Open Source & Outils. Migration WordPress vers Drupal : le retour d'expérience de Marc

Migration WordPress vers Drupal: le retour d'expérience de Marc

Elle commence par une mauvaise intuition: puisque les deux CMS reposent sur PHP, on imagine qu’il suffira de déplacer les tables, de réinstaller quelques modules et de refaire le thème. Sur le papier, c’est séduisant. Dans la vraie vie, c’est le genre de raccourci qui transforme une migration de contenu en séance prolongée de débogage existentiel.

Le cas de Marc illustre précisément ce basculement. Son site WordPress fonctionne, son contenu est là, les utilisateurs aussi, et pourtant l’architecture cible n’a plus grand-chose à voir avec celle de départ. WordPress pense en extensions, crochets et tables historiques. Drupal raisonne en entités, configuration exportable, services injectés et rendu Twig. Même langage sous le capot, autre manière de construire le monde.

C’est tout le paradoxe de cette migration CMS PHP complexe: la proximité technique facilite l’entrée, mais elle peut aussi masquer l’ampleur du changement.

Pourquoi WordPress et Drupal ne parlent-ils pas exactement la même langue?

WordPress donne rapidement une impression de familiarité. On installe une extension, on ajoute un crochet, on surcharge une fonction, on intervient dans la boucle. L’écosystème est vaste, documenté, parfois merveilleusement pragmatique. Il est aussi marqué par une longue histoire de compatibilité ascendante, de conventions souples et de bricolages devenus des standards de fait.

Drupal, lui, impose davantage de structure. Les contenus sont modélisés comme des entités. Les champs sont séparés de la présentation. La configuration peut être exportée et versionnée. Les services passent par l’injection de dépendances. Le rendu s’appuie sur Twig. Et lorsqu’on commence à travailler proprement avec Drupal moderne, on rencontre rapidement les plugins, les événements, les contrôleurs, les files d’attente et tout un environnement qui ressemble davantage à un framework applicatif qu’à un simple gestionnaire de publication.

Ce n’est pas une question de supériorité morale. On peut laisser ce genre de débat aux fils de discussion où chacun explique que son CMS préféré est le seul à avoir compris Internet. Le sujet est plus concret: une migration réussie exige de traduire un modèle mental dans un autre.

Dans WordPress, un article est souvent associé à un type de publication, des métadonnées, des taxonomies et une série d’extensions qui enrichissent son comportement. Dans Drupal, on va plutôt définir un type d’entité, des champs, des vocabulaires, des références et des règles de présentation. Le contenu ne disparaît pas pendant la migration, mais sa logique doit être reconstruite.

Ce que l’on déplace vraiment

Déplacer le contenu WordPress vers Drupal ne consiste donc pas seulement à copier des titres et des paragraphes. Il faut établir une correspondance entre plusieurs couches:

• les utilisateurs WordPress et les comptes Drupal;
• les articles, pages et types de publication avec les nœuds et autres entités de contenu;
• les catégories et étiquettes avec les termes de taxonomie;
• les images et fichiers avec les médias et leurs champs associés;
• les commentaires avec le modèle de commentaires Drupal;
• les métadonnées SEO, les dates, les auteurs, les statuts de publication et les relations entre contenus.

Cette cartographie est le premier vrai travail de la migration. Le code vient ensuite. Et parfois, il révèle que le modèle WordPress s’est construit par accumulation: une extension pour les champs personnalisés, une autre pour les contenus multilingues, une troisième pour le référencement, puis quelques fonctions dans le fichier du thème. Tout ce qui semblait parfaitement cohérent côté administration doit maintenant trouver sa place dans une architecture Drupal plus explicite.

Une migration ne déplace pas seulement des données: elle traduit une façon de penser le contenu.

Pour Marc, c’est ce changement de perspective qui rend l’opération intéressante — et nettement moins automatique qu’annoncé dans certaines présentations trop enthousiastes. Une base de données peut être importée. Une architecture, elle, doit être interprétée.

Comment l’API Migrate transforme-t-elle le transfert de contenu?

L’un des grands avantages de Drupal pour ce type de projet est son API Migrate. Elle fournit un cadre pour extraire, transformer et importer des données vers les entités Drupal. Le module Drupal WordPress to Drupal Migrate permet notamment d’importer directement depuis la base MySQL de WordPress des utilisateurs, des nœuds, des taxonomies, des médias et des commentaires.

Le mot important ici est bien importer, pas comprendre automatiquement. L’outil connaît les structures courantes de WordPress. Il ne connaît pas nécessairement les décisions prises au fil des années sur le site de Marc, ni les extensions qui ont ajouté leurs propres tables, ni les champs dont le nom ne veut plus rien dire depuis trois refontes.

L’API Migrate repose sur une logique de migrations déclaratives. Une source fournit les données, des processus les transforment, puis une destination les écrit dans Drupal. Cette séparation est précieuse: elle permet de rejouer l’opération, d’ajuster une transformation et de comparer les résultats sans repartir d’un script monolithique bricolé un vendredi soir.

Base MySQL ou export WXR: quel chemin choisir?

Deux grandes approches se présentent généralement.

La première consiste à lire directement la base MySQL de WordPress. C’est souvent la voie la plus riche lorsque l’on souhaite récupérer les relations, les identifiants, les métadonnées et les informations qui ne figurent pas dans un export éditorial classique. Le module de migration peut alors travailler au plus près de la structure d’origine.

La seconde passe par le format WXR, ou WordPress eXtended RSS. WordPress permet de générer cet export depuis l’interface d’administration, et la commande wp export offre une alternative adaptée aux environnements pilotés en ligne de commande. Le fichier contient le contenu éditorial exportable: publications, taxonomies, commentaires et certains éléments associés.

Ces deux méthodes ne répondent pas exactement au même besoin.

Dans les deux cas, l’export n’est que la matière première. Il faut ensuite définir les migrations, leurs dépendances et leur ordre d’exécution. Les taxonomies doivent être disponibles avant les contenus qui les référencent. Les fichiers doivent être accessibles avant les médias. Les utilisateurs doivent exister avant de pouvoir être associés comme auteurs.

Ce sont des détails? Oui, jusqu’au moment où chaque article importé se retrouve attribué à un compte supprimé, avec une image dont le chemin pointe vers un ancien domaine. Là, le détail devient soudain le sujet principal de la réunion.

Quelles transformations prévoir dans le code?

La migration de contenu exige généralement plusieurs transformations:

1. Normaliser les identifiants et les références

Les identifiants WordPress ne sont pas automatiquement ceux que Drupal utilisera. Il faut conserver des correspondances entre anciennes et nouvelles entités pour relier les contenus, les médias, les auteurs et les taxonomies.

2. Convertir les champs personnalisés

Un champ WordPress stocké comme métadonnée peut devenir un champ Drupal typé. Une valeur texte peut devoir être transformée en référence d’entité, en date, en booléen ou en collection de valeurs.

3. Nettoyer le HTML historique

Les contenus peuvent contenir des balises issues de l’éditeur WordPress, des classes de mise en page, des shortcodes ou des fragments propres à une extension. Les importer tels quels revient souvent à transporter le passé avec ses meubles, ses câbles et son armoire impossible à démonter.

4. Réécrire les chemins de fichiers

Les URL d’images et de documents doivent pointer vers les fichiers gérés par Drupal. Le simple remplacement du domaine ne suffit pas toujours: l’organisation des répertoires et les styles d’image peuvent changer.

5. Préserver les dates et les statuts

Une publication, un brouillon, une page privée ou un contenu programmé ne doivent pas être traités de la même manière. Ces états font partie du comportement éditorial du site.

Une bonne migration est donc rejouable. On doit pouvoir vider l’environnement de test, corriger une règle, relancer l’import et observer précisément ce qui change. Si le seul moyen de corriger une erreur consiste à ouvrir la base à la main et à modifier quelques lignes au hasard, on n’a pas encore une migration: on a un incident en préparation.

Pourquoi les mots de passe PHPass posent-ils un problème particulier?

Le sujet de l’authentification est souvent repoussé à la fin, comme si les comptes utilisateurs étaient une donnée secondaire. C’est une erreur. Un site peut récupérer ses articles, ses images et ses catégories, puis échouer sur l’expérience la plus sensible: la connexion des utilisateurs existants.

WordPress utilise historiquement le système de hachage PHPass. Drupal moderne s’appuie sur l’API de hachage de mot de passe de PHP, avec des mécanismes compatibles avec son propre système de sécurité. Les deux approches ne sont pas interchangeables par défaut.

Autrement dit, on ne transfère pas une colonne de mots de passe comme on transfère une date de publication. Le mot de passe n’est pas censé être récupéré en clair, et son ancien hachage ne peut pas simplement être présenté à Drupal comme s’il avait été produit par son propre système.

Deux stratégies, aucune magie

La première stratégie consiste à imposer une réinitialisation des mots de passe. Elle est simple à expliquer et relativement propre sur le plan de la sécurité: après la migration, les utilisateurs reçoivent une procédure pour définir un nouveau mot de passe selon les règles du site Drupal.

Cette approche a toutefois un coût d’usage. Elle ajoute une friction, provoque des demandes au support et peut perturber les comptes qui ne se reconnectent pas régulièrement. Pour un petit site, c’est parfois le choix le plus raisonnable. Pour une plateforme communautaire ou un espace client très actif, l’impact doit être anticipé.

La seconde stratégie consiste à mettre en place un mécanisme de transition. Drupal peut reconnaître temporairement l’ancien format PHPass au moment de la connexion, puis recalculer le mot de passe avec son système cible après une authentification réussie. Cela demande un module ou un traitement sur mesure correctement intégré au cycle d’authentification.

Ce fonctionnement ne doit pas être présenté comme un transfert transparent obtenu en cochant une option. Il suppose du code, des tests, une politique de retrait de la compatibilité et une attention particulière aux comptes inactifs. Les utilisateurs qui ne se connectent jamais pendant la période de transition resteront concernés par le problème.

Marc découvre ici une règle assez universelle du développement web: les données les plus visibles ne sont pas toujours les plus délicates. Une centaine de milliers de paragraphes peut se traiter avec une migration bien structurée. Une stratégie de connexion mal pensée suffit à transformer le déploiement en cauchemar relationnel.

Le contenu se migre avec une procédure. La confiance des utilisateurs, beaucoup moins.

Comment préserver les URL et le référencement pendant le changement de CMS?

Le changement de CMS est aussi un changement potentiel de géographie. Les chemins de WordPress ont souvent été modelés par des réglages de permaliens, des extensions SEO et des habitudes éditoriales. Drupal propose ses propres alias, ses propres patterns et ses propres règles de génération d’URL.

Si l’on modifie cette structure sans plan précis, les moteurs de recherche rencontrent des pages déplacées, des liens internes cassés et des réponses 404. Le contenu est toujours là, mais il n’est plus accessible à la même adresse. Pour les lecteurs comme pour le référencement naturel, c’est une différence loin d’être théorique.

La conservation de la structure des URL et la mise en place d’un plan strict de redirections 301 sont indispensables. Il faut établir une correspondance entre chaque ancienne URL importante et sa destination Drupal. Les pages qui n’ont plus d’équivalent exact doivent être orientées vers une ressource réellement pertinente, pas vers la page d’accueil par réflexe administratif.

L’inventaire des URL avant le développement

Avant d’écrire les règles de redirection, il faut dresser l’inventaire des adresses existantes. On y trouve les publications, les pages, les archives, les taxonomies, les fichiers et parfois des URL générées par des extensions. Le contenu visible dans le menu n’est qu’une petite partie de la surface réelle d’un site.

L’ancienne structure peut ressembler à ceci dans sa logique:

• articles avec une date dans l’URL;
• pages hiérarchiques;
• catégories et étiquettes;
• archives d’auteur;
• fichiers médias accessibles directement;
• flux et formats historiques;
• URL personnalisées créées pour des campagnes ou des contenus anciens.

Drupal peut reproduire une grande partie de ces chemins, mais la reproduction doit être décidée. Il ne faut pas supposer que le simple fait de conserver le même titre produira le même alias. Les accents, les caractères spéciaux, les doublons et les traductions peuvent modifier le résultat.

La stratégie la plus robuste sépare trois sujets:

1. Les URL à conserver telles quelles

Lorsqu’un chemin est propre, stable et compatible avec la nouvelle modélisation, le garder réduit le nombre de redirections.

2. Les URL à transformer

Si la structure change, chaque ancienne adresse doit recevoir une destination explicite. Les règles génériques peuvent aider, mais elles doivent être contrôlées sur un échantillon représentatif.

3. Les URL à abandonner

Une ancienne page sans contenu équivalent ne doit pas être redirigée mécaniquement vers une page sans rapport. Il faut choisir entre une destination proche, une réponse 410 ou une autre stratégie cohérente avec le contenu.

La question SEO ne se limite pas aux redirections. Il faut également vérifier les liens internes, les balises canoniques, les plans de site, les métadonnées, les fichiers robots et les versions multilingues lorsqu’elles existent. Le nouveau site peut afficher exactement le même article tout en envoyant des signaux différents aux moteurs de recherche.

Les redirections se testent comme du code

Une règle de redirection qui fonctionne sur trois exemples peut échouer sur les cas historiques. Les URL avec des caractères encodés, des suffixes, des paramètres ou des niveaux hiérarchiques inattendus sont particulièrement révélatrices.

Le test doit couvrir:

• des contenus récents et anciens;
• des pages avec et sans trailing slash;
• des taxonomies;
• des fichiers médias;
• des URL supprimées;
• des chemins contenant des caractères accentués;
• des anciennes adresses bénéficiant de liens externes;
• les variantes HTTP, HTTPS, avec ou sans sous-domaine.

On peut vouloir automatiser cette phase, et c’est une excellente idée. Mais l’automatisation doit produire un rapport lisible: URL source, destination, code HTTP obtenu et éventuelle chaîne de redirections. Une redirection 301 qui pointe vers une autre redirection n’est pas forcément dramatique, mais une longue chaîne ralentit le parcours et complique le diagnostic.

Pour les détails opérationnels liés au fonctionnement des migrations Drupal, la documentation consacrée à l’API de migration constitue une base utile, notamment pour comprendre la logique des sources, processus et destinations.

Que change Drupal pour un développeur PHP habitué à WordPress?

La transition vers Drupal moderne demande plus qu’une familiarisation avec quelques fonctions. Elle touche à la manière d’organiser le code.

WordPress autorise beaucoup de choses directement dans les thèmes et les extensions. Drupal pousse davantage vers une séparation entre la logique métier, la configuration, les services et la présentation. Cette contrainte peut sembler lourde au début. Elle devient généralement un avantage lorsque le projet grandit, que plusieurs développeurs interviennent ou que les environnements doivent rester synchronisés.

L’injection de dépendances n’est pas un décor de conférence

Dans Drupal, l’injection de dépendances permet de fournir à une classe les services dont elle a besoin plutôt que de les récupérer directement dans son corps. Pour un développeur PHP venant de WordPress, le changement est important: on ne se contente plus d’appeler une fonction globale parce qu’elle existe quelque part dans le cycle de chargement.

Cette approche rend les responsabilités plus visibles et facilite les tests. Elle demande aussi une discipline supplémentaire dans la construction des services, des contrôleurs et des plugins. Les premiers jours, on peut avoir l’impression de remplir beaucoup de formulaires pour faire quelque chose qui semblait tenir en trois lignes dans WordPress. Puis on retrouve le bénéfice lorsque le code doit évoluer sans faire tomber la moitié du site.

Le même décalage apparaît avec la configuration. Dans Drupal, de nombreux réglages peuvent être exportés et versionnés. Cela permet de synchroniser plus proprement le développement, la recette et la production. Une modification réalisée sur une interface d’administration ne devrait pas rester une décision invisible dans une base de données: elle doit pouvoir être identifiée, transportée et réappliquée.

Twig impose une frontière plus nette avec la présentation

Le moteur Twig change aussi les habitudes. Les templates ne doivent pas devenir des endroits où l’on recode toute la logique métier à coups de conditions imbriquées. La présentation reçoit des données préparées en amont et se concentre sur le rendu.

Là encore, les développeurs PHP connaissent déjà le principe général. Mais la migration est l’occasion de regarder les anciens thèmes WordPress avec un peu de lucidité. Les boucles qui contiennent des requêtes, des transformations de chaînes, des conditions SEO et des exceptions héritées ont parfois survécu uniquement parce que personne n’osait y toucher. Les déplacer tels quels dans Drupal ne constitue pas une modernisation. C’est du portage de legacy avec un nouveau logo.

Le bon réflexe consiste à distinguer:

• ce qui relève du modèle de contenu;
• ce qui appartient à la configuration;
• ce qui doit devenir un service ou un plugin;
• ce qui concerne uniquement l’affichage;
• ce qui peut être supprimé parce qu’il répondait à une contrainte disparue.

C’est là que la migration devient une refacto réelle. Pas une simple conversion WordPress Drupal, mais une occasion de retirer des dépendances historiques et de clarifier les responsabilités.

Comment industrialiser une migration vers Drupal 10 ou Drupal 11?

Le contexte de Drupal renforce cette nécessité de moderniser. La fin du support officiel de Drupal 7 en janvier 2025 a accéléré les projets de sortie des versions anciennes. Les migrations vers Drupal 10 et Drupal 11 s’inscrivent désormais dans une logique de pérennité: on ne déplace pas seulement un site, on évite de recréer une dépendance à une génération bientôt dépassée.

Pour une équipe PHP, cela signifie que les outils de migration doivent être traités comme du code de production. Ils méritent une arborescence claire, des revues, des journaux d’exécution et des tests. Le script temporaire qui devait servir une seule fois finit très souvent par être relancé pour l’environnement de recette, la préproduction, le correctif des médias puis le déploiement final. Autant lui donner une vraie structure dès le départ.

Un déroulement en plusieurs passes

Une migration fiable se construit rarement en un seul import massif. On avance plutôt par passes, chacune ayant un objectif précis.

La première passe est celle de l’audit.

On observe la base WordPress, les extensions, les types de contenu, les taxonomies, les utilisateurs, les fichiers et les URL. Il faut repérer les doublons, les champs vides, les contenus orphelins et les données produites par des extensions qui ne seront pas conservées.

La deuxième passe concerne la modélisation Drupal.

On définit les types de contenu, les champs, les médias, les vocabulaires et les relations. C’est ici que l’on décide si une ancienne métadonnée devient un champ réel, une configuration, une référence ou rien du tout.

La troisième passe importe un échantillon.

Quelques contenus représentatifs suffisent pour détecter les problèmes de caractères, de formats de date, d’images, de liens et de rendu. Importer toute la base avant de vérifier le modèle est une manière très efficace de fabriquer beaucoup de données incorrectes.

La quatrième passe traite les cas particuliers.

Les shortcodes, les contenus multilingues, les utilisateurs sans adresse valide, les médias absents et les anciennes URL demandent souvent des transformations spécifiques. Ils ne doivent pas être noyés dans une règle générale impossible à maintenir.

La cinquième passe mesure la qualité du résultat.

On compare le nombre de contenus, la répartition par type, les taxonomies, les médias, les auteurs et les statuts. On contrôle également les erreurs de migration, les entités ignorées et les références non résolues.

La dernière passe prépare le basculement.

Elle inclut la synchronisation des contenus créés sur WordPress depuis le dernier import, la mise en place des redirections, la vérification des tâches planifiées et la stratégie de retour arrière.

Cette organisation paraît moins spectaculaire qu’un bouton intitulé Migrer maintenant. Elle est surtout beaucoup plus efficace lorsque le bouton imaginaire ne fait pas ce qu’on espérait.

Les commandes et les journaux font partie du produit

Une migration automatisée doit laisser des traces exploitables. Pour chaque exécution, on doit pouvoir savoir combien d’éléments ont été lus, transformés, importés, ignorés ou rejetés. Les erreurs doivent inclure suffisamment de contexte pour retrouver la donnée en cause.

Les identifiants d’origine sont particulièrement utiles. Ils permettent de relancer une migration ciblée, d’identifier un doublon et de construire une table de correspondance entre WordPress et Drupal. Sans eux, le diagnostic repose rapidement sur des recherches approximatives dans les titres et les dates. Cela fonctionne jusqu’au jour où deux articles portent le même titre. Évidemment, ce jour arrive.

La migration doit également être idempotente autant que possible: relancer le traitement ne doit pas créer une nouvelle copie de chaque entité. La gestion des identifiants sources, des mises à jour et des dépendances est essentielle pour obtenir ce comportement.

Et les extensions WordPress?

La comparaison extension contre module Drupal est tentante, mais rarement suffisante. Une extension WordPress peut avoir plusieurs rôles: stockage de données, affichage, administration, optimisation, collecte de statistiques ou modification du comportement éditorial. Dans Drupal, ces responsabilités peuvent être réparties entre la configuration, un module contribué, un module personnalisé et le thème.

Il faut donc établir une équivalence fonctionnelle plutôt qu’une liste de remplacements.

Un constructeur de pages ne se traduit pas forcément par un autre constructeur de pages. Il peut être préférable de remodéliser les composants éditoriaux avec des paragraphes ou des blocs. Une extension SEO ne doit pas entraîner le transfert aveugle de toutes ses métadonnées si le nouveau site possède une stratégie différente. Un système de champs personnalisés peut devenir une modélisation Drupal plus propre, avec des types et des relations explicites.

Le développeur PHP qui connaît WordPress possède ici un avantage: il sait déjà lire du code, suivre un cycle de publication et diagnostiquer une extension mal intégrée. Mais il doit accepter de ne pas chercher une copie exacte de son environnement précédent. Drupal n’est pas WordPress avec un autre tableau de bord. Cette phrase a fait le tour des communautés, et elle reste désespérément exacte.

Le vrai retour d’expérience: que retenir du cas de Marc?

L’intérêt du parcours de Marc ne réside pas dans une durée ou un budget précis — ces éléments dépendent du volume, des extensions, des utilisateurs et du niveau de dette technique. Il se trouve dans la nature des problèmes rencontrés.

La première leçon est que la compétence PHP ne suffit pas à maîtriser immédiatement l’architecture Drupal. Elle facilite la lecture du code et l’apprentissage des concepts, bien sûr. Mais l’injection de dépendances, les entités, la configuration et Twig forment un ensemble cohérent qu’il faut comprendre comme tel.

La deuxième leçon concerne les outils de conversion WordPress Drupal. Ils accélèrent le travail, surtout pour les structures standard. Ils ne remplacent pas l’audit, la modélisation et les tests. Une API de migration est un cadre d’automatisation, pas une machine à deviner les intentions historiques d’un site.

La troisième porte sur les mots de passe. Les utilisateurs ne sont pas une ligne parmi d’autres dans un tableau d’import. Le passage de PHPass vers le mécanisme cible doit être décidé tôt, documenté et testé. Une réinitialisation assumée vaut mieux qu’une promesse de continuité impossible à tenir.

La quatrième concerne les URL. Le référencement se gagne parfois dans des choix très peu visibles: un alias conservé, une redirection exacte, un lien interne corrigé, un fichier qui ne renvoie plus vers un ancien répertoire. La migration technique et la migration SEO avancent ensemble, qu’on le veuille ou non.

Enfin, la cinquième leçon est presque une philosophie de développement: il faut profiter du changement de CMS pour supprimer ce qui n’a plus de raison d’exister. Reproduire chaque ancienne extension, chaque champ obsolète et chaque convention de nommage revient à installer le passé dans une nouvelle maison. Avec de la chance, il trouvera quand même le chemin de la production.

Vers quoi évoluent les migrations PHP?

Les migrations vers Drupal 10 et Drupal 11 vont probablement devenir plus outillées, plus déclaratives et plus intégrées aux pratiques de déploiement modernes. L’import ponctuel réalisé sur une machine locale laissera progressivement la place à des pipelines capables de rejouer les transformations, de contrôler les écarts et de produire des rapports.

Ce mouvement est déjà cohérent avec l’évolution générale de l’écosystème PHP: dépendances gérées proprement, tests automatisés, configuration versionnée, intégration continue et environnements reproductibles. Les migrations ne sont plus seulement des opérations exceptionnelles. Elles deviennent une compétence d’ingénierie à part entière.

Pour les développeurs WordPress, l’enjeu n’est pas d’abandonner leurs réflexes du jour au lendemain. Il est de comprendre ce qu’ils traduisent dans Drupal: quel est le modèle de contenu, où vit la logique, comment les services sont assemblés, comment les données sont versionnées et comment le système évolue sans accumuler une nouvelle couche de dette.

Pour les équipes Drupal, l’enjeu est inverse: ne pas traiter l’héritage WordPress avec condescendance. Un site WordPress peut contenir des années de décisions éditoriales, de contraintes métier et de contenu utile. Le travail consiste à préserver cette valeur tout en reconstruisant une base plus saine.

La migration WordPress vers Drupal pour des développeurs PHP n’est donc ni un simple export, ni une conversion automatique, ni un duel de chapelles techniques. C’est une traduction d’architecture, de données et d’usages. Elle demande de la méthode, un peu de patience et une tolérance raisonnable aux surprises du legacy.

Et c’est précisément ce qui la rend intéressante. On part d’un CMS connu, on traverse ses habitudes, ses extensions et ses vieux raccourcis, puis on arrive dans un Drupal plus explicite, plus structuré, parfois plus exigeant. Le prochain défi sera de rendre ces migrations suffisamment reproductibles pour qu’elles cessent d’être des opérations héroïques. Dans une communauté PHP qui aime encore un peu trop les héros du dernier déploiement, ce serait déjà un progrès spectaculaire.