Checklist migration Drupal

Une migration Drupal réussie ne se joue pas le jour de la bascule. Elle se prépare en amont, s'exécute avec méthode et se sécurise dans les semaines qui suivent le lancement. Que vous passiez d'une version majeure à la suivante, que vous changiez d'hébergeur ou que vous refondiez en profondeur votre architecture, le risque principal n'est jamais technique au sens strict : c'est l'oubli. Un module non remplacé, une redirection manquante, un backup non testé. Chacun de ces angles morts peut transformer un projet maîtrisé en incident de production.

Cette checklist couvre les trois phases d'une migration Drupal : la pré-migration (préparer et cartographier), la migration elle-même (exécuter et valider) et la post-migration (surveiller et stabiliser). Chaque item est accompagné d'une explication courte pour comprendre pourquoi il compte. L'objectif n'est pas de tout faire dans l'ordre mécaniquement, mais de disposer d'une grille de référence pour vérifier qu'aucun chantier critique n'a été laissé de côté.

Phase 1 : la pré-migration

C'est la phase qui détermine le succès du reste. Une migration bien préparée est une migration sans surprise. Tout le temps investi ici est récupéré au centuple le jour de la bascule.

Réaliser un audit complet de l'existant. Avant de toucher quoi que ce soit, il faut savoir précisément ce qu'on migre. Un audit Drupal recense la version actuelle, les modules contrib et custom, les thèmes, les intégrations tierces, la dette technique et les points de fragilité. C'est la cartographie sans laquelle on avance à l'aveugle. C'est aussi l'occasion de décider ce qui mérite d'être migré et ce qui peut être abandonné.

Inventorier les modules et leur compatibilité. Chaque module contrib doit être vérifié : existe-t-il une version compatible avec la cible ? Est-il toujours maintenu ? A-t-il un remplaçant désormais intégré au core ? Les modules custom demandent une attention particulière, car personne d'autre que vous ne les portera.

Auditer le thème et le front. Un thème custom hérité de plusieurs versions antérieures peut représenter une part importante du travail. Identifiez les templates, les préprocesseurs et les dépendances front (librairies JavaScript, build assets) à porter ou à reconstruire.

Cartographier le contenu et les types de données. Combien de types de contenu, de champs, de taxonomies, de vues, de médias ? Le volume et la complexité du contenu déterminent la stratégie de migration des données. Les contenus orphelins ou obsolètes peuvent être nettoyés avant plutôt que migrés inutilement.

Lister les URLs et préparer le plan de redirections. Exportez l'ensemble des URLs actuelles indexées. Toute URL qui change doit faire l'objet d'une redirection 301 vers sa nouvelle adresse. C'est le point le plus souvent sous-estimé et celui qui a l'impact SEO le plus direct.

Documenter l'état SEO de référence. Avant la bascule, capturez les positions, le trafic organique, les pages les plus performantes et les balises en place (title, meta description, données structurées). Sans ce point de référence, impossible de mesurer l'impact réel de la migration après coup.

Définir une stratégie de backup vérifiée. Un backup qui n'a jamais été restauré n'est pas un backup, c'est une hypothèse. Sauvegardez la base de données, les fichiers et la configuration, puis testez au moins une restauration complète. C'est votre filet de sécurité absolu.

Valider les contraintes et les délais. Identifiez les fenêtres de maintenance acceptables, les périodes à éviter (pics de trafic, campagnes en cours) et les parties prenantes à informer. Une migration technique réussie mais lancée au mauvais moment reste un problème.

Phase 2 : la migration

Cette phase doit se dérouler dans un environnement maîtrisé, jamais directement en production. L'enjeu : exécuter, valider chaque étape et garder à tout moment la possibilité de revenir en arrière.

Monter un environnement de staging fidèle. La migration se construit et se répète sur un environnement de staging qui reproduit la production : même version de PHP, même configuration serveur, mêmes données (anonymisées si nécessaire). C'est là que vous découvrez les problèmes, pas en production.

Migrer la configuration avant le contenu. L'approche recommandée consiste à reconstruire proprement la configuration (Configuration Management) puis à importer le contenu par-dessus. Cela évite de traîner la dette de configuration de l'ancien site dans le nouveau.

Exécuter la migration des données par lots. Pour les gros volumes, l'API de migration de Drupal permet de traiter le contenu de façon incrémentale et reproductible. Validez sur un échantillon représentatif avant de lancer la migration complète. Vérifiez l'intégrité : champs, relations, médias et fichiers joints.

Porter et reconstruire le thème. Adaptez les templates et les préprocesseurs à la version cible, recompilez les assets front et vérifiez le rendu sur les gabarits principaux. Testez aussi le responsive et les composants interactifs.

Réinstaller et reconfigurer les modules. Activez les modules dans leur version compatible, reportez leur configuration et remplacez ceux qui n'ont pas de successeur direct. Documentez chaque décision de remplacement pour la traçabilité.

Mettre en place les redirections. Implémentez le plan de redirections 301 préparé en phase 1. Une redirection par URL modifiée, pas une redirection générique vers la page d'accueil qui détruirait le bénéfice SEO de chaque page.

Lancer les tests automatisés. Une suite de tests automatisés Drupal valide en quelques minutes que les parcours critiques fonctionnent sur la nouvelle version : pages qui chargent, formulaires qui s'envoient, authentification opérationnelle. Au moment d'une migration, ces tests jouent le rôle de tests de régression et sécurisent fortement la bascule. Complétez par une validation manuelle des parcours métier les plus sensibles.

Vérifier les performances et la sécurité. Contrôlez les temps de réponse, la configuration du cache, les en-têtes de sécurité et les permissions. Une nouvelle version mal configurée peut être plus lente ou plus exposée que l'ancienne.

Préparer un plan de rollback. Avant la bascule finale, définissez précisément comment revenir à l'état antérieur en cas de problème bloquant : restauration du backup, bascule DNS inverse, gel des écritures. Savoir reculer proprement permet d'avancer sereinement.

Phase 3 : la post-migration

Le lancement n'est pas la fin du projet, c'est le début de la phase de stabilisation. Les jours qui suivent la bascule sont ceux où les problèmes résiduels remontent. Une surveillance active à ce moment précis évite qu'un détail ne devienne une crise.

Activer le monitoring post-lancement. Surveillez les erreurs serveur (logs, 500), les pages en erreur (404 inattendues), les temps de réponse et la disponibilité. Mettez en place des alertes pour être prévenu avant vos utilisateurs. Les premières heures sont les plus critiques.

Contrôler les redirections en conditions réelles. Vérifiez que les redirections 301 fonctionnent sur les URLs réellement sollicitées. Surveillez les 404 dans les logs : chaque 404 récurrente signale une redirection oubliée à ajouter rapidement.

Soumettre le sitemap et surveiller l'indexation. Régénérez et soumettez le sitemap aux moteurs de recherche, puis suivez la réindexation. Une baisse temporaire de trafic est fréquente après une migration : c'est le suivi qui permet de distinguer une fluctuation normale d'un vrai problème à corriger.

Comparer au point de référence SEO. Reprenez les indicateurs capturés en phase 1 et comparez. Positions, trafic organique, pages clés : un écart anormal sur une page importante mérite une investigation immédiate, le plus souvent une redirection manquante ou une balise non reportée.

Valider le contenu et les médias. Parcourez un échantillon de contenus migrés pour confirmer que rien n'est cassé : images affichées, liens internes fonctionnels, mise en forme préservée. Les médias et les liens internes sont les premières victimes d'une migration approximative.

Conserver l'ancien environnement en lecture seule. Gardez l'ancien site accessible (hors production) pendant quelques semaines. C'est une référence précieuse pour comparer un comportement douteux ou récupérer une donnée oubliée.

Documenter et capitaliser. Consignez les décisions prises, les remplacements de modules, les particularités de configuration et les problèmes rencontrés. Cette documentation accélère la maintenance future et la prochaine migration majeure (Drupal 12, puis Drupal 13).

Planifier la maintenance continue. Une fois le site stabilisé, intégrez-le à un cycle de mises à jour régulier. Un site maintenu en continu sera bien plus simple à migrer la prochaine fois, et les tests automatisés mis en place lors de cette migration continueront de protéger chaque déploiement.

Une checklist, pas une recette unique

Aucune migration ne ressemble exactement à une autre. Un site éditorial à fort contenu, une application métier custom et un multi-site partageant un codebase ne posent pas les mêmes défis. Cette checklist est une grille de vérification à adapter à votre contexte, pas une procédure à dérouler aveuglément. Ce qui reste constant : préparer sérieusement, valider sur staging et surveiller après le lancement.

Si vous abordez une migration et que vous voulez sécuriser chaque phase, nous pouvons intervenir là où c'est utile : un audit en amont, l'exécution complète ou un accompagnement ponctuel en complément de votre équipe interne ou de votre prestataire habituel.

Une migration Drupal en vue ? Parlons de votre projet et construisons ensemble le plan qui sécurise chaque étape, de l'audit au monitoring post-lancement.