La Migration Drupal n’est plus un sujet théorique depuis la fin de vie de Drupal 7. Entre évolutions de sécurité, nouvelles APIs et changements d’architecture, un simple clic sur « mise à jour Drupal » ne suffit plus. Un site un peu chargé, avec ses modules, ses intégrations et ses contenus éditoriaux, peut se retrouver en erreur 500 ou avec un back-office inutilisable en quelques secondes. Ce qui fait la différence, ce n’est pas l’outil en lui-même, mais la façon dont l’équipe prépare le changement de version, anticipe la compatibilité Drupal et planifie les tests.
Pour une DSI, un CTO ou une équipe web, la question n’est plus « faut-il migrer ? », mais « comment faire sans casser le site, ni exploser le budget, ni bloquer les équipes éditoriales pendant des semaines ». Les bonnes pratiques Drupal autour de la migration ne sont pas des détails théoriques : elles structurent le projet, conditionnent la qualité des données migrées et l’acceptation des utilisateurs. C’est d’autant plus vrai avec le saut entre Drupal 7 et les versions modernes type Drupal 10 ou 11, qui s’apparente à une reconstruction sur une nouvelle base technique plutôt qu’à une simple montée de version.
Cet article prend le sujet par le terrain : comment une organisation moyenne, du type PME ou institution, peut organiser une préparation migration propre, définir une architecture cible réaliste, sécuriser la gestion des modules et maîtriser les tests après migration. Pour éclairer les enjeux, l’itinéraire d’un site fictif, « CampusNord », sert de fil rouge. Ce portail universitaire sous Drupal 7 doit passer sur Drupal 11 : multilingue, quelques centaines de types de contenus, beaucoup de formulaires et un service communication qui ne veut surtout pas perdre ses habitudes.
- ✅ Pourquoi migrer avant que le CMS ne soit hors support, et ce que cela implique côté sécurité Drupal 🔐
- 🧩 Différences architecturales entre anciennes et nouvelles versions, avec impact direct sur la compatibilité des modules
- 🧱 Méthodes de préparation (audit, tri des contenus, cartographie fonctionnelle) avant tout chantier de Migration Drupal
- 🧪 Stratégie de tests après migration pour éviter les surprises en prod
- 🚀 Optimisation du site après le basculement : performance, monitoring, petites itérations rapides
Migration Drupal et fin de vie des versions : pourquoi attendre est un mauvais calcul
Un point gêne régulièrement les décideurs : si le site tourne encore, pourquoi lancer un projet lourd de Migration Drupal maintenant ? La réponse tient en trois mots : support, sécurité, coût. Une version arrivée en fin de vie ne reçoit plus de correctifs. Chaque nouveau exploit rendu public transforme le site en porte d’entrée possible, même si tout semble stable en surface. À partir d’un certain moment, la sécurité Drupal repose essentiellement sur de la chance, ce qui n’est pas une stratégie professionnelle.
Sur « CampusNord », le site en Drupal 7 fonctionnait sans incident majeur depuis des années. Sauf qu’aucun patch critique n’était appliqué depuis longtemps, les modules communautaires ne bougeaient plus, et l’hébergeur commençait à pousser vers une version de PHP non compatible. Attendre davantage signifiait repousser le problème jusqu’à la mise hors ligne brutale. C’est typiquement la situation où une migration peut se transformer en urgence coûteuse.
Comprendre la différence entre mise à jour Drupal mineure et changement de génération
Une confusion revient souvent : tout le monde parle de « mise à jour Drupal », alors que le passage de Drupal 7 à Drupal 10 ou 11 ressemble bien plus à un changement de plateforme. Entre PHP procédural et Symfony orienté objet, Twig, Composer, nouvelle gestion de configuration et APIs modernes, la marche technique est haute. Imaginer ce passage comme un simple bouton de mise à jour dans l’admin conduit droit dans le mur.
Pour clarifier les choses auprès des équipes métier, un tableau comparatif pragmatique aide beaucoup. Il montre noir sur blanc ce qui change pour les développeurs, mais aussi pour les éditeurs de contenu et les responsables marketing.
| Aspect 🔍 | Ancienne génération Drupal | Drupal 10/11 moderne |
|---|---|---|
| Base technique | PHP procédural, hooks dispersés | Symfony, services, POO, Composer 📦 |
| Thèmes | PHPTemplate avec logique dans les templates | Twig sécurisé, meilleure séparation front/back 🎨 |
| Configuration | En base uniquement, difficile à versionner | YAML exportable, Git-friendly pour les équipes 👥 |
| API et intégrations | REST limité, beaucoup de bricolage | REST, JSON:API, GraphQL possible, approche API-first 🔗 |
| Tests et qualité | Tests sporadiques, peu de standard | Intégration avec PHPUnit, Behat, CI/CD plus simple ✅ |
Pour une équipe habituée à manipuler un CMS « monolithique », ce virage peut faire peur. Pourtant, il ouvre la porte à des pratiques de développement bien plus solides, proches de ce qu’on trouve dans d’autres univers PHP. Pour un lecteur qui vient de Joomla, le choc est d’ailleurs moins violent qu’il n’y paraît, comme montré dans le comparatif proposé dans cet article sur la comparaison Drupal / Joomla.
- 📌 Ne jamais vendre une migration majeure comme une simple mise à jour auprès des métiers.
- 🔐 Intégrer la sécurité Drupal au discours dès le départ pour justifier le budget.
- 💸 Comparer le coût des rustines annuelles avec celui d’un projet de refonte maîtrisé.
- 📅 Planifier la fenêtre de migration hors des pics d’activité (inscriptions, lancement de produits, etc.).
Une fois que tout le monde a compris que le projet n’est pas une fantaisie technique, mais une assurance de continuité d’activité, la discussion devient plus rationnelle. C’est le bon moment pour se pencher sur l’architecture cible.
Préparer une Migration Drupal propre sans perdre le contrôle du projet
Une préparation migration bâclée entraîne systématiquement des dépassements de délai, des fonctions oubliées et des bugs en cascade au moment du basculement. À l’inverse, un audit sérieux du site existant, même sur quelques jours, fait gagner des semaines ensuite. Sur « CampusNord », l’équipe a commencé par une cartographie fonctionnelle très concrète : qui utilise quoi, à quelle fréquence, et pour quel résultat métier.
L’erreur classique consiste à partir des écrans du back-office et des listes de modules, sans parler aux utilisateurs réels. Un responsable de formation n’a pas la même vision du site qu’un développeur, et c’est précisément ce croisement de regards qui évite de migrer des fonctionnalités mortes depuis longtemps.
Audit fonctionnel, technique et contenu avant le changement de version
Un audit efficace n’a pas besoin d’un document de 100 pages, mais doit couvrir trois axes distincts : le fonctionnel, la technique et le contenu. Chacun éclaire un pan différent du futur chantier de Migration Drupal. Le but est de réduire l’inconnu, pas de tout spécifier jusqu’au dernier pixel.
| Type d’audit 🧭 | Objectif principal | Livrables utiles pour la migration |
|---|---|---|
| Fonctionnel | Comprendre qui fait quoi avec le site | Carte des parcours clés, priorisation des fonctionnalités ⚙️ |
| Technique | Identifier modules, intégrations, contraintes d’hébergement | Liste des modules à garder/remplacer, besoins en refonte 🔁 |
| Contenu | Évaluer la qualité et la quantité de contenus | Stratégie d’archivage, nettoyage, conventions éditoriales 🧹 |
- 🧩 Lister les types de contenu, taxonomies, vues, formulaires utilisés.
- 📂 Mesurer le volume de fichiers, images, médias à migrer.
- 🌐 Identifier les langues, règles de traduction et besoins multilingues.
- 🔌 Référencer toutes les intégrations externes (CRM, SSO, analytics, ERP).
C’est aussi à ce moment-là que la gestion des modules doit être analysée sans complaisance. Les modules orphelins, non maintenus ou utilisés pour des broutilles deviennent des bombes à retardement lors du changement de version. Une revue inspirée de ce que l’on fait sur d’autres CMS, comme lors d’un tri d’extensions sur Joomla, aide beaucoup. Pour ceux qui ont déjà vécu ce genre de chantier, des retours comme ceux partagés dans cette analyse des évolutions de Drupal 8 donnent des repères sur les fonctionnalités désormais natives.
Prioriser ce qui doit vraiment survivre à la migration
Migrer aveuglément tout ce qui existe est l’assurance de transporter de la dette technique d’une version à l’autre. La règle appliquée sur « CampusNord » était simple : si personne ne peut justifier l’utilité d’un module ou d’une fonctionnalité, il est candidat à la suppression ou au remplacement par quelque chose de plus standard. Cette approche simplifie la compatibilité Drupal à gérer et réduit le nombre de cas particuliers.
Pour objectiver ces choix, une matrice « valeur métier » / « coût/complexité de migration » fonctionne bien. Ce n’est pas de la science exacte, mais cela permet de dire non à certaines demandes, en expliquant clairement pourquoi.
- 🔥 Éviter les effets catalogue : trop de fonctionnalités tuent l’expérience utilisateur.
- ⚖️ Arbitrer entre custom code et solutions natives ou contribuées modernes.
- 📉 Accepter que certaines habitudes soient revues si elles coûtent trop cher à conserver.
Une fois cette phase de tri réalisée, le projet gagne en clarté. Les développeurs savent où concentrer leurs efforts, les métiers voient quelles améliorations sont au programme, et tout le monde partage la même carte du futur site. Ce terrain clarifié prépare naturellement la question sensible de la compatibilité technique entre anciennes et nouvelles versions.
Compatibilité Drupal, modules et architecture : limiter les mauvaises surprises
Dès que l’on parle de compatibilité Drupal, tout le monde pense immédiatement aux modules. C’est logique, mais un peu réducteur. Le vrai sujet, ce sont les dépendances au sens large : modules contribués, thèmes, librairies front, intégrations, scripts maison dans les templates, tâches cron exotiques, etc. Dans un projet de Migration Drupal, chaque dépendance qui a été bricolée dans un coin finit par ressortir au pire moment.
Sur « CampusNord », plusieurs fonctionnalités clés reposaient sur des modules très spécifiques développés pour Drupal 7 et jamais portés vers les versions modernes. Plutôt que de chercher désespérément des équivalents stricts, l’équipe a accepté de reconstruire certaines briques à partir des APIs actuelles, parfois en combinant plusieurs modules plus simples.
Cartographier la gestion des modules avant d’écrire une ligne de code
Avant de foncer sur une installation neuve, la première étape consiste à établir une cartographie claire de la gestion des modules. Cela passe par la liste des modules activés, leurs versions, leur état de maintenance et surtout leur usage réel. Un module installé mais jamais utilisé ne mérite pas d’énergie. Un module critique mais non maintenu doit déclencher une réflexion approfondie.
| Module ou composant 🧱 | État dans l’ancienne version | Stratégie pour la nouvelle version |
|---|---|---|
| Module contrib actif | Maintenu mais vieux, dépendances floues | Recherche du portage, remplacement ou core feature équivalente 🔍 |
| Module custom | Code procédural, pas de tests | Réécriture en POO, services, tests unitaires ciblés 🧪 |
| Thème spécifique | PHPTemplate, logique métier dans les templates | Refonte Twig, extraction de la logique dans des modules dédiés 🎯 |
| Intégration externe | Connexion en base directe ou SOAP | API REST/JSON, middleware, sécurisation renforcée 🔐 |
- 🧮 Définir un score de criticité pour chaque module (de 1 à 5).
- 🧪 Tester séparément les modules sensibles sur un environnement pilote.
- 🧯 Documenter les dépendances externes (libs JS, scripts cron, jobs d’import).
Cette approche, assez proche de ce que l’on pratique sur d’autres CMS lors de migrations majeures, permet de limiter les effets domino. Quand un module tombe, on sait déjà ce qu’il impacte. Et si tout casse, les réflexes décrits dans des ressources comme ce guide de résolution d’erreur 500 restent utiles : logs, rollback, environnement de test propre.
Composer, Twig, APIs : accepter les nouveaux outils plutôt que contourner
Une partie de l’équipe technique aura parfois tendance à reproduire les habitudes passéistes au lieu d’adopter les pratiques modernes. Refuser Composer, insérer du PHP dans les templates ou contourner la configuration YAML sont des pistes rapides vers une dette technique nouvelle génération. Un projet de changement de version est justement l’occasion de poser des règles claires : gestion des dépendances via Composer, séparation stricte front/back, utilisation des APIs standardisées pour les imports, exports et intégrations.
Sur « CampusNord », l’arrivée d’outils comme Layout Builder et d’une meilleure gestion des médias a permis de supprimer plusieurs modules historiques, ainsi que des contournements front. Dans le même esprit, des pratiques décrites dans des contextes voisins, par exemple l’usage d’extensions de commentaires sur Joomla comme cComment, donnent des idées sur la façon de s’appuyer davantage sur les écosystèmes officiels plutôt que de tout réinventer « maison ».
- ✅ Adopter Composer pour toute nouvelle dépendance, même si cela demande une montée en compétence initiale.
- 🎨 Nettoyer les thèmes des bouts de code métier, les ramener dans des modules clairement versionnés.
- 📡 Standardiser les intégrations autour d’APIs propres plutôt que de connexions directes en base.
Une compatibilité bien pensée ne cherche pas à tout conserver à l’identique, mais à traduire chaque besoin sur les briques techniques actuelles. C’est cette vision qui facilite ensuite la phase de migration réelle des données et des fonctionnalités, que l’on va maintenant aborder.
Stratégie de Migration Drupal et tests après migration : passer en production sans se crisper
Une fois l’architecture cible dessinée et la gestion des modules clarifiée, vient le moment de passer au concret. C’est là que la rigueur de la méthode fait toute la différence. Une Migration Drupal qui se limite à un seul tir de migration à la veille de la mise en ligne finit presque toujours en nuit blanche. Une stratégie saine repose sur des itérations rapides, avec des cycles clairs : script de migration, exécution, contrôle, correction.
Pour « CampusNord », l’équipe a utilisé l’API Migrate, avec des modules comme migrate_plus et migrate_tools, en mettant au point progressivement des scripts reproductibles. Les premiers tests portaient sur un sous-ensemble des contenus : formations, actualités, événements. L’objectif n’était pas de tout réussir du premier coup, mais d’identifier rapidement les champs problématiques, les fichiers manquants, les doublons de taxonomies.
Organiser les cycles de migration et les environnements
Un projet bien tenu sépare toujours au moins trois environnements : développement, recette et production. Dans la pratique, un environnement de préproduction, au plus proche de la prod, se révèle vite indispensable pour les derniers tests après migration. Chaque environnement doit être géré avec un jeu de données cohérent, sans forcément tout recopier en permanence.
| Environnement 🌍 | Usage principal | Données et tests associés |
|---|---|---|
| Développement | Écriture des scripts, développement des modules | Sample de données représentatif, logs détaillés 🔧 |
| Recette / QA | Validation fonctionnelle par les métiers | Jeu de données plus large, tests de parcours utilisateurs 👀 |
| Préproduction | Répétition générale avant basculement | Copie quasi complète de la prod, scénarios de migration finale 🚦 |
- 🧪 Automatiser au minimum les migrations de contenus structurés (articles, pages, taxos).
- ⏱ Planifier une migration delta peu avant la mise en ligne pour rattraper les derniers contenus.
- 🧷 Documenter les scripts et les conserver dans le dépôt de code, pas dans des notes éparses.
Pour les données les plus délicates, un mix entre import automatisé et correction manuelle reste parfois la solution la plus pragmatique. Tenter de tout automatiser, y compris les exceptions rarissimes, peut coûter beaucoup plus cher que quelques heures de nettoyage ciblé.
Construire une vraie stratégie de tests après migration
Les tests après migration ne se limitent pas à « le site s’affiche, tout va bien ». Il s’agit de vérifier chaque fonction qui a un impact sur le business : formulaires de contact, tunnel de candidature, exports d’inscrits, back-office éditorial, recherche interne, droits d’accès. Un bon réflexe consiste à préparer des scénarios concrets à faire jouer par les utilisateurs eux-mêmes.
Sur « CampusNord », les scénarios principaux ont été joués par des référents métier : un responsable de formation qui publie une nouvelle fiche de cursus, une personne du service com qui planifie une actualité multilingue, un étudiant qui remplit un formulaire de demande d’information. Ces tests réels ont révélé des problèmes que ni les développeurs ni les testeurs internes n’avaient remarqués.
- 🧭 Écrire des cas de test simples mais complets pour chaque parcours clé.
- 📋 Vérifier les logs serveur et les messages d’erreur après chaque campagne de tests.
- 🔁 Corriger, rejouer les scripts de migration si des anomalies structurelles sont détectées.
Cette phase n’est pas du temps perdu, c’est une assurance de ne pas découvrir en prod que le processus d’inscription ou la génération de PDF ne fonctionne plus. Une fois ce socle validé, il reste un angle à ne pas négliger : la performance et l’optimisation du site après basculement.
Optimisation site et sécurité Drupal après migration : stabiliser et faire évoluer
Une fois le nouveau site en ligne, la tentation est grande de considérer la mission terminée. En réalité, c’est le début d’une nouvelle phase : stabilisation, optimisation site, durcissement de la sécurité Drupal et ajustements fonctionnels. Un site tout neuf qui rame ou qui consomme trop de ressources va vite demander autant de travail que l’ancien.
Pour « CampusNord », la première semaine après mise en ligne a été entièrement dédiée à l’observation : monitoring des temps de réponse, analyse des erreurs PHP, retours des utilisateurs, surveillance des logs de sécurité. En parallèle, des ajustements sur le cache, l’agrégation CSS/JS et le thème ont permis de gratter de précieuses millisecondes.
Performance, cache et observation continue
Les versions modernes de Drupal disposent d’outils de cache avancés, qui, bien configurés, réduisent énormément la charge serveur. Encore faut-il les utiliser correctement. Combiner cache dynamique, reverse proxy, éventuel CDN et bon paramétrage des pages très dynamiques demande un peu de méthode, mais les gains sont immédiats sur la perception utilisateur.
| Zone du site 🚀 | Optimisation possible | Bénéfice pour les utilisateurs |
|---|---|---|
| Pages éditoriales | Cache complet, CDN, agrégation CSS/JS | Affichage rapide, moindre charge serveur ⚡ |
| Formulaires | Cache limité, protection CSRF, validation côté serveur | Moins d’erreurs, meilleure robustesse 🔒 |
| Recherche interne | Indexation asynchrone, moteur dédié si besoin | Résultats pertinents, temps de réponse stables 🔍 |
- 📊 Mettre en place un monitoring simple (APM, logs, dashboards temps de réponse).
- 📉 Identifier les pages les plus coûteuses et les optimiser en priorité.
- ♻️ Planifier des itérations régulières plutôt qu’une grosse refonte de performance tous les trois ans.
Des réflexes issus d’autres écosystèmes PHP restent utiles ici. Sur des migrations Joomla par exemple, une mauvaise gestion du cache conduit vite à des erreurs 500 ou à des contenus périmés. Les conseils déjà partagés dans des articles de diagnostic, comme ceux sur les erreurs serveur ou les changements de version, gardent toute leur pertinence pour un site Drupal fraîchement migré.
Sécurité Drupal, gouvernance et roadmap post-migration
Un site en version moderne ne dispense pas de vigilance. La sécurité Drupal repose sur un triptyque simple : mises à jour régulières, surveillance et gouvernance. Après un gros changement de version, il est logique de mettre en place un contrat de maintenance ou une organisation interne claire : qui applique les mises à jour, à quelle fréquence, selon quel processus de test.
Pour « CampusNord », un cycle mensuel de maintenance a été instauré : revue des bulletins de sécurité, application des mises à jour mineures, tests ciblés sur les parcours critiques. En parallèle, une petite roadmap fonctionnelle permet d’intégrer des améliorations continues : nouveaux types de contenus, ajustements de workflows, refinement de l’UX. Cela évite que le site ne s’encrasse à nouveau pendant des années.
- 🛡 Définir un responsable sécurité et un process de traitement des alertes.
- 📆 Planifier dès le départ les futures mises à jour Drupal mineures, pour ne pas retomber dans l’urgence.
- 🧭 Aligner la roadmap fonctionnelle avec les possibilités offertes par la nouvelle version (Layout Builder, médias, APIs, etc.).
Pour les équipes qui gèrent plusieurs CMS côté parc applicatif, mettre en regard les pratiques entre systèmes aide à garder une cohérence globale. Comparer la gestion des cycles de version entre Drupal et Joomla par exemple, comme dans les analyses détaillées de ce comparatif CMS, permet de bâtir des processus transverses pour l’ensemble du parc web.
Cas d’usage complet : du Drupal 7 vieillissant à un site Drupal moderne optimisé
Pour terminer le parcours de « CampusNord », il est utile de regrouper les étapes clé sous forme de scénario. Cela parle davantage qu’une liste de principes abstraits. L’université part d’un Drupal 7 en fin de vie, avec des formulaires complexes, des contenus multilingues et des intégrations vers des systèmes d’inscription externe. La direction craint une panne grave en pleine période d’inscription, le service com veut moderniser l’interface, l’IT veut reprendre la main sur le code.
Le projet démarre par un audit rapide mais sérieux, qui met en lumière des dizaines de modules peu ou pas utilisés, et une quantité impressionnante de contenus obsolètes. Une équipe projet resserrée se met d’accord sur ce qui doit être conservé, réécrit ou abandonné. Le choix est fait de reconstruire sur Drupal 11, avec une architecture propre, plutôt que de tenter plusieurs petites mises à jour Drupal intermédiaires.
Étapes concrètes et apprentissages du projet
Après avoir défini la cible, l’équipe technique installe un environnement neuf, configure les premiers types de contenus et commence à écrire les scripts de migration. Les premiers essais sont loin d’être parfaits, mais ils révèlent les vrais problèmes : champs incohérents, fichiers manquants, taxonomies inutiles. Les métiers sont sollicités tôt pour tester les écrans d’édition, ce qui évite les mauvaises surprises plus tard.
| Phase du projet 📌 | Actions principales | Leçon retenue |
|---|---|---|
| Audit initial | Cartographie fonctionnelle et technique, tri des modules | Moins il y a de fonctionnalités inutiles, plus la migration est fluide ✂️ |
| Prototype | Création de quelques types de contenus, premières migrations | Les premiers essais servent surtout à comprendre les données 📚 |
| Migrations itératives | Affinage des scripts, correction des anomalies | Itérer plutôt que viser la perfection d’un coup 🎯 |
| Tests métiers | Scénarios concrets joués par les profils clés | Les utilisateurs repèrent des problèmes invisibles aux devs 👀 |
| Post-basculement | Monitoring, performance, petites améliorations continues | Un site vivant demande une attention régulière, pas ponctuelle 🔁 |
- 🧠 Impliquer les métiers tôt évite les rejets au moment du passage en production.
- 🛠 Documenter chaque décision techniques (remplacement de module, refonte de workflow).
- 🔄 Mettre en place un cycle de vie continu, pas un « one shot » qui laisse le site vieillir à nouveau.
Pour les équipes qui connaissent déjà les cycles de migration sur Joomla ou d’autres CMS, ce genre de scénario évoque forcément des souvenirs. Les démarches restent proches : on retrouve les mêmes pièges, les mêmes arbitrages entre code maison et fonctionnalités standards, les mêmes besoins de pédagogie auprès des métiers. Certains articles dédiés à Joomla, comme les analyses d’évolutions de version ou les guides de réparation en cas de plantage, peuvent d’ailleurs être transposés en partie à un contexte Drupal, comme on le voit dans des ressources croisées comme le changelog commenté de Drupal 8.
Au final, un projet de Migration Drupal bien mené n’est ni un sprint isolé ni une série de bricolages à chaud. C’est une opportunité de remettre à plat l’architecture, d’améliorer la performance, de moderniser les pratiques de développement et de clarifier la gouvernance. Les équipes qui prennent ce virage sérieusement se retrouvent avec un outil web qui ressemble davantage à une plateforme applicative robuste qu’à un simple site vitrine fragile.
Combien de temps prévoir pour une Migration Drupal 7 vers Drupal 10 ou 11 ?
La durée dépend fortement de la taille et de la complexité du site. Un site institutionnel moyen, avec plusieurs langues, une vingtaine de types de contenus et quelques intégrations externes, se situe souvent entre 4 et 8 mois de travail réel, incluant la préparation, les migrations itératives et les tests après migration. Les très petits sites vitrine peuvent descendre à 2 ou 3 mois, alors qu’un portail d’envergure, avec beaucoup de custom et de workflows, peut dépasser un an s’il est traité sérieusement.
Faut-il absolument passer par toutes les versions intermédiaires pour changer de version ?
Non, les migrations Drupal majeures entre 7 et 10/11 se font en général vers une installation neuve, en utilisant l’API Migrate. On ne fait pas une suite de mises à jour Drupal incrémentales comme sur d’autres CMS. Le contenu et une partie de la configuration sont migrés, mais le code et l’architecture sont reconstruits sur la version cible. C’est plus sain, même si cela demande plus de préparation.
Comment gérer les modules non compatibles ou abandonnés lors de la migration ?
La première étape consiste à identifier ces modules via un audit. Si un remplaçant moderne et maintenu existe, il est préférable de basculer dessus. Si ce n’est pas le cas, deux options restent sur la table : réécrire la fonctionnalité en module custom conforme aux bonnes pratiques Drupal actuelles, ou remettre en cause le besoin si son usage réel est marginal. Migrer coûte que coûte un module orphelin est rarement une bonne idée.
Quels sont les tests après migration à ne jamais oublier ?
Les parcours critiques sont prioritaires : formulaires de contact et d’inscription, création et publication de contenus, gestion des médias, recherche interne, droits d’accès par rôles. Il faut les tester à la fois côté front (utilisateurs finaux) et côté back-office (éditeurs, administrateurs). L’ajout de vérifications basiques sur les performances et les erreurs serveur pendant ces tests permet de repérer tôt les points faibles de l’optimisation site.
La migration est-elle le bon moment pour changer de CMS, par exemple passer de Drupal à Joomla ou WordPress ?
La question mérite d’être posée lors de chaque gros chantier. Si le site actuel souffre surtout d’un manque de clarté fonctionnelle, de contenus vieillissants ou d’une gouvernance floue, rester sur Drupal tout en modernisant l’architecture peut suffire. Si, en revanche, les besoins se rapprochent davantage d’un autre outil, un comparatif sérieux, comme celui proposé sur les différences entre Drupal et Joomla, peut orienter vers un changement de CMS. Dans tous les cas, le travail de préparation et d’audit reste largement le même.
