Ce qui casse en quittant Drupal, et quand il ne faut pas partir

Les migrations Drupal sont motivées par le coût de possession plutôt que par un défaut du site. Drupal est conçu pour les développeurs et suppose un investissement technique continu : mises à jour de sécurité, compatibilité des modules, et quelqu'un qui s'y connaisse. Les organisations qui partent font presque toujours le même arbitrage : moins de profondeur de personnalisation contre beaucoup moins de charge opérationnelle et bien plus d'autonomie pour ceux qui publient.

Le modèle de contenu se transpose, en grande partie

Drupal organise le contenu en types de nœuds avec champs et taxonomies. Webflow l'organise en collections avec champs et références. La traduction est assez directe pour que l'essentiel d'un modèle Drupal ait un équivalent évident sous Webflow, ce qui rend ces migrations plus prévisibles qu'elles n'en ont l'air.

Là où cela force, c'est la profondeur. Le modèle de références de Webflow est moins profond que celui de Drupal : hiérarchies de taxonomie profondes et structures de références très imbriquées doivent être simplifiées plutôt que recopiées. Cette simplification est une décision de contenu aux conséquences éditoriales, et sa place est dans l'audit, pas dans le chantier.

La machinerie éditoriale de Drupal n'a pas de contrepartie directe, et il faut être franc sur l'ampleur. États de modération. Validation multi-étapes. Historiques de révision avec retour arrière. Permissions assez fines pour donner à un éditeur l'accès à un champ d'un seul type de contenu. Ce n'est pas plus difficile sous Webflow. C'est absent.

La question utile est donc : pourquoi ce workflow existe-t-il ? S'il existe parce qu'un processus de conformité exige un validateur nommé avant toute publication, c'est un véritable bloqueur, à résoudre avant d'acter la migration et non à découvrir pendant la recette. S'il existe parce que quelqu'un l'a activé en 2014 et que personne ne l'a désactivé, la plupart des équipes ne le regrettent pas et certaines sont soulagées.

Quand rester sur Drupal

Tous les sites Drupal ne doivent pas déménager, et une agence qui ne le dit jamais ne mérite pas qu'on l'écoute sur ce sujet. Les cas où rester est le bon choix sont assez nets.

• Une chaîne de validation réglementée devant être prouvée. Si un auditeur doit voir qui a approuvé quoi et quand, il vous faut l'historique des révisions, et le reconstruire sur un CMS hébergé coûte plus que la maintenance que vous fuyiez.
• Un contenu très volumineux ou très relationnel. Le CMS de Webflow a des plafonds durs, et un catalogue à l'aise sous Drupal peut être structurellement impossible dans une collection.
• Des dizaines d'éditeurs aux permissions réellement différentes. Les rôles de Webflow sont grossiers en comparaison, et le contournement est un processus, pas un logiciel.
• Une application plutôt qu'un site. Si Drupal fait tourner une logique d'adhésion, des formulaires complexes ou des intégrations qui sont le produit, vous migrez un logiciel, pas du contenu.

Les sites Drupal qui migrent bien sont ceux où Drupal était le mauvais outil dès le départ. Ceux qui migrent mal sont ceux où c'était le bon outil et où l'équipe s'est simplement lassée.

La lassitude est une raison légitime d'y regarder, et ce n'est pas à elle seule une raison de partir. L'audit honnête répond à ceci : la charge de maintenance vient-elle de ce que Drupal est Drupal, ce qu'une migration corrige, ou de ce que le site fait réellement quelque chose de compliqué, ce qu'une migration ne fait que déplacer. La marche à suivre, si c'est le bon choix, est sur la page migration Drupal vers Webflow.