Ik ben door genoeg TYPO3-migraties gegaan om te weten dat het verschil tussen een soepele overgang en een nachtmerrie van zes maanden afhangt van voorbereiding. TYPO3 is een krachtig CMS — het bestaat sinds 1998 en draait enkele zeer complexe enterprise-sites, vooral in de DACH-regio. Maar wanneer het tijd is om te migreren, of je nu upgradet tussen grote TYPO3-versies of overstap naar een geheel ander platform, het proces kan snel uit de hand lopen als je geen plan hebt.

Dit is de checklist die ik graag voor mijn eerste TYPO3-migratie had gekregen. Het is niet theoretisch. Elk item hier bestaat omdat ik heb gezien wat er gebeurt wanneer je het overslaat.

Inhoudsopgave

TYPO3 Migration Checklist: A Developer's Step-by-Step Guide

Beoordeel je huidige TYPO3-installatie

Voordat je iets aanraakt, moet je precies begrijpen waarmee je werkt. Dit klinkt voor de hand liggend. Dat is het niet. Ik ben in projecten gelopen waar het team niet eens wist welke TYPO3-versie ze in productie draaide.

Versie- en omgevingsaudit

Begin hier:

# Controleer je TYPO3-versie
php typo3/sysext/core/bin/typo3 --version

# Of controleer via de backend: Help > About TYPO3

Documenteer het volgende:

  • TYPO3-versie (hoofd- en subversie — bijv. TYPO3 v11.5.38 LTS)
  • PHP-versie draait op de server
  • Databasetype en versie (MySQL, MariaDB, PostgreSQL)
  • Webserver (Apache, Nginx)
  • Composer-gebaseerde of klassieke installatie — dit maakt enorm veel uit
  • Aantal sites/domeinen in de installatie (multi-site-instellingen voegen complexiteit toe)
  • Totaal aantal pagina's en content-elementen in de pagina's-boom

Gebruiker- en machtigingstoewijzing

TYPO3's backend-gebruiker- en groepsmachtigingssysteem is beroemd granulair. Exporteer je be_users en be_groups tabellen en documenteer:

  • Hoeveel backend-gebruikers bestaan
  • Welke aangepaste machtigingen zijn geconfigureerd
  • Welke gebruikers hebben beheerderstoegang
  • Eventuele aangepaste TSconfig-overschrijvingen

Als je naar een ander CMS migreert, zul je deze rollen moeten toewijzen aan het machtigingsmodel van het nieuwe systeem. Als je TYPO3-versies upgradet, moeten sommige machtigingsconfiguraties mogelijk worden bijgewerkt.

TypoScript- en configuratiecomplexiteit

Voer een snelle audit uit van je TypoScript-instellingen:

# Tel je TypoScript-bestanden
find . -name '*.typoscript' -o -name '*.ts' | wc -l

# Controleer op setup.txt en constants.txt (verouderd formaat)
find . -name 'setup.txt' -o -name 'constants.txt' | wc -l

Als je honderden TypoScript-bestanden hebt met diep geneste configuraties, verwacht dan dat de migratie langer duurt. Ik heb TYPO3-installaties gezien met 10.000+ regels TypoScript die 15 jaar waren geëvolueerd. Dat is geen weekendproject.

Definieer je migratiesstrategie

Er zijn fundamenteel drie soorten TYPO3-migraties, en je moet beslissen welke je doet voordat je iets anders doet.

Migratiestype Wanneer kiezen Complexiteit Typische tijdlijn
TYPO3-versie-upgrade (bijv. v10 → v12) Je wilt op TYPO3 blijven Gemiddeld-Hoog 4-12 weken
TYPO3 naar headless CMS (bijv. Contentful, Strapi, Sanity) Je wilt moderne frontend-flexibiliteit Hoog 8-20 weken
TYPO3 naar ander traditioneel CMS (bijv. WordPress, Drupal) Je wilt een ander monolithisch CMS Gemiddeld 6-16 weken
TYPO3 naar headless TYPO3 (met EXT:headless) Je wilt TYPO3-backend met moderne frontend Gemiddeld 6-14 weken

Upgraden binnen TYPO3

Als je op TYPO3 blijft, vereist het officiële upgrade-pad het doorlopen van elke LTS-versie. Je kunt niet direct van v8 naar v12 springen. Nou ja, je kunt het proberen. Niet doen.

Het aanbevolen pad vanaf 2025:

  • v8 LTS → v9 LTS → v10 LTS → v11 LTS → v12 LTS → v13 LTS

TYPO3 v13 LTS werd eind 2024 uitgebracht en is de huidige long-term support-versie. TYPO3 v12 LTS ontvangt beveiligingsupdates tot april 2026 via het Extended Long Term Support (ELTS)-programma.

Weg van TYPO3 migreren

Als je naar een headless-architectuur gaat — en eerlijk gezegd, voor veel teams heeft dit veel zin — wil je je frontend-frameworkopties evalueren. We hebben uitgebreid werk gedaan met Next.js en Astro als frontend-lagen gekoppeld aan headless CMS-platforms.

De sleutelvraag is: rechtvaardigt je content-model de complexiteit van TYPO3? Als je een marketingsite met 200 pagina's draait, is TYPO3 waarschijnlijk overkill. Als je een multi-taal enterprise-portal draait met complexe workflows, zal het content-modelleringswerk tijdens de migratie aanzienlijk zijn, ongeacht waar je heen gaat.

Content audit en data mapping

Dit is waar migraties slagen of falen. Content.

Database-export en analyse

TYPO3 slaat content primair op in deze tabellen:

  • pages — de pagina's-boomstructuur
  • tt_content — content-elementen
  • sys_file en sys_file_reference — media-assets (FAL)
  • sys_category — categorieën
  • tx_news_domain_model_news — als je de nieuwsextensie gebruikt

Exporteer je content en krijg echte getallen:

-- Tel pagina's op type
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 
GROUP BY doktype;

-- Tel content-elementen op type
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Tel bestandsverwijzingen
SELECT COUNT(*) FROM sys_file WHERE missing = 0;

Content-type-toewijzing

Maak een spreadsheet aan waarin elk TYPO3 content-type (CType) wordt toegewezen aan het equivalent in het doelsysteem. Veelvoorkomende TYPO3 content-types die je tegenkijkt:

  • text, textmedia, textpic — standaard tekstcontent
  • image — afbeeldingsgalerijen
  • table — gegevenstabellen
  • bullets — lijsten
  • uploads — bestandslijsten
  • html — onbewerkte HTML (dit zijn altijd plezierige momenten tijdens migratie)
  • list — plugin-content (hier wordt het ingewikkeld)
  • Aangepaste content-types uit extensies

Het list CType is het lastige. Het vertegenwoordigt plugin-content — nieuwslijsten, formulieren, aangepaste functionaliteit — en elk ervan vereist individuele aandacht.

Multi-taal content

TYPO3 verwerkt vertalingen via connected mode (waarbij vertalingen zijn gekoppeld aan een standaardtaalrecord) of free mode. Controleer welke aanpak je site gebruikt:

-- Controleer vertaalinstelling
SELECT sys_language_uid, COUNT(*) 
FROM pages 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Als je 8 talen met connected mode-vertalingen hebt, is je migratiedatamapping zojuist 8x complexer geworden. Plan dienovereenkomstig.

TYPO3 Migration Checklist: A Developer's Step-by-Step Guide - architecture

Voorbereiding technische infrastructuur

Serververeisten

Als je upgradet naar TYPO3 v13, zijn dit de minimale vereisten vanaf 2025:

  • PHP 8.2 of hoger (8.3 aanbevolen)
  • MySQL 8.0+ of MariaDB 10.4+ of PostgreSQL 12+
  • Minimaal 256 MB PHP-geheugenlimiet (512 MB aanbevolen)
  • Composer 2.7+

Staging-omgeving

Voer nooit — en ik kan dit niet genoeg benadrukken — nooit een migratie rechtstreeks in productie uit. Stel in:

  1. Een staging-omgeving die productie spiegelt
  2. Een afzonderlijke databasekopie
  3. Identieke PHP- en serverconfiguraties
  4. Bestandsopslagingang (of een kopie van fileadmin)
# Kloon je database naar staging
mysqldump -u root -p production_db | mysql -u root -p staging_db

# Rsync fileadmin
rsync -avz production:/var/www/html/fileadmin/ staging:/var/www/html/fileadmin/

Back-upstrategie

Voordat migratiewerk begint:

  • Volledige databasedump met tijdstempels
  • Volledige bestandssysteemback-up inclusief fileadmin, typo3conf en eventuele aangepaste extensie-directories
  • Document je LocalConfiguration.php en AdditionalConfiguration.php-instellingen
  • Exporteer je TypoScript-templates

Bewaar deze back-ups ergens volledig gescheiden van de migratieomgeving. Ik houd minstens drie kopieën.

Uitbreiding- en integratie-inventaris

TYPO3-extensies zijn waarschijnlijk de grootste bron van migratieperikelen. Zo ga je ermee om.

Lijst alle geïnstalleerde extensies

# Composer-gebaseerde installatie
composer show | grep typo3

# Of controleer PackageStates.php
cat typo3conf/PackageStates.php

Categoriseer elke extensie

Bepaal voor elke extensie:

Categorie Vereiste actie Voorbeeld
Systeemextensie van kern Wordt meestal afgehandeld door upgrade wizard fluid_styled_content, form
Onderhouden TER-extensie Controleer compatibiliteit met doelversie news, powermail, solr
Verlaten TER-extensie Vind vervanging of aangepaste oplossing Diversen
Aangepaste site-extensie Vereist handmatige migratie/herschrijven Je site_package
Commerciële extensie Neem contact op met leverancier voor migratiepad in2publish, diversen

Veelvoorkomende extensie-migratiepadden

Enkele extensies die ik in bijna elke TYPO3-migratie zie:

  • EXT:news (Georg Ringer) — Controleer versiecompatibiliteit; v11+ werkt met TYPO3 v12/v13
  • EXT:powermail — Populaire formulierextensie; alternatieven zijn EXT:form (kern)
  • EXT:realurl — Verouderd sinds TYPO3 v9; vervangen door kernrouting
  • EXT:tt_address — Meestal eenvoudige upgrade
  • EXT:gridelements of EXT:flux — Deze layout-extensies veroorzaken de meeste pijn tijdens upgrades. Als je weg bent van TYPO3, verwacht aanzienlijk werk om content uit rasterstructuren te extraheren.

SEO-behoudsplan

Dit gedeelte overslaan heeft bedrijven miljoenen aan organisch verkeer gekost. Wees niet dat team.

URL-toewijzing

  1. Crawl je hele huidige site met Screaming Frog, Sitebulb of Ahrefs
  2. Exporteer alle URL's (verwacht duizenden voor grote TYPO3-sites)
  3. Maak een volledig 1:1 URL-toewijzingsdocument
  4. Identificeer je top 100 pagina's op basis van organisch verkeer (controleer Google Search Console)
  5. Prioriteer omleiding nauwkeurigheid voor pagina's met veel verkeer

Omleiding-implementatie

# Voorbeeld .htaccess-omleidingen
RedirectPermanent /old-typo3-path/page.html /new-path/page
RedirectPermanent /index.php?id=123 /about-us

Voor grootschalige omleidingen, gebruik een omleiding-beheeroplossing in plaats van duizenden regels in .htaccess stoppen. Als je naar een moderne stack verhuist, hebben de meeste frameworks en hostingplatforms (Vercel, Netlify) omleiding-configuratiebestanden.

Meta-gegeven-migratie

TYPO3 slaat SEO-metagegevens op in de pages-tabel (sinds EXT:seo een kernextensie werd in v9):

  • seo_title
  • og_title, og_description, og_image
  • twitter_title, twitter_description, twitter_image
  • canonical_link
  • no_index, no_follow

Zorg ervoor dat je dit alles exporteert en toewijs. Het verliezen van je meta-beschrijvingen op 500 pagina's is een voorkoombare ramp.

De migratieuitvoeringsfase

Voor TYPO3-versie-upgrades

Volg deze reeks voor elke versiestap:

  1. Update Composer-afhankelijkheden naar de volgende LTS-versie
  2. Voer de Upgrade Wizard uit in het Install Tool (Admin Tools > Upgrade)
  3. Voer database-analyzer uit om schema bij te werken
  4. Controleer deprecatielogboek op problemen
  5. Update extensies naar compatibele versies
  6. Repareer TypoScript verouderingen en breekveranderingen
  7. Test grondig voordat je naar de volgende versie gaat
# Update TYPO3-kern via Composer
composer require typo3/cms-core:^13.4 typo3/cms-backend:^13.4 \
  typo3/cms-frontend:^13.4 --with-all-dependencies

# Voer upgrade wizards uit via CLI
php typo3/sysext/core/bin/typo3 upgrade:run

# Database-schema-update
php typo3/sysext/core/bin/typo3 database:updateschema

Voor platformmigraties

Als je naar een headless CMS-architectuur migreert, ziet de uitvoeringsfase er anders uit:

  1. Stel het nieuwe CMS in en configureer content-modellen
  2. Bouw migratiescripts om TYPO3-gegevens te transformeren
  3. Migreer content in batches — begin met de eenvoudigste content-types
  4. Verwerk media-assets — download uit fileadmin en upload naar nieuwe asset-opslag
  5. Bouw de frontend met je gekozen framework
  6. Implementeer omleidingen voordat je live gaat
  7. DNS-cutover en monitoring

Voor de werkelijke gegevenstransformatie schrijf ik meestal Python- of Node.js-scripts die uit de TYPO3-database lezen en content naar het nieuwe CMS via API pushen:

import mysql.connector
import requests

# Verbind met TYPO3-database
db = mysql.connector.connect(
    host="localhost",
    user="typo3",
    password="password",
    database="typo3_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT uid, title, description, slug, 
           seo_title, og_description 
    FROM pages 
    WHERE deleted = 0 AND hidden = 0 
    AND sys_language_uid = 0
    ORDER BY sorting
""")

for page in cursor.fetchall():
    # Transform en push naar nieuw CMS
    payload = {
        "title": page["title"],
        "slug": page["slug"],
        "seoTitle": page["seo_title"] or page["title"],
        "description": page["og_description"] or page["description"]
    }
    # POST naar je nieuwe CMS API
    response = requests.post(
        "https://api.new-cms.com/content",
        json=payload,
        headers={"Authorization": "Bearer YOUR_TOKEN"}
    )
    print(f"Migrated page {page['uid']}: {response.status_code}")

Testen en kwaliteitsborging

Geautomatiseerde testchecklist

  • Alle pagina's retourneren 200 statuscode
  • Geen verbroken interne links
  • Alle afbeeldingen worden correct geladen
  • Formulieren versturen succesvol
  • Zoekfunctionaliteit werkt
  • Multi-taalwisseling werkt
  • Omleidingen van oude URL's werken correct
  • Canonieke URL's zijn correct
  • XML-sitemaps zijn geldig en toegankelijk
  • robots.txt is juist geconfigureerd
  • SSL-certificaten zijn geldig
  • Laadtijden van pagina's zijn aanvaardbaar (onder 3 seconden)

Visuele regressietesten

Gebruik tools zoals Percy, BackstopJS of Playwright voor visuele vergelijking:

# BackstopJS-voorbeeld
npx backstop init
# Configureer scenario's in backstop.json
npx backstop reference  # Leg huidige site vast
npx backstop test       # Vergelijk na migratie

Prestatiemarkering

Meet voor en na. Je migratie zou ideaal gezien de prestaties moeten verbeteren, niet verslechteren.

Metriek Pre-migratie-doel Post-migratie-doel
TTFB < 800ms < 200ms
LCP < 2,5s < 1,5s
CLS < 0,1 < 0,05
FID/INP < 200ms < 100ms
PageSpeed-score 50-70 90+

Als je van server-rendered TYPO3 naar een statische of edge-rendered frontend gaat, zou je dramatische verbeteringen in deze getallen moeten zien.

Monitoring na migratie

De migratie is niet voorbij wanneer je de DNS omslaat. Monitor dit minstens 30 dagen:

  1. Google Search Console — Let op crawlfouten, dekkingsproblemen en indexeringsproblemen. Verwacht enige schommeling in de eerste twee weken.
  2. Analytics — Vergelijk verkeerpatronen week-voor-week met pre-migratie-basislijnen.
  3. 404-fouten — Stel logging in voor 404's en voeg omleidingen toe voor eventuele URL's die je hebt gemist.
  4. Core Web Vitals — Monitor echte gebruikersgegevens via CrUX of je analyticsplatform.
  5. Serverlogboeken — Let op ongewone foutpatronen.

Stel waarschuwingen in voor verkeerdalingen van meer dan 20% op elke pagina die eerder in je top 50 stond.

Veelvoorkomende TYPO3-migratievallen

Dit zijn fouten die ik in tientallen migraties heb zien optreden (en soms zelf heb gemaakt):

1. Soft-verwijderde records negeren. TYPO3 gebruikt deleted=1-vlaggen in plaats van records daadwerkelijk te verwijderen. Je migratiescripts moeten deze filteren, anders importeer je duizenden records die jaren geleden zijn verwijderd.

2. Werkruimten vergeten. Als de site TYPO3-werkruimten voor redactionele workflows gebruikt, heb je mogelijk conceptcontent gemengd in je export. Filter altijd naar t3ver_wsid = 0 om alleen live-content te krijgen.

3. RTE-content onderschatten. TYPO3's rich text-editoruitvoer kan aangepaste tags, <link>-tags met TYPO3-specifieke syntaxis en t3://-URI's bevatten. Je moet al deze parseren en converteren.

4. Bestandsverwijzingen breken. TYPO3's File Abstraction Layer (FAL) gebruikt sys_file_reference om bestanden aan content te verbinden. Het is geen eenvoudig "afbeeldingsveld in het content-record" — het is een relatietabel. Je migratiescripts moeten deze verwijzingen volgen.

5. Niet testen met echte content-volumes. Je migratiescript werkt prima met 10 testpagina's. Het mislukt catastrofaal met 15.000 pagina's en 50.000 content-elementen. Test altijd op schaal.

Als je een migratie plant en deze vallen wilt vermijden, hebben we verschillende enterprise-teams door TYPO3-migraties geleid — neem gerust contact op en we kunnen je specifieke situatie doorspreken.

Veelgestelde vragen

Hoe lang duurt een TYPO3-migratie doorgaans? Dit hangt sterk af van de complexiteit van je installatie. Een eenvoudige TYPO3 v11 naar v13-upgrade voor een site met één taal en standaardextensies kan 4-6 weken duren. Een volledige platformmigratie van een multi-taal enterprise TYPO3-site met aangepaste extensies kan gemakkelijk 3-6 maanden duren. Alleen de content audit-fase kan 2-4 weken duren voor grote sites.

Kan ik TYPO3 LTS-versies overslaan tijdens een upgrade? Technisch gezien mag je niet. De officiële aanbeveling is om door elke LTS-versie opeenvolgend te upgraden (v8 → v9 → v10 → v11 → v12 → v13) omdat elke versie upgrade wizards bevat die gegevensmigraties voor die specifieke stap verwerken. Versies overslaan betekent dat die gegevensmigraties niet worden uitgevoerd en je eindigt met beschadigde of zwevende gegevens. Enkele agencies beweren dat ze versie-overspringende upgrades kunnen doen, maar ik heb gezien dat dit subtiele gegevensproblemen veroorzaakt die maanden later naar buiten komen.

Moet ik van TYPO3 naar WordPress migreren? Het hangt van je behoeften af. WordPress verwerkt eenvoudige marketingsites goed, maar als je TYPO3 oorspronkelijk hebt gekozen vanwege complexe multi-taal-vereisten, granulaire machtigingen of enterprise-workflows, kan WordPress een stap terug zijn. Bekijk of een headless CMS gekoppeld aan een modern frontend-framework niet beter zou passen. We hebben geschreven over headless CMS-ontwikkelingbenaderingen die vaak meer zin hebben voor teams die enterprise CMS-platforms verlaten.

Wat gebeurt er met mijn SEO-rankings tijdens een TYPO3-migratie? Verwacht enige rangschikkingsschommeling gedurende 2-6 weken, zelfs met perfecte omleidingen. Google heeft tijd nodig om je content opnieuw te crawlen en opnieuw in te delen. Om impact te minimaliseren: implementeer 301-omleidingen voor elke URL, houd je content-structuur zo dicht mogelijk bij het origineel, dien bijgewerkte sitemaps onmiddellijk in en gebruik het Adresveranderinghulpmiddel in Google Search Console als je domeinen wijzigt. Sites die omleidingen correct afhandelen, herstellen meestal binnen 4-8 weken.

Hoe ga ik om met TYPO3-extensies die niet op het doelplatform bestaan? Bepaal eerst wat de extensie echt doet. Veel TYPO3-extensies bieden functionaliteit die ingebouwd is in moderne platforms (zoals formulierbuilders, SEO-tools of omleiding-beheer). Voor aangepaste functionaliteit zul je een gelijkwaardige plugin/service moeten vinden of aangepaste functies moeten bouwen. Maak een spreadsheet aan met elke extensie, het doel ervan en de vervangingsstrategie.

Is het de moeite waard om naar headless TYPO3 te gaan in plaats van helemaal weg te migreren? De TYPO3 headless-extensie (EXT:headless) is een legitieme optie als je team comfortabel is met TYPO3's backend maar een moderne frontend wilt. Het stelt TYPO3-content bloot als JSON API's, zodat je je frontend met Next.js, Nuxt of Astro kunt bouwen. Deze aanpak behoud je bestaande content-structuur en redactionele workflows terwijl je de presentatielaag moderniseert. Het is een goed middenweg, hoewel het betekent dat je nog steeds een TYPO3-backend onderhoudt.

Wat zijn de kosten van een TYPO3-migratie in 2025? Richtijnfiguren: een TYPO3-versie-upgrade voor een middelgrote site kost $15.000-$50.000. Een volledige platformmigratie naar een headless-architectuur loopt $40.000-$150.000+ afhankelijk van content-volume, aantal talen, aangepaste functionaliteit en integratiecomplexiteit. Dit zijn niet kleine bedragen, maar vergelijk ze met de kosten van het onderhouden van een verouderde, onveilige CMS-installatie. Je kunt onze prijspagina controleren voor meer details over hoe we deze projecten structureren.

Moet ik mijn templates helemaal opnieuw bouwen? Voor TYPO3-versie-upgrades, meestal niet helemaal — maar je zult Fluid-templates moeten bijwerken om verouderde ViewHelpers en nieuwe API's af te handelen. Voor platformmigraties, ja, je bouwt een nieuwe frontend. Het goede nieuws is dat moderne frameworks zoals Next.js en Astro het aanzienlijk sneller maken om performante frontends te bouwen dan het was in het Fluid/TypoScript-tijdperk. Je design kan hetzelfde blijven; de implementatie verandert gewoon.