TYPO3 naar Headless CMS Migratie: Praktische Gids voor Ontwikkelaars
Als je al enige tijd met TYPO3 hebt gewerkt, weet je dat het een beest is. Niet op een slechte manier -- het is ongelooflijk krachtig, vooral voor grote Europese enterprise-sites met complexe content-structuren, meertalige setups en verfijnde permissies. Maar er groeit een groeiend besef onder teams die TYPO3-installaties beheren: de monolithische architectuur houdt hen tegen. Frontend-developers willen React of Vue gebruiken. Marketing-teams willen omnichannel content-delivery. DevOps wil eenvoudigere deployments. En iedereen wil betere performance.
Daar komt headless CMS-migratie om de hoek kijken. Ik ben dit proces meerdere keren doorlopen -- organisaties van TYPO3 naar headless-architecturen brengen -- en ik zal eerlijk zijn: het is nooit zo eenvoudig als de vendor-marketingpagina's suggereren. Maar het is absoluut het moeite waard wanneer de omstandigheden goed zijn. Deze gids behandelt de echte beslissingen, valkuilen en strategieën bij het migreren van TYPO3 naar een headless CMS.
Inhoudsopgave
- Waarom Teams TYPO3 Verlaten
- Wanneer Migratie Echt Zin Heeft
- Je Headless CMS Kiezen
- Content Modeling: Het Moeilijke Deel
- Data Migratie Strategieën
- Frontend Architectuur Beslissingen
- TYPO3-Specifieke Functies Hanteren
- SEO Behoud Tijdens Migratie
- Testen en Go-Live Strategie
- Real-World Migratietijdlijn en Kosten
- FAQ
Waarom Teams TYPO3 Verlaten
Laat me duidelijk zijn: TYPO3 is geen slechte software. Het is volwassen, goed onderhouden en heeft een toegewijde community, met name in Duitsland, Oostenrijk en Zwitserland. Maar het draagt bepaalde architectonische beperkingen met zich mee die op schaal pijnlijk worden.
Developer Experience Friction
Het TYPO3 templating-systeem (Fluid) is krachtig maar niche. Developers vinden die Fluid, TypoScript en Extbase/TYPO3's extension framework kennen wordt steeds moeilijker. De leercurve is steil en jongere developers geven overweldigend de voorkeur aan het werken met JavaScript-frameworks. Ik heb gezien dat wervingstijdlijnen verdubbelden omdat teams geen proficiënte TYPO3-developers konden vinden.
Performance Beperkingen
TYPO3 geeft pagina's server-side weer via PHP. Hoewel caching helpt, ben je fundamenteel beperkt door de monolithische request-cyclus. Statische site-generatie en edge-rendering -- het soort dingen dat moderne frameworks goed kunnen -- zijn niet ingeboren in TYPO3's architectuur. De TYPO3 Headless-extensie (EXT:headless) bestaat en maakt van TYPO3 een API, maar op dat moment onderhoud je een PHP-backend die steeds minder werk doet.
Content Reuse Uitdagingen
TYPO3's content-model is page-centric. Content-elementen bevinden zich op pagina's. Als je content tegelijkertijd naar een mobiele app, een digitale kiosk, een email-systeem en een website moet leveren, vecht TYPO3's model je op elk moment tegen. Headless CMS-platforms behandelen content als gestructureerde data vanaf het begin, waardoor multi-channel delivery natuurlijk is in plaats van ernaast geplakt.
Totale Eigendomskosten
Het runnen van TYPO3 betekent het onderhouden van PHP-servers, het beheren van TYPO3 core-updates (wat tussen grote versies niet-trivaal kan zijn) en het compatibility houden van extensies. Een headless SaaS CMS elimineert de meeste infrastructuuroverwegingen. Zelfs zelf-gehoste headless-opties zoals Strapi of Directus vereisen meestal minder operationele inspanning.
Wanneer Migratie Echt Zin Heeft
Niet elke TYPO3-site hoeft headless te worden. Hier is mijn eerlijke beoordeling:
| Scenario | Migreren? | Waarom |
|---|---|---|
| Eenvoudige brochuresite, 50 pagina's, één taal | Waarschijnlijk niet | Overkill. TYPO3 werkt hier prima. |
| Multi-language enterprise-site met mobiele apps | Ja | Headless schittert voor omnichannel delivery |
| E-commerce met complexe productdata | Ja | Betere frontend-flexibiliteit, API-first integraties |
| Site met veel TYPO3-extensies (news, events, forms) | Misschien | Audit extensionafhankelijkheden eerst |
| Intern portaal met TYPO3 backend-workflows | Voorzichtig | Je kunt workflow-features verliezen die moeilijk zijn om te vervangen |
| Team kan TYPO3 developers niet aannemen | Ja | Duurzaamheid is belangrijker dan functies |
De migratie heeft het meeste zin wanneer je al een redesign of platform-upgrade plant. Migreren puur om technische redenen -- zonder een business-trigger -- worstelt vaak met budgetgoedkeuring.
Je Headless CMS Kiezen
Dit is waar teams vast komen te zitten. Er zijn tientallen headless CMS-opties en de juiste keuze hangt sterk af van je specifieke situatie.
Enterprise-Grade Opties
Contentful blijft de marktleider voor enterprise headless CMS. De prijzen beginnen rond $300/maand voor het Team-plan en schalen naar aangepaste enterprise-prijzen (typisch $2.000-$10.000+/maand afhankelijk van gebruik). Het is volwassen, goed gedocumenteerd en heeft uitstekende SDK's. De content-modeling is flexibel en de Compose-feature behandelt page-building use-cases waar TYPO3-editors aan gewend zijn.
Sanity is mijn persoonlijke favoriet voor developer experience. Het prijsmodel is genereus -- de gratis laag behandelt veel kleine projecten en het Team-plan op $15/gebruiker/maand is redelijk. Sanity Studio is volledig aanpasbaar met React, dus je kunt editorial experiences bouwen die gelijk zijn aan of beter dan wat TYPO3's backend biedt. De GROQ-querytaal kost even wat gewenning, maar het is ongelooflijk krachtig eenmaal beheerst.
Storyblok verdient speciale aandacht voor TYPO3-migraties omdat het een visuele editor biedt die vertrouwd aanvoelt voor TYPO3 backend-gebruikers. De prijzen beginnen bij €99/maand voor het Entry-plan. Het is bijzonder populair in de DACH-regio, wat sterk overlapt met TYPO3's gebruikersbasis.
Open-Source Alternatieven
Strapi (v5 uitgebracht in 2024) is de toonaangevende open-source optie. Je kunt het zelf hosten of Strapi Cloud gebruiken (beginnend bij $29/maand per seat). Het is gebaseerd op Node.js, gebruikt een PostgreSQL- of MySQL-database en biedt een plugin-ecosysteem dat snel groeit.
Directus verpakt elke SQL-database met een API en admin-paneel. Het is een goede keuze als je je bestaande databasestructuur wilt houden en geleidelijk wilt migreren. De open-source versie is volledig uitgebreid; de cloud-versie begint op $99/maand.
Vergelijkingstabel: Headless CMS-Opties voor TYPO3-Migratie
| Functie | Contentful | Sanity | Storyblok | Strapi | Directus |
|---|---|---|---|---|---|
| Hosting-Model | SaaS | SaaS + Zelf-hosten | SaaS | Zelf-hosten + Cloud | Zelf-hosten + Cloud |
| Visuele Editor | Compose (add-on) | Aanpasbaar | Ingebouwd | Plugin | Beperkt |
| Multi-language | Uitstekend | Goed | Uitstekend | Goed | Goed |
| Startprijs | $300/mnd | Gratis laag | €99/mnd | Gratis (OSS) | Gratis (OSS) |
| TYPO3 Editor-Bekendheid | Gemiddeld | Laag | Hoog | Gemiddeld | Gemiddeld |
| Content Modeling | Flexibel | Zeer Flexibel | Component-gebaseerd | Flexibel | Database-driven |
| Webhooks/Workflows | Ja | Ja | Ja | Ja | Ja |
We werken met de meeste van deze platforms via onze headless CMS-ontwikkelingsdiensten. De keuze hangt vaak af van of jouw editors een visuele editing-ervaring nodig hebben (Storyblok, Contentful Compose) of dat developer-flexibiliteit de prioriteit is (Sanity, Strapi).
Content Modeling: Het Moeilijke Deel
Hier gaan de meeste migraties fout. TYPO3's content-model is fundamenteel anders dan headless CMS content-modellen en je kunt ze niet zomaar op elkaar afbeelden.
TYPO3's Content-Structuur Begrijpen
In TYPO3 is content georganiseerd als:
- Pagina's (de page tree) met eigenschappen en metadata
- Content-elementen (tt_content) gepositioneerd in kolommen op pagina's
- Extensies die aangepaste record-types toevoegen (news, events, etc.)
- Categorieën en file references gelinkt via de sys_file_reference-tabel
- TypoScript configuratie die rendering en data-flow beïnvloedt
Dit is een page-first model. Content bestaat in de context van een pagina.
Headless Content-Modeling
Headless CMS-platforms gebruiken een content-first model. Je definieert content-types (zoals Article, Author, Product) met velden en stelt vervolgens pagina's samen uit verwijzingen naar deze content-items. De pagina zelf is vaak gewoon een ander content-type.
Het vertaalwerk ziet er ongeveer zo uit:
TYPO3 Page Tree → Page content type met slug/hierarchy velden
tt_content (text) → Rich text component/block
tt_content (image) → Media component met asset-referenties
tx_news_domain_model_news → Article/News content type
Categories (sys_category) → Tags/Categories content type
File references → Asset management (DAM)
Praktisch Advies
Probeer niet TYPO3's content-model in je headless CMS na te bootsen. Dit is een kans om je content-architectuur opnieuw te bedenken en te verbeteren. Begin met auditing:
- Welke content-types bestaan er? Exporteer je tt_content CTypes en maak een lijst van alle extension record-types.
- Welke velden worden werkelijk gebruikt? TYPO3 tabellen hebben tientallen velden. De meeste content gebruikt er slechts een handvol.
- Wat zijn de relaties? Kaart uit hoe content naar ander content verwijst.
- Hoe ziet de vertaalsetup eruit? TYPO3 ondersteunt connected en free vertaalmodes -- je headless CMS moet hanteren wat je gebruikt.
-- Nuttige TYPO3 audit-queries
-- Tel content-elementen per type
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
-- Tel pagina's per doktype
SELECT doktype, COUNT(*) as count
FROM pages
WHERE deleted = 0 AND hidden = 0
GROUP BY doktype
ORDER BY count DESC;
-- Vind alle gebruikte talen
SELECT sys_language_uid, COUNT(*) as count
FROM tt_content
WHERE deleted = 0
GROUP BY sys_language_uid;
Data Migratie Strategieën
Eenmaal je content-model in het doel CMS is gedefinieerd, moet je daadwerkelijk de data verplaatsen. Er zijn drie hoofdbenaderingen.
Benadering 1: Script-Based Export/Import
Schrijf scripts die rechtstreeks TYPO3's database bevragen, de data transformeren en deze via zijn management API in het headless CMS duwen. Dit is de meest voorkomende benadering en geeft je de meeste controle.
// Voorbeeld: TYPO3 news-records naar Contentful migreren
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(`Migrated: ${row.title}`);
}
}
De convertRteToRichText functie is waar het rommelig wordt. TYPO3's RTE-output is HTML (vaak met aangepaste tags zoals <link> voor interne links). Het converteren ervan naar gestructureerde rich text-formaten verschilt per CMS -- Contentful gebruikt zijn eigen rich text JSON, Sanity gebruikt Portable Text, etc.
Benadering 2: TYPO3 Headless Extension als Brug
Installeer de EXT:headless extensie op je bestaande TYPO3-instantie. Dit maakt van TYPO3 een JSON API, die je vervolgens kunt gebruiken via migratatiescripts of zelfs tijdelijk als je headless backend terwijl je de nieuwe frontend bouwt.
Deze benadering heeft een aardig voordeel: je kunt de nieuwe frontend eerst tegen TYPO3's headless API draaien en vervolgens de backend later naar een echte headless CMS schakelen. Het breekt de migratie in twee fasen.
Benadering 3: Handmatig Recreëren
Voor kleinere sites (onder 100 pagina's), soms is het gewoon sneller om content handmatig in het nieuwe CMS opnieuw te maken. Vooral als je ook content herstructureert en herschrijft -- wat je waarschijnlijk toch zou moeten doen.
Frontend Architectuur Beslissingen
Met een headless CMS heb je een aparte frontend nodig. Dit is waar de echte performance-winsten plaatsvinden.
Next.js
De meest populaire keuze. Server-side rendering, statische generatie, incrementele statische regeneratie -- Next.js behandelt alle rendering-strategieën die je nodig zou kunnen hebben. De App Router (stabiel sinds Next.js 13.4) met React Server Components is bijzonder geschikt voor content-heavy sites. We doen veel van dit werk via onze Next.js-ontwikkelingspraktijk.
Astro
Voor content-heavy sites die niet veel interactiviteit nodig hebben, is Astro fenomenaal. Het verzendt standaard nul JavaScript en ondersteunt gedeeltelijke hydration via zijn Islands Architecture. We hebben Lighthouse-scores consistent zien raken 95+ met Astro-builds, wat een dramatische verbetering is ten opzichte van typische TYPO3 frontend-performance. Bekijk onze Astro-ontwikkelingsdiensten als dit je interesseert.
Nuxt
Als je team Vue prefereert boven React, is Nuxt 3 het equivalent van Next.js. Solide keuze, prima DX, goed ecosysteem.
| Framework | Best Voor | JS Verzonden | Leerkurve | CMS Integraties |
|---|---|---|---|---|
| Next.js | Dynamische apps, e-commerce, dashboards | Gemiddeld-Hoog | Gemiddeld | Uitstekend |
| Astro | Content-sites, blogs, marketing | Minimaal | Laag | Uitstekend |
| Nuxt 3 | Vue-teams, content + apps | Gemiddeld | Gemiddeld | Goed |
| SvelteKit | Kleine teams die eenvoud willen | Laag | Laag-Gemiddeld | Groeiend |
TYPO3-Specifieke Functies Hanteren
Sommige TYPO3-functies hebben geen directe equivalenten in de headless-wereld. Hier is hoe je de veelvoorkomende hanteert.
Workspaces en Versioning
TYPO3's workspace-systeem laat editors wijzigingen over meerdere pagina's voorbereiden voordat ze worden gepubliceerd. De meeste headless CMS-platforms bieden omgevingen of geplande publicatie die dit gedeeltelijk repliceren. Contentful heeft Environments en Scheduled Publishing. Sanity heeft Releases (onlangs gelanceerd). Geen ervan is uit de doos zo geavanceerd als TYPO3 Workspaces, dus als je editors sterk op workspaces vertrouwen, plan voor workflow-aanpassingen.
Backend Gebruikers Permissies
TYPO3's permissiesysteem is extreem verfijnd -- pagina-niveau, content-element-niveau, veld-niveau toegangscontroles. Headless CMS-platforms variëren enorm hier. Contentful's rolesysteem is behoorlijk maar minder verfijnd. Sanity's is flexibeler maar vereist aangepaste configuratie. Strapi's op rollen gebaseerde toegang is goed. Audit je huidige permissie-matrix en valideer dat het doel CMS het kan aan voordat je je vastlegt.
Form Handling
TYPO3's Form Framework (EXT:form) genereert formulieren uit YAML-configuratie. In een headless-setup heb je een form-service nodig. Opties zijn onder meer Formspree, Basin of het zelf bouwen met serverless functies. Als je Next.js gebruikt, maken Server Actions form-handling eenvoudig.
Meerdere Talen en Lokalisatie
Dit is kritiek en wordt vaak onderschat. TYPO3's vertalingsafhandeling -- met zijn concept van language overlays, connected/free mode en fallback-ketens -- is geavanceerd. Kaart je exacte vertaalvereisten uit voordat je een CMS kiest. Storyblok en Contentful behandelen locale-beheer goed. Sanity vereist meer aangepaste setup voor complexe meertalige scenario's.
SEO Behoud Tijdens Migratie
Dit gedeelte is misschien het belangrijkste. Een verknalde migratie kan je organische traffic tanken.
URL Mapping
Exporteer elke URL van je TYPO3-site. Elke. Enkele. Een. Gebruik een crawler zoals Screaming Frog of wget --spider om een volledige URL-lijst op te stellen. Maak vervolgens een redirect-kaart:
/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf
Implementeer 301-redirects voor elke URL die verandert. In Next.js gaat dit in next.config.js:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-path/:slug*',
destination: '/new-path/:slug*',
permanent: true,
},
// ... honderden meer, bij voorkeur geladen uit een JSON-bestand
];
},
};
Voor grote redirect-lijsten (500+), overweeg redirects aan de edge af te handelen (Vercel Edge Middleware, Cloudflare Workers of nginx) in plaats van in je applicatieconfiguratie.
Meta Data Migratie
TYPO3 slaat SEO-metadata op in de pages-tabel (seo_title, description, og_image, etc.) en mogelijk in extensies zoals EXT:cs_seo of EXT:seo_basics. Extraheer alles en migreer het naar je headless CMS content-model. Vergeet niet:
- Pagina-titels en meta-beschrijvingen
- Open Graph en Twitter Card-data
- Canonieke URL's
- hreflang-tags voor meertalige sites
- Gestructureerde data / JSON-LD schema's
- XML sitemap-generatie
Monitoring
Zet Google Search Console in voor het nieuwe domein/subdomein voordat je migreert. Na go-live, monitor je Coverage-rapport dagelijks gedurende de eerste twee weken. Bekijk crawl-fouten, verloren pagina's en indexering-problemen. Heb een rollback-plan.
Testen en Go-Live Strategie
Ik raad een gefaseerde benadering aan in plaats van een big-bang cutover.
Fase 1: Parallel Runnen (2-4 weken)
Voer de nieuwe headless-site op een staging-domein uit. Vergelijk content-pariteit met de TYPO3-site. Laat editors content-workflows testen. Voer geautomatiseerde visuele regressietesten uit met tools zoals Percy of Playwright.
Fase 2: Soft Launch
Routeer een klein percentage van het verkeer naar de nieuwe site met behulp van feature flags of A/B-testing op CDN-niveau. Monitor Core Web Vitals, fout-rates en gebruiksgedrag.
Fase 3: Volledige Cutover
Schakel DNS of reverse proxy-configuratie over. Activeer alle redirects. Monitor agressief gedurende 48 uur. Houd de TYPO3-instantie draaiend (alleen-lezen) gedurende minstens 30 dagen als referentie.
Fase 4: Decommissioning
Zodra je zeker bent dat de migratie stabiel is, sluit je de TYPO3-infrastructuur af. Archiveer de database en fileadmin-directory. Je zult jezelf later dankbaar zijn als iemand naar oude content vraagt.
Real-World Migratietijdlijn en Kosten
Laat me eerlijk zijn over wat dit kost. Ik heb veel te veel teams migratieprojecten zien onderschatten.
| Projectgrootte | Pagina's | Tijdlijn | Geschatte Kosten |
|---|---|---|---|
| Klein | 50-200 | 6-10 weken | $15.000-$35.000 |
| Gemiddeld | 200-1.000 | 12-20 weken | $40.000-$90.000 |
| Groot | 1.000-5.000 | 20-36 weken | $80.000-$200.000 |
| Enterprise | 5.000+ | 6-12 maanden | $150.000-$500.000+ |
Deze getallen omvatten content-modeling, migratiescripting, frontend-ontwikkeling, testen en launch-ondersteuning. Ze omvatten geen CMS-licentiekosten, die per platform variëren.
De grootste kostenverursakers zijn:
- Aantal content-types en complexiteit -- niet ruw pagina-aantallen
- Aangepaste TYPO3-extensies die equivalente functionaliteit nodig hebben
- Multi-language setup complexiteit
- Integratievereisten (search, e-commerce, authenticatie)
- Editorial training en change management
Als je wilt bespreken hoe een migratie er voor je specifieke setup uit zou kunnen zien, neem contact op of check onze prijspagina voor engagement-modellen.
FAQ
Kan ik TYPO3 als headless CMS gebruiken in plaats van naar een nieuw te migreren?
Ja, de EXT:headless extensie (voorheen "headless") maakt van TYPO3 een JSON API. Dit kan een goed tussenstap zijn. Je onderhoud echter nog steeds een TYPO3-backend met alle operationele overhead. Het heeft zin als een brug-strategie maar is meestal niet het langetermijn-antwoord als je doel TYPO3-afhankelijkheid verminderen.
Hoe lang duurt een typische TYPO3 naar headless CMS-migratie?
Voor een middelgrote site (200-1.000 pagina's), verwacht 3-5 maanden van kickoff tot launch. De content-modeling en migratiescript-fasen nemen doorgaans langer dan teams verwachten. Frontend-ontwikkeling kan doorgaans parallel lopen eenmaal het content-model is gedefinieerd. Enterprise-migraties met meerdere talen en complexe integraties kunnen 6-12 maanden duren.
Verlies ik SEO-rankings tijdens de migratie?
Dat hoeft niet als je het correct doet. De kritieke factoren zijn: implementatie van juiste 301-redirects voor alle gewijzigde URL's, migratie van alle metadata, handhaven van je site-structuur en interne links en indiening van bijgewerkte sitemaps naar Google. Een tijdelijk dip in rankings gedurende 2-4 weken na migratie is normaal en herstelt zich gewoonlijk. Permanente verliezen duiden doorgaans op gemiste redirects of verloren content.
Welke headless CMS is het beste om TYPO3 te vervangen?
Het hangt af van je prioriteiten. Storyblok is vaak de soepelste overgang voor TYPO3-editors vanwege zijn visuele mogelijkheden. Contentful is de veiligste enterprise-keuze met het meest volwassen ecosysteem. Sanity biedt de meeste developer-flexibiliteit. Strapi is de beste optie als je open source en zelf-hosten nodig hebt. Er is geen enkel best antwoord -- het hangt af van je team, budget en vereisten.
Wat gebeurt er met mijn TYPO3-extensies na migratie?
Elke extensie moet individueel worden geëvalueerd. Veelvoorkomende extensies zoals EXT:news, EXT:cal en EXT:powermail hebben equivalente functionaliteit nodig in je nieuwe stack. News/blog-functionaliteit is eenvoudig te repliceren met elke headless CMS. Kalender- en event-functies hebben mogelijk externe services nodig. Formulieren vereisen een nieuwe oplossing (form builders, serverless functies of services zoals Formspree). Aangepaste extensies vereisen de meeste analyse.
Hoe handle ik TYPO3's fileadmin-assets tijdens migratie?
Je moet alle assets (afbeeldingen, PDF's, video's) naar het asset management-systeem van je nieuwe CMS of een aparte DAM/CDN migreren. Schrijf een script dat van fileadmin download, upload naar het nieuwe platform via zijn API en oude file-referenties aan nieuwe asset-ID's toewijst. Vergeet niet geverwerkte/geresizde afbeeldingen -- de meeste headless CMS-platforms verwerken beeldtransformatie automatisch, dus je hoeft doorgaans alleen originelen te migreren.
Kan ik geleidelijk migreren of moet het allemaal tegelijk?
Geleidelijke migratie is mogelijk en soms aan te raden voor grote sites. Je kunt een reverse proxy gebruiken om bepaalde URL-paden naar de nieuwe headless frontend te routeren terwijl je andere op TYPO3 houdt. Dit laat je sectie per sectie migreren. Het compromis is verhoogde complexiteit in het gelijktijdig beheren van twee systemen en het handhaven van consistente navigatie en design over beide heen.
Wat moet ik doen met TYPO3 backend-gebruikers die resistentie bieden?
Change management is echt de helft van de strijd. Begin door editors vroeg erbij te betrekken -- show ze het nieuwe CMS tijdens de content-modeling fase, niet nadat alles is gebouwd. Kies een CMS met goede editing-ervaring (Storyblok en Contentful krijgen doorgaans het beste editor-feedback). Maak documentatie en trainingsmateriaal specifiek voor je setup. En wees eerlijk over wat verandert en waarom -- editors komen meestal om als ze de verbeterde preview-ervaring en snellere publishing-workflows zien.