Si vous avez passé du temps significatif avec TYPO3, vous savez que c'est une bête. Pas au mauvais sens -- c'est incroyablement puissant, surtout pour les grands sites d'entreprise européens avec des structures de contenu complexes, des configurations multilingues et des permissions granulaires. Mais il y a une prise de conscience croissante parmi les équipes gérant des installations TYPO3 : l'architecture monolithique les retient. Les développeurs frontend veulent utiliser React ou Vue. Les équipes marketing veulent la livraison de contenu omnicanal. DevOps veut des déploiements plus simples. Et tout le monde veut de meilleures performances.

C'est là que la migration vers un CMS headless intervient. J'ai traversé ce processus plusieurs fois -- en accompagnant des organisations de TYPO3 vers des architectures headless -- et je vais être honnête : ce n'est jamais aussi simple que le suggèrent les pages marketing des fournisseurs. Mais c'est absolument valable quand les conditions s'y prêtent. Ce guide couvre les vraies décisions, pièges et stratégies impliqués dans la migration de TYPO3 vers un CMS headless.

Table des matières

Migration de TYPO3 vers un CMS headless : Un guide pratique pour développeurs

Pourquoi les équipes quittent TYPO3

Soyons clairs : TYPO3 n'est pas un mauvais logiciel. C'est un logiciel mature, bien maintenu et avec une communauté dévouée, particulièrement en Allemagne, en Autriche et en Suisse. Mais il porte certaines contraintes architecturales qui deviennent douloureuses à grande échelle.

Friction de l'expérience développeur

Le système de templating de TYPO3 (Fluid) est puissant mais de niche. Trouver des développeurs connaissant Fluid, TypoScript et l'écosystème Extbase/TYPO3 devient de plus en plus difficile. La courbe d'apprentissage est abrupte et les jeunes développeurs préfèrent largement travailler avec des frameworks JavaScript. J'ai vu des calendriers d'embauche doubler parce que les équipes ne pouvaient pas trouver de développeurs compétents en TYPO3.

Limitations de performance

TYPO3 affiche les pages côté serveur via PHP. Bien que la mise en cache aide, vous êtes fondamentalement limité par le cycle de requête monolithique. La génération de site statique et le rendu en périphérie -- ce que les frameworks modernes font bien -- ne sont pas natifs à l'architecture de TYPO3. L'extension TYPO3 Headless (EXT:headless) existe et transforme TYPO3 en API, mais à ce stade vous maintenez un backend PHP qui fait de moins en moins le travail réel.

Défis de réutilisation du contenu

Le modèle de contenu de TYPO3 est centré sur les pages. Les éléments de contenu vivent sur les pages. Si vous avez besoin de livrer du contenu à une application mobile, un kiosque numérique, un système d'email et un site Web simultanément, le modèle de TYPO3 vous oppose de la résistance à chaque étape. Les plates-formes CMS headless traitent le contenu comme des données structurées dès le départ, rendant la livraison multi-canal naturelle plutôt que boulonnée.

Coût total de propriété

Exécuter TYPO3 signifie maintenir des serveurs PHP, gérer les mises à jour du noyau TYPO3 (ce qui peut être non trivial entre les versions majeures) et garder les extensions compatibles. Un CMS headless SaaS élimine la plupart des frais généraux d'infrastructure. Même les options headless auto-hébergées comme Strapi ou Directus nécessitent généralement moins d'effort opérationnel.

Quand la migration a vraiment du sens

Pas chaque site TYPO3 n'a besoin de devenir headless. Voici mon évaluation honnête :

Scénario Migrer ? Pourquoi
Simple site de présentation, 50 pages, une langue Probablement pas Surqualifié. TYPO3 fonctionne bien ici.
Site d'entreprise multilingue avec applications mobiles Oui Headless excelle pour la livraison omnicanal
E-commerce avec données produit complexes Oui Meilleure flexibilité frontend, intégrations API-first
Site avec des extensions TYPO3 lourdes (news, événements, formulaires) Peut-être Auditez d'abord les dépendances des extensions
Portail interne avec workflows backend TYPO3 Prudence Vous pourriez perdre des fonctionnalités de workflow difficiles à remplacer
L'équipe ne peut pas embaucher des développeurs TYPO3 Oui La durabilité compte plus que les fonctionnalités

La migration a le plus de sens quand vous planifiez déjà une refonte ou une mise à niveau de plateforme. Migrer purement pour des raisons techniques -- sans déclencheur commercial -- a souvent du mal à obtenir l'approbation du budget.

Choisir votre CMS headless

C'est là que les équipes se bloquent. Il existe des dizaines d'options CMS headless, et le bon choix dépend largement de votre situation spécifique.

Options de niveau entreprise

Contentful reste le leader du marché pour les CMS headless d'entreprise. Les tarifs commencent autour de 300 $/mois pour le plan Team et montent jusqu'aux tarifs d'entreprise personnalisés (généralement 2 000 à 10 000 $/mois selon l'utilisation). C'est mature, bien documenté et dispose d'excellents SDK. La modélisation du contenu est flexible, et la fonctionnalité Compose gère les cas d'usage de création de page auxquels les éditeurs TYPO3 sont habitués.

Sanity est mon préféré personnel pour l'expérience développeur. Le modèle de tarification est généreux -- le niveau gratuit gère de nombreux petits projets, et le plan Team à 15 $/utilisateur/mois est raisonnable. Sanity Studio est entièrement personnalisable avec React, vous pouvez donc construire des expériences éditoriales qui correspondent ou dépassent ce que l'interface backend de TYPO3 offre. Le langage de requête GROQ nécessite un certain apprentissage, mais c'est incroyablement puissant une fois que vous le maîtrisez.

Storyblok mérite une attention particulière pour les migrations TYPO3 car il offre un éditeur visuel qui se sent familier aux utilisateurs backend TYPO3. Les tarifs commencent à 99 €/mois pour le plan Entry. C'est particulièrement populaire dans la région DACH, qui chevauche largement la base d'utilisateurs de TYPO3.

Alternatives open-source

Strapi (v5 sortie en 2024) est l'option open-source leader. Vous pouvez l'auto-héberger ou utiliser Strapi Cloud (à partir de 29 $/mois par utilisateur). C'est basé sur Node.js, utilise une base de données PostgreSQL ou MySQL, et offre un écosystème de plugins qui se développe rapidement.

Directus enveloppe n'importe quelle base de données SQL avec une API et un panneau d'administration. C'est un excellent choix si vous voulez garder votre structure de base de données existante et migrer progressivement. La version open-source est entièrement fonctionnelle ; la version cloud commence à 99 $/mois.

Tableau de comparaison : Options de CMS headless pour la migration TYPO3

Fonctionnalité Contentful Sanity Storyblok Strapi Directus
Modèle d'hébergement SaaS SaaS + Auto-hébergé SaaS Auto-hébergé + Cloud Auto-hébergé + Cloud
Éditeur visuel Compose (add-on) Personnalisable Intégré Plugin Limité
Multilingue Excellent Bon Excellent Bon Bon
Prix de départ 300 $/mois Niveau gratuit 99 €/mois Gratuit (OSS) Gratuit (OSS)
Familiarité éditeur TYPO3 Moyen Faible Élevée Moyen Moyen
Modélisation du contenu Flexible Très flexible Basée sur les composants Flexible Basée sur les bases de données
Webhooks/Workflows Oui Oui Oui Oui Oui

Nous travaillons avec la plupart de ces plates-formes via nos services de développement CMS headless. Le choix dépend souvent de savoir si vos éditeurs ont besoin d'une expérience d'édition visuelle (Storyblok, Contentful Compose) ou si la flexibilité du développeur est la priorité (Sanity, Strapi).

Migration de TYPO3 vers un CMS headless : Un guide pratique pour développeurs - architecture

Modélisation du contenu : la partie difficile

C'est là que la plupart des migrations déraillent. Le modèle de contenu de TYPO3 est fondamentalement différent des modèles de contenu CMS headless, et vous ne pouvez pas simplement mapper l'un à l'autre.

Comprendre la structure du contenu TYPO3

Dans TYPO3, le contenu est organisé comme :

  • Pages (l'arborescence des pages) avec propriétés et métadonnées
  • Éléments de contenu (tt_content) positionnés dans les colonnes des pages
  • Extensions qui ajoutent des types d'enregistrements personnalisés (news, événements, etc.)
  • Catégories et références de fichiers liées via la table sys_file_reference
  • Configuration TypoScript qui affecte le rendu et le flux de données

C'est un modèle page-first. Le contenu existe dans le contexte d'une page.

Modélisation du contenu Headless

Les plates-formes CMS headless utilisent un modèle content-first. Vous définissez des types de contenu (comme Article, Author, Product) avec des champs, puis composez des pages à partir de références à ces éléments de contenu. La page elle-même est souvent juste un autre type de contenu.

Le travail de traduction ressemble à ceci :

Arborescence des pages TYPO3  →  Type de contenu page avec champs slug/hiérarchie
tt_content (texte)           →  Composant/bloc texte riche
tt_content (image)           →  Composant média avec références de ressources
tx_news_domain_model_news    →  Type de contenu Article/News
Catégories (sys_category)    →  Type de contenu Tags/Categories
Références de fichiers       →  Gestion des ressources (DAM)

Conseils pratiques

N'essayez pas de reproduire le modèle de contenu de TYPO3 dans votre CMS headless. C'est une occasion de repenser et d'améliorer votre architecture de contenu. Commencez par auditer :

  1. Quels types de contenu existent ? Exportez vos CTypes tt_content et listez tous les types d'enregistrements d'extension.
  2. Quels champs sont réellement utilisés ? Les tables TYPO3 ont des dizaines de champs. La plupart des contenus n'en utilisent que quelques-uns.
  3. Quelles sont les relations ? Cartographiez comment le contenu référence d'autre contenu.
  4. Quelle est la configuration de traduction ? TYPO3 supporte les modes de traduction connectée et libre -- votre CMS headless doit gérer celui que vous utilisez.
-- Requêtes d'audit TYPO3 utiles
-- Compter les éléments de contenu par type
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Compter les pages par doktype
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- Trouver toutes les langues en use
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Stratégies de migration des données

Une fois votre modèle de contenu défini dans le CMS cible, vous devez réellement déplacer les données. Il y a trois approches principales.

Approche 1 : Export/Import basé sur des scripts

Écrivez des scripts qui interrogent directement la base de données TYPO3, transforment les données et les poussent dans le CMS headless via son API de gestion. C'est l'approche la plus courante et vous donne le plus de contrôle.

// Exemple : Migration de dossiers de news TYPO3 vers Contentful
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`Migré : ${row.title}`);
  }
}

La fonction convertRteToRichText est là où les choses deviennent compliquées. La sortie RTE de TYPO3 est HTML (souvent avec des balises personnalisées comme <link> pour les liens internes). La conversion en formats de texte riche structurés varie selon le CMS -- Contentful utilise son propre JSON de texte riche, Sanity utilise Portable Text, etc.

Approche 2 : Extension TYPO3 Headless comme pont

Installez l'extension EXT:headless sur votre instance TYPO3 existante. Ceci transforme TYPO3 en une API JSON, que vous pouvez ensuite consommer à partir de scripts de migration ou même utiliser temporairement comme votre backend headless pendant que vous construisez le nouveau frontend.

Cette approche a un avantage sympa : vous pouvez d'abord exécuter le nouveau frontend contre l'API headless de TYPO3, puis basculer le backend vers un vrai CMS headless plus tard. Cela décompose la migration en deux phases.

Approche 3 : Récréation manuelle

Pour les sites plus petits (moins de 100 pages), c'est parfois plus rapide de simplement recréer manuellement le contenu dans le nouveau CMS. Surtout si vous restructurez et réécrivez également du contenu -- ce que vous devriez probablement faire.

Décisions d'architecture frontend

Avec un CMS headless, vous avez besoin d'un frontend séparé. C'est là que les vrais gains de performance se produisent.

Next.js

Le choix le plus populaire. Rendu côté serveur, génération statique, régénération statique incrémentielle -- Next.js gère toutes les stratégies de rendu dont vous pourriez avoir besoin. L'App Router (stable depuis Next.js 13.4) avec React Server Components est particulièrement bien adapté aux sites riches en contenu. Nous faisons beaucoup de ce travail via notre pratique de développement Next.js.

Astro

Pour les sites riches en contenu qui n'ont pas besoin de beaucoup d'interactivité, Astro est phénoménal. Il n'expédie zéro JavaScript par défaut et supporte l'hydratation partielle via son Architecture Islands. Nous avons vu les scores Lighthouse atteindre régulièrement 95+ avec les builds Astro, ce qui est une amélioration spectaculaire par rapport aux performances typiques du frontend TYPO3. Consultez nos services de développement Astro si cela vous intéresse.

Nuxt

Si votre équipe préfère Vue à React, Nuxt 3 est l'équivalent de Next.js. Bon choix, excellent DX, bon écosystème.

Framework Meilleur pour JS expédié Courbe d'apprentissage Intégrations CMS
Next.js Applications dynamiques, e-commerce, tableaux de bord Moyen-Élevé Moyen Excellent
Astro Sites de contenu, blogs, marketing Minimal Faible Excellent
Nuxt 3 Équipes Vue, contenu + applications Moyen Moyen Bon
SvelteKit Petites équipes cherchant la simplicité Faible Faible-Moyen En croissance

Gérer les fonctionnalités spécifiques à TYPO3

Certaines fonctionnalités de TYPO3 n'ont pas d'équivalents directs dans le monde headless. Voici comment gérer les courantes.

Espaces de travail et versioning

Le système d'espace de travail de TYPO3 permet aux éditeurs de mettre en scène les modifications sur plusieurs pages avant la publication. La plupart des plates-formes CMS headless offrent des environnements ou une planification de publication qui répliquent partiellement ceci. Contentful a les Environnements et la Publication planifiée. Sanity a les Releases (récemment lancé). Aucun n'est aussi sophistiqué que TYPO3 Workspaces prêt à l'emploi, donc si vos éditeurs s'appuient fortement sur les espaces de travail, planifiez des ajustements de workflow.

Permissions des utilisateurs backend

Le système de permission de TYPO3 est extrêmement granulaire -- contrôles d'accès au niveau de la page, de l'élément de contenu et du champ. Les plates-formes CMS headless varient considérablement ici. Le système de rôles de Contentful est décent mais moins granulaire. Celui de Sanity est plus flexible mais nécessite une configuration personnalisée. Le contrôle d'accès basé sur les rôles de Strapi est bon. Auditez votre matrice de permissions actuelle et validez que le CMS cible peut la gérer avant de vous engager.

Gestion des formulaires

La Framework Formulaires de TYPO3 (EXT:form) génère des formulaires à partir de la configuration YAML. Dans une configuration headless, vous aurez besoin d'un service de formulaires. Les options incluent Formspree, Basin ou construire votre propre avec des fonctions serverless. Si vous utilisez Next.js, les Server Actions rendent la gestion des formulaires simple.

Multilingue et localisation

C'est critique et souvent sous-estimé. La gestion des traductions de TYPO3 -- avec son concept de superpositions de langue, de modes connecté/libre et de chaînes de fallback -- est sophistiquée. Cartographiez vos exigences de traduction exactes avant de choisir un CMS. Storyblok et Contentful gèrent bien la gestion des paramètres régionaux. Sanity nécessite plus de configuration personnalisée pour les scénarios multilingues complexes.

Préservation du SEO pendant la migration

Cette section pourrait être la plus importante. Une migration ratée peut couler votre trafic organique.

Cartographie des URL

Exportez chaque URL de votre site TYPO3. Chaque. Seule. Une. Utilisez un crawler comme Screaming Frog ou wget --spider pour construire une liste d'URL complète. Ensuite, créez une carte de redirection :

/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf

Implémentez des redirections 301 pour chaque URL qui change. Dans Next.js, cela va dans next.config.js :

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... des centaines de plus, chargés à partir d'un fichier JSON idéalement
    ];
  },
};

Pour de grandes listes de redirection (500+), envisagez de gérer les redirections en périphérie (Vercel Edge Middleware, Cloudflare Workers ou nginx) plutôt que dans votre configuration d'application.

Migration des métadonnées

TYPO3 stocke les métadonnées SEO dans la table des pages (seo_title, description, og_image, etc.) et potentiellement dans des extensions comme EXT:cs_seo ou EXT:seo_basics. Extrayez tout cela et migrez-le vers votre modèle de contenu CMS headless. N'oubliez pas :

  • Titres de page et descriptions de métadonnées
  • Données Open Graph et Twitter Card
  • URLs canoniques
  • Tags hreflang pour les sites multilingues
  • Données structurées / schémas JSON-LD
  • Génération de sitemap XML

Monitoring

Configurez Google Search Console pour le nouveau domaine/sous-domaine avant la migration. Après la mise en ligne, surveillez le rapport Coverage quotidiennement pendant les deux premières semaines. Regardez les erreurs d'exploration, les pages perdues et les problèmes d'indexation. Ayez un plan de restauration.

Stratégie de test et de mise en ligne

Je recommande une approche par phases plutôt qu'un basculement big-bang.

Phase 1 : Exécution en parallèle (2-4 semaines)

Exécutez le nouveau site headless sur un domaine de staging. Comparez la parité du contenu avec le site TYPO3. Demandez aux éditeurs de tester les workflows de contenu. Exécutez les tests de régression visuelle automatisés avec des outils comme Percy ou Playwright.

Phase 2 : Lancement progressif

Routez un petit pourcentage du trafic vers le nouveau site en utilisant des feature flags ou des tests A/B au niveau du CDN. Surveillez les Core Web Vitals, les taux d'erreur et le comportement des utilisateurs.

Phase 3 : Basculement complet

Changez la configuration DNS ou reverse proxy. Activez toutes les redirections. Surveillez de manière agressive pendant 48 heures. Gardez l'instance TYPO3 en exécution (en lecture seule) pendant au moins 30 jours comme référence.

Phase 4 : Désaffectation

Une fois que vous êtes confiant que la migration est stable, arrêtez l'infrastructure TYPO3. Archivez la base de données et le répertoire fileadmin. Vous vous remercierez plus tard quand quelqu'un demandera du contenu ancien.

Calendrier réel et coûts de migration

Soyons honnêtes à ce sujet. J'ai vu trop d'équipes sous-estimer les projets de migration.

Taille du projet Pages Calendrier Coût estimé
Petit 50-200 6-10 semaines 15 000-35 000 $
Moyen 200-1 000 12-20 semaines 40 000-90 000 $
Grand 1 000-5 000 20-36 semaines 80 000-200 000 $
Entreprise 5 000+ 6-12 mois 150 000-500 000 $+

Ces chiffres incluent la modélisation du contenu, les scripts de migration, le développement frontend, les tests et le support de lancement. Ils n'incluent pas les coûts de licence CMS, qui varient selon la plateforme.

Les principaux facteurs de coût sont :

  1. Nombre de types de contenu et complexité -- pas un compte de pages brut
  2. Extensions TYPO3 personnalisées qui ont besoin que les fonctionnalités équivalentes soient construites
  3. Complexité de la configuration multilingue
  4. Exigences d'intégration (recherche, e-commerce, authentification)
  5. Formation éditoriale et gestion du changement

Si vous voulez discuter de ce qu'une migration pourrait ressembler pour votre configuration spécifique, contactez-nous ou consultez notre page de tarification pour les modèles d'engagement.

FAQ

Puis-je utiliser TYPO3 comme CMS headless au lieu de migrer vers un nouveau ?

Oui, l'extension EXT:headless (autrefois "headless") transforme TYPO3 en une API JSON. Cela peut être une bonne étape intermédiaire. Cependant, vous maintenez toujours un backend TYPO3 avec tous ses frais généraux opérationnels. C'est logique comme stratégie de pont mais n'est généralement pas la réponse à long terme si votre objectif est de réduire la dépendance à TYPO3.

Combien de temps prend une migration typique de TYPO3 vers un CMS headless ?

Pour un site de taille moyenne (200-1 000 pages), attendez-vous à 3-5 mois à partir du coup d'envoi jusqu'à la mise en ligne. Les phases de modélisation du contenu et de migration de scripts prennent généralement plus longtemps que les équipes l'anticipent. Le développement frontend peut souvent s'exécuter en parallèle une fois le modèle de contenu défini. Les migrations d'entreprise avec plusieurs langues et intégrations complexes peuvent prendre 6-12 mois.

Vais-je perdre les classements SEO pendant la migration ?

Vous ne devriez pas si vous le faites correctement. Les facteurs critiques sont : implémenter les redirections 301 appropriées pour toutes les URL modifiées, migrer tous les métadonnées, maintenir la structure de votre site et la liaison interne, et soumettre les sitemaps mis à jour à Google. Une chute temporaire des classements de 2-4 semaines post-migration est normale et se rétablit généralement. Les pertes permanentes indiquent généralement des redirections manquées ou du contenu perdu.

Quel CMS headless est le meilleur pour remplacer TYPO3 ?

Cela dépend de vos priorités. Storyblok est souvent la transition la plus fluide pour les éditeurs TYPO3 en raison de ses capacités d'édition visuelle. Contentful est le choix d'entreprise le plus sûr avec l'écosystème le plus mature. Sanity offre la flexibilité de développeur la plus élevée. Strapi est la meilleure option si vous avez besoin de l'open source et de l'auto-hébergement. Il n'y a pas de meilleure réponse unique -- cela dépend de votre équipe, de votre budget et de vos exigences.

Que se passe-t-il avec mes extensions TYPO3 après la migration ?

Chaque extension doit être évaluée individuellement. Les extensions courantes comme EXT:news, EXT:cal et EXT:powermail ont besoin que les fonctionnalités équivalentes soient créées dans votre nouvelle pile. La fonctionnalité News/blog est simple à répliquer avec n'importe quel CMS headless. Les fonctionnalités Calendar et event pourraient avoir besoin de services tiers. Les formulaires nécessitent une nouvelle solution (constructeurs de formulaires, fonctions serverless ou services comme Formspree). Les extensions personnalisées ont besoin de l'analyse la plus approfondie.

Comment gérer les ressources fileadmin de TYPO3 pendant la migration ?

Vous devrez migrer tous les assets (images, PDF, vidéos) vers le système de gestion des assets du nouveau CMS ou un DAM/CDN séparé. Écrivez un script qui télécharge depuis fileadmin, charge vers la nouvelle plateforme via son API et mappe les anciennes références de fichiers aux nouveaux ID d'assets. N'oubliez pas de gérer les images traitées/redimensionnées -- la plupart des plates-formes CMS headless gèrent la transformation d'images automatiquement, vous devez donc généralement uniquement migrer les originaux.

Puis-je migrer progressivement ou cela doit-il être tout à la fois ?

La migration progressive est possible et parfois recommandée pour les grands sites. Vous pouvez utiliser un reverse proxy pour router certains chemins d'URL vers le nouveau frontend headless tout en gardant d'autres sur TYPO3. Cela vous permet de migrer section par section. Le compromis est une complexité accrue dans la gestion de deux systèmes simultanément et le maintien d'une navigation et d'une conception cohérentes sur les deux.

Que devrais-je faire à propos des utilisateurs backend TYPO3 qui sont résistants au changement ?

La gestion du changement est véritablement la moitié du combat. Commencez en impliquant les éditeurs tôt -- montrez-leur le nouveau CMS pendant la phase de modélisation du contenu, pas après que tout soit construit. Choisissez un CMS avec une bonne expérience d'édition (Storyblok et Contentful ont tendance à obtenir les meilleurs commentaires des éditeurs). Créez la documentation et les matériaux de formation spécifiques à votre configuration. Et soyez honnête à propos de ce qui change et pourquoi -- les éditeurs viennent généralement autour quand ils voient la meilleure expérience d'aperçu et les workflows de publication plus rapides.