Migrer Drupal vers Drupal 10 : la méthode qui évite les mauvaises surprises
Passer à Drupal 10 n’est pas juste “mettre à jour le core”. Selon votre point de départ (Drupal 7, 8 ou 9), la stratégie change :
- Drupal 9 → 10 : c’est le cas le plus simple (upgrade technique).
- Drupal 8 → 10 : il faut d’abord passer proprement par Drupal 9.
- Drupal 7 → 10 : ce n’est pas un upgrade direct, c’est un projet de migration (reconstruction + transfert de contenus).
Si vous partez de zéro côté infra, commencez par une base propre : Installer Drupal avec Docker Compose (prod) (vous gagnerez du temps sur l’environnement de test et la reproductibilité).
1) Avant de migrer : clarifiez le périmètre (et ce qui ne migrera pas)
Une migration Drupal réussie commence par une décision simple : qu’est-ce qu’on garde, qu’est-ce qu’on jette, qu’est-ce qu’on reconstruit.
À cadrer très tôt :
- Types de contenus (et champs) réellement utilisés
- Taxonomies, menus, blocs
- Modules contrib indispensables
- Fonctionnalités “custom” (modules maison, hooks, intégrations)
- Thème : mise à jour possible ou refonte nécessaire
Côté performance, ça vaut le coup d’identifier les pages et parcours critiques (homepage, recherche, formulaires) : vous pourrez ensuite les vérifier après migration et éviter un go-live “à l’aveugle”. Pour compléter, voir aussi : Drupal lent : 15 causes + correctifs.
2) Préparez un environnement de staging “vrai” (sinon vous testez pour rien)
Le staging doit ressembler à la prod (même PHP, même DB engine/versions, même reverse proxy si possible).
Bonnes pratiques pragmatiques :
- Cloner la prod (code + DB + fichiers)
- Anonymiser les données sensibles si besoin
- Bloquer l’indexation (robots + basic auth)
- Activer des logs utiles (Nginx/Apache, PHP-FPM, Drupal)
Pour éviter les soucis en prod, prenez 10 minutes pour sécuriser l’exploitation : Drupal en production : sécurité (guide 2026).
3) Cas n°1 : Drupal 9 → 10 (upgrade “propre”)
Étape A — Vérifier la compatibilité (modules + code)
L’outil le plus simple pour commencer est Upgrade Status. Il vous sort une liste claire :
- modules compatibles
- modules compatibles après mise à jour
- modules non compatibles
- code custom à corriger
C’est aussi le bon moment pour vérifier Drush (souvent, une mise à niveau est nécessaire).
Étape B — Mettre à jour modules et dépendances
L’ordre qui fonctionne bien :
- Mettre à jour les modules contrib
- Corriger le custom
- Puis seulement monter Drupal core
Sur des projets “classiques”, la partie la plus longue n’est pas Drupal lui-même : ce sont les dépendances et les modules dont le maintien est incertain.
Étape C — Passer le core en Drupal 10
Exemple (à adapter à votre projet) :
composer require 'drupal/core-recommended:^10' \
'drupal/core-composer-scaffold:^10' \
'drupal/core-project-message:^10' \
--update-with-dependencies
composer update
drush updatedb
drush cr
Ensuite : tests fonctionnels + vérification des logs.
4) Cas n°2 : Drupal 8 → 10 (passage obligatoire par Drupal 9)
Drupal 10 est construit sur la base d’un Drupal 9 “nettoyé” : si vous êtes en Drupal 8, le chemin robuste est :
- Drupal 8 → dernière version supportée de Drupal 8
- Drupal 8 → Drupal 9 (en supprimant les dépréciations)
- Drupal 9 → Drupal 10
C’est typiquement ici que le staging et un déploiement reproductible (Docker/CI) vous font gagner des jours. Si vous n’avez pas de base, partez de : l’application Drupal sur adgents.cloud.
5) Cas n°3 : Drupal 7 → 10 (migration de contenus + reconstruction)
Il faut être très clair : on ne met pas “à jour” Drupal 7 vers Drupal 10. On installe Drupal 10, on reconstruit la structure (contenus, champs, vues, permissions), puis on migre les données.
Approche recommandée :
- Installer un Drupal 10 “cible” (types de contenus, champs, taxonomies, rôles)
- Faire un POC sur un sous-ensemble (ex: 2 types de contenus)
- Automatiser la migration avec l’API Migrate / outils adaptés
- Répéter jusqu’à obtenir un import reproductible
Un point souvent sous-estimé : la migration de Drupal 7 est aussi une opportunité pour supprimer des contenus obsolètes et améliorer votre SEO (URLs, redirections, structure).
6) Le plan de rollback : votre assurance anti-panique
Le rollback n’est pas un luxe : c’est une condition pour pouvoir basculer sereinement.
Concrètement, prévoyez :
- Un backup complet juste avant bascule (DB + fichiers)
- Un “point de retour” (snapshot disque + export DB)
- Une procédure de retour simple, écrite et testée
- Un critère de décision (qui décide de revenir en arrière, et quand)
Sur adgents.cloud, vous pouvez vous appuyer sur des backups automatisés (jusqu’à 1/h) + rétention longue, et ajuster CPU/RAM si la charge post-migration augmente : adgents.cloud.
7) Tests à faire avant le go-live (minimum viable)
Testez en priorité ce qui casse “en vrai” :
- Authentification + rôles
- Formulaires (contact, demandes)
- Recherche
- Envoi d’e-mails
- Upload média
- Redirections (si URLs changent)
- Perfs (TTFB, pages clés)
Et n’oubliez pas la partie sécurité (updates, permissions, headers) : Drupal en production : sécurité (guide 2026).
Une vidéo (FR) utile sur la migration Drupal 7 → 10
Pour voir un retour d’expérience concret (procédure, points d’attention, pièges), cette conférence est très bien :
L’option simple si vous voulez surtout un hébergement fiable
Si votre priorité est d’avoir un Drupal 10 stable, sauvegardé, et facile à faire évoluer, vous pouvez déployer rapidement via : Hébergement Drupal sur adgents.cloud.
Vous gardez :
- déploiement rapide
- facturation à l’heure
- stop/start
- backups automatiques (jusqu’à 1/h)
- rétention longue (jusqu’à 10 ans)
- scaling CPU/RAM à la demande
Résumé
- Drupal 9 → 10 : Upgrade Status, mise à jour modules/custom, puis upgrade core
- Drupal 8 → 10 : passer par Drupal 9
- Drupal 7 → 10 : reconstruire + migrer les contenus (projet à part entière)
- Dans tous les cas : staging réaliste + tests + rollback prêt
