Ich bin genug TYPO3-Migrationen durchgegangen, um zu wissen, dass der Unterschied zwischen einem reibungslosen Übergang und einem sechsmonatigen Albtraum von der Vorbereitung abhängt. TYPO3 ist ein leistungsstarkes CMS — es gibt es seit 1998 und betreibt einige sehr komplexe Enterprise-Websites, besonders in der DACH-Region. Aber wenn es Zeit für eine Migration ist, egal ob Sie zwischen großen TYPO3-Versionen upgraden oder zu einer ganz anderen Plattform wechseln, kann der Prozess schnell hässlich werden, wenn Sie keinen Plan haben.

Das ist die Checkliste, die mir jemand vor meiner ersten TYPO3-Migration geben hätte sollen. Sie ist nicht theoretisch. Jeder Punkt hier existiert, weil ich gesehen habe, was passiert, wenn man ihn übergeht.

Inhaltsverzeichnis

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

Bewertung Ihrer aktuellen TYPO3-Installation

Bevor Sie irgendetwas anfassen, müssen Sie genau verstehen, womit Sie es zu tun haben. Das klingt offensichtlich. Ist es nicht. Ich bin in Projekte gekommen, wo das Team nicht einmal wusste, welche TYPO3-Version sie in der Produktion laufen hatten.

Versions- und Umgebungs-Audit

Beginnen Sie hier:

# Überprüfen Sie Ihre TYPO3-Version
php typo3/sysext/core/bin/typo3 --version

# Oder überprüfen Sie über das Backend: Help > About TYPO3

Dokumentieren Sie folgende Angaben:

  • TYPO3-Version (Major und Minor — z.B. TYPO3 v11.5.38 LTS)
  • PHP-Version auf dem Server
  • Datenbanktyp und -version (MySQL, MariaDB, PostgreSQL)
  • Webserver (Apache, Nginx)
  • Composer-basierte oder klassische Installation — das ist enorm wichtig
  • Anzahl der Websites/Domains in der Installation (Multi-Site-Setups erhöhen die Komplexität)
  • Gesamtanzahl der Seiten und Content-Elemente im Seitenbaum

Benutzer- und Berechtigungszuordnung

TYPOs Backend-Benutzer- und Gruppberechtigungssystem ist notorisch granular. Exportieren Sie Ihre be_users- und be_groups-Tabellen und dokumentieren Sie:

  • Wie viele Backend-Benutzer existieren
  • Welche benutzerdefinierten Berechtigungen konfiguriert sind
  • Welche Benutzer Admin-Zugriff haben
  • Alle benutzerdefinierten TSconfig-Überschreibungen

Wenn Sie zu einem anderen CMS migrieren, müssen Sie diese Rollen dem Berechtigungsmodell des neuen Systems zuordnen. Wenn Sie TYPO3-Versionen aktualisieren, müssen einige Berechtigungskonfigurationen möglicherweise aktualisiert werden.

TypoScript- und Konfigurationskomplexität

Führen Sie eine schnelle Überprüfung Ihres TypoScript-Setups durch:

# Zählen Sie Ihre TypoScript-Dateien
find . -name '*.typoscript' -o -name '*.ts' | wc -l

# Überprüfen Sie setup.txt und constants.txt (Legacy-Format)
find . -name 'setup.txt' -o -name 'constants.txt' | wc -l

Wenn Sie hunderte von TypoScript-Dateien mit tief verschachtelten Konfigurationen haben, rechnen Sie mit einer längeren Migration. Ich bin auf TYPO3-Installationen mit 10.000+ Zeilen TypoScript gestoßen, die sich über 15 Jahre entwickelt haben. Das ist kein Wochenend-Projekt.

Definition Ihrer Migrationsstrategie

Es gibt grundsätzlich drei Arten von TYPO3-Migrationen, und Sie müssen entscheiden, welche Sie durchführen, bevor irgendetwas anderes passiert.

Migrationstyp Wann wählen Komplexität Typischer Zeitrahmen
TYPO3-Versionsupgrade (z.B. v10 → v12) Sie möchten auf TYPO3 bleiben Mittel-Hoch 4-12 Wochen
TYPO3 zu Headless CMS (z.B. Contentful, Strapi, Sanity) Sie möchten moderne Frontend-Flexibilität Hoch 8-20 Wochen
TYPO3 zu anderem traditionellem CMS (z.B. WordPress, Drupal) Sie möchten ein anderes monolithisches CMS Mittel 6-16 Wochen
TYPO3 zu Headless TYPO3 (mit EXT:headless) Sie möchten TYPO3-Backend mit modernem Frontend Mittel 6-14 Wochen

Upgrade innerhalb von TYPO3

Wenn Sie auf TYPO3 bleiben, erfordert der offizielle Upgrade-Pfad das Durchlaufen jeder LTS-Version. Sie können nicht direkt von v8 zu v12 springen. Nun, Sie können versuchen. Tun Sie es nicht.

Der empfohlene Pfad ab 2025:

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

TYPO3 v13 LTS wurde Ende 2024 veröffentlicht und ist die aktuelle Long-Term-Support-Version. TYPO3 v12 LTS erhält Sicherheitsupdates bis April 2026 durch das Extended Long Term Support (ELTS)-Programm.

Weg von TYPO3

Wenn Sie zu einer Headless-Architektur wechseln — und ehrlich gesagt macht das für viele Teams viel Sinn — möchten Sie Ihre Frontend-Framework-Optionen evaluieren. Wir haben umfangreiche Arbeiten mit Next.js und Astro als Frontend-Schichten gekoppelt mit Headless-CMS-Plattformen durchgeführt.

Die Schlüsselfrage lautet: rechtfertigt Ihr Content-Modell die Komplexität von TYPO3? Wenn Sie einen Marketing-Site mit 200 Seiten betreiben, ist TYPO3 wahrscheinlich overkill. Wenn Sie ein mehrsprachiges Enterprise-Portal mit komplexen Workflows betreiben, wird die Content-Modellierungsarbeit während der Migration unabhängig davon, wohin Sie gehen, erheblich sein.

Content-Audit und Datenmapping

Hier leben oder sterben Migrationen. Content.

Datenbankexport und -analyse

TYPO3 speichert Inhalte hauptsächlich in diesen Tabellen:

  • pages — die Seitenbaum-Struktur
  • tt_content — Content-Elemente
  • sys_file und sys_file_reference — Media-Assets (FAL)
  • sys_category — Kategorien
  • tx_news_domain_model_news — falls Sie die News-Erweiterung verwenden

Exportieren Sie Ihren Inhalt und erhalten Sie echte Zahlen:

-- Zählen Sie Seiten nach Typ
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 
GROUP BY doktype;

-- Zählen Sie Content-Elemente nach Typ
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Zählen Sie Dateireferenzen
SELECT COUNT(*) FROM sys_file WHERE missing = 0;

Content-Typ-Zuordnung

Erstellen Sie eine Tabelle, die jeden TYPO3-Content-Typ (CType) seinem Äquivalent im Zielsystem zuordnet. Häufige TYPO3-Content-Typen, denen Sie begegnen werden:

  • text, textmedia, textpic — Standard-Text-Inhalt
  • image — Bildergalerien
  • table — Datentabellen
  • bullets — Listen
  • uploads — Dateilisten
  • html — reines HTML (diese sind während der Migration immer unterhaltsam)
  • list — Plugin-Inhalt (hier wird es kompliziert)
  • Benutzerdefinierte Content-Typen aus Erweiterungen

Der list CType ist der knifflige. Er stellt Plugin-Inhalt dar — News-Auflistungen, Formulare, benutzerdefinierte Funktionalität — und jeder muss einzeln beachtet werden.

Multi-Sprachen-Inhalt

TYPO3 verwaltet Übersetzungen durch verbundenen Modus (wobei Übersetzungen mit einem Standard-Sprachendatensatz verknüpft sind) oder freien Modus. Überprüfen Sie, welcher Ansatz Ihre Website verwendet:

-- Überprüfen Sie das Übersetzungs-Setup
SELECT sys_language_uid, COUNT(*) 
FROM pages 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Wenn Sie 8 Sprachen mit verbundenem Modus-Übersetzungen haben, ist Ihre Migrations-Datenzuordnung gerade 8x komplexer geworden. Planen Sie entsprechend.

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

Vorbereitung der technischen Infrastruktur

Server-Anforderungen

Wenn Sie zu TYPO3 v13 upgraden, sind dies ab 2025 die Mindestanforderungen:

  • PHP 8.2 oder höher (8.3 empfohlen)
  • MySQL 8.0+ oder MariaDB 10.4+ oder PostgreSQL 12+
  • 256 MB PHP-Speicherlimit mindestens (512 MB empfohlen)
  • Composer 2.7+

Staging-Umgebung

Führen Sie niemals — und ich kann das nicht genug betonen — niemals eine Migration direkt auf der Produktion durch. Richten Sie folgende ein:

  1. Eine Staging-Umgebung, die die Produktion spiegelt
  2. Eine separate Datenbankkopie
  3. Identische PHP- und Server-Konfigurationen
  4. Dateispeicher-Zugriff (oder eine Kopie von fileadmin)
# Klonen Sie Ihre Datenbank zum 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/

Sicherungsstrategie

Bevor eine Migrationsarbeit beginnt:

  • Vollständiger Datenbankdump mit Zeitstempel
  • Komplette Dateisystem-Sicherung einschließlich fileadmin, typo3conf und benutzerdefinierten Erweiterungs-Verzeichnissen
  • Dokumentieren Sie Ihre LocalConfiguration.php und AdditionalConfiguration.php Einstellungen
  • Exportieren Sie Ihre TypoScript-Templates

Speichern Sie diese Sicherungen vollständig getrennt von der Migrations-Umgebung. Ich halte mindestens drei Kopien.

Erweiterungs- und Integrationsinventar

TYPO3-Erweiterungen sind wahrscheinlich die größte Quelle von Migrations-Kopfschmerzen. So gehen Sie damit um.

Alle installierten Erweiterungen auflisten

# Composer-basierte Installation
composer show | grep typo3

# Oder überprüfen Sie die PackageStates.php
cat typo3conf/PackageStates.php

Kategorisieren Sie jede Erweiterung

Für jede Erweiterung bestimmen Sie:

Kategorie Erforderliche Aktion Beispiel
Core-System-Erweiterung Normalerweise vom Upgrade-Wizard behandelt fluid_styled_content, form
Gepflegte TER-Erweiterung Kompatibilität mit Zielversion überprüfen news, powermail, solr
Aufgegebene TER-Erweiterung Ersatz finden oder benutzerdefinierte Lösung Verschiedene
Benutzerdefinierte Website-Erweiterung Manuelle Migration/Umschreiben erforderlich Ihr site_package
Kommerzielle Erweiterung Kontaktieren Sie den Anbieter für Migrationspfad in2publish, verschiedene

Häufige Migrations-Pfade für Erweiterungen

Einige Erweiterungen, die ich in fast jeder TYPO3-Migration sehe:

  • EXT:news (Georg Ringer) — Version-Kompatibilität überprüfen; v11+ funktioniert mit TYPO3 v12/v13
  • EXT:powermail — Beliebte Formular-Erweiterung; Alternativen sind EXT:form (Core)
  • EXT:realurl — Veraltet seit TYPO3 v9; ersetzt durch Core-Routing
  • EXT:tt_address — Normalerweise unkomplizierter Upgrade
  • EXT:gridelements oder EXT:flux — Diese Layout-Erweiterungen verursachen die meisten Probleme bei Upgrades. Wenn Sie von TYPO3 weg migrieren, erwarten Sie erhebliche Arbeiten beim Extrahieren von Inhalten aus Grid-Strukturen.

SEO-Erhaltungsplan

Das Überspringen dieses Abschnitts hat Unternehmen Millionen an organischem Traffic gekostet. Sein Sie nicht dieses Team.

URL-Zuordnung

  1. Crawlen Sie Ihre gesamte aktuelle Website mit Screaming Frog, Sitebulb oder Ahrefs
  2. Exportieren Sie alle URLs (erwarten Sie Tausende für große TYPO3-Websites)
  3. Erstellen Sie ein komplettes 1:1-URL-Zuordnungs-Dokument
  4. Identifizieren Sie Ihre Top-100-Seiten nach organischem Traffic (überprüfen Sie die Google Search Console)
  5. Priorisieren Sie Redirect-Genauigkeit für High-Traffic-Seiten

Redirect-Implementierung

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

Verwenden Sie für große Redirect-Mengen eine Redirect-Management-Lösung, statt Tausende von Regeln in .htaccess zu packen. Wenn Sie zu einem modernen Stack wechseln, haben die meisten Frameworks und Hosting-Plattformen (Vercel, Netlify) Konfigurationsdateien für Redirects.

Metadaten-Migration

TYPO3 speichert SEO-Metadaten in der pages-Tabelle (seit EXT:seo in v9 eine Core-Erweiterung wurde):

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

Stellen Sie sicher, dass Sie alle diese exportieren und zuordnen. Den Verlust Ihrer Meta-Beschreibungen über 500 Seiten hinweg ist ein vermeidbares Desaster.

Die Migrationsausführungsphase

Für TYPO3-Versionsupgrades

Folgen Sie dieser Reihenfolge für jeden Versions-Schritt:

  1. Aktualisieren Sie Composer-Abhängigkeiten auf die nächste LTS-Version
  2. Führen Sie den Upgrade-Wizard im Install-Tool aus (Admin Tools > Upgrade)
  3. Führen Sie die Datenbankanalysierung aus, um das Schema zu aktualisieren
  4. Überprüfen Sie das Deprecation-Log auf Probleme
  5. Aktualisieren Sie Erweiterungen auf kompatible Versionen
  6. Reparieren Sie TypoScript Deprecation und Breaking Changes
  7. Testen Sie gründlich, bevor Sie zum nächsten Versions-Schritt übergehen
# TYPO3-Core via Composer aktualisieren
composer require typo3/cms-core:^13.4 typo3/cms-backend:^13.4 \
  typo3/cms-frontend:^13.4 --with-all-dependencies

# Upgrade-Wizards via CLI ausführen
php typo3/sysext/core/bin/typo3 upgrade:run

# Datenbankschema-Update
php typo3/sysext/core/bin/typo3 database:updateschema

Für Plattform-Migrationen

Wenn Sie zu einer Headless-CMS-Architektur migrieren, sieht die Ausführungsphase anders aus:

  1. Richten Sie das neue CMS ein und konfigurieren Sie Content-Modelle
  2. Erstellen Sie Migrations-Skripte, um TYPO3-Daten zu transformieren
  3. Migrieren Sie Inhalte in Batches — beginnen Sie mit den einfachsten Content-Typen
  4. Handhaben Sie Media-Assets — laden Sie von fileadmin herunter und laden Sie zu neuem Asset-Speicher hoch
  5. Bauen Sie das Frontend mit Ihrem gewählten Framework
  6. Implementieren Sie Redirects, bevor Sie live gehen
  7. DNS-Cutover und Überwachung

Für die tatsächliche Datentransformation schreibe ich normalerweise Python- oder Node.js-Skripte, die aus der TYPO3-Datenbank lesen und Inhalte über API an das neue CMS drücken:

import mysql.connector
import requests

# Verbindung zur TYPO3-Datenbank
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():
    # Transformieren und zu neuem CMS drücken
    payload = {
        "title": page["title"],
        "slug": page["slug"],
        "seoTitle": page["seo_title"] or page["title"],
        "description": page["og_description"] or page["description"]
    }
    # POST zu Ihrer neuen 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 und Qualitätssicherung

Automatisierte Test-Checkliste

  • Alle Seiten geben Status-Code 200 zurück
  • Keine beschädigten internen Links
  • Alle Bilder laden korrekt
  • Formulare werden erfolgreich eingereicht
  • Such-Funktionalität funktioniert
  • Multi-Sprachen-Umschalten funktioniert
  • Redirects von alten URLs funktionieren
  • Canonical-URLs sind korrekt
  • XML-Sitemaps sind gültig und erreichbar
  • robots.txt ist richtig konfiguriert
  • SSL-Zertifikate sind gültig
  • Seiten-Ladezeiten sind akzeptabel (unter 3 Sekunden)

Visuelle Regressions-Tests

Verwenden Sie Tools wie Percy, BackstopJS oder Playwright für visuellen Vergleich:

# BackstopJS-Beispiel
npx backstop init
# Konfigurieren Sie Szenarien in backstop.json
npx backstop reference  # Erfassen Sie aktuelle Website
npx backstop test       # Vergleichen Sie nach Migration

Performance-Benchmarks

Messen Sie vorher und nachher. Ihre Migration sollte idealerweise die Performance verbessern, nicht verschlechtern.

Metrik Pre-Migration-Ziel Post-Migration-Ziel
TTFB < 800ms < 200ms
LCP < 2.5s < 1.5s
CLS < 0.1 < 0.05
FID/INP < 200ms < 100ms
PageSpeed-Score 50-70 90+

Wenn Sie von server-gerenderten TYPO3 zu einem statischen oder edge-gerendertem Frontend wechseln, sollten Sie dramatische Verbesserungen in diesen Zahlen sehen.

Überwachung nach der Migration

Die Migration ist nicht abgeschlossen, wenn Sie den DNS umschalten. Überwachen Sie diese mindestens 30 Tage:

  1. Google Search Console — Beobachten Sie Crawl-Fehler, Coverage-Probleme und Indexierungs-Probleme. Erwarten Sie einige Fluktuationen in den ersten zwei Wochen.
  2. Analytics — Vergleichen Sie Traffic-Muster Woche für Woche mit Pre-Migration-Baselines.
  3. 404-Fehler — Richten Sie Logging für 404s ein und fügen Sie Redirects für alle URLs hinzu, die Sie verpasst haben.
  4. Core Web Vitals — Überwachen Sie echte Benutzerdaten über CrUX oder Ihre Analytics-Plattform.
  5. Server-Logs — Beobachten Sie ungewöhnliche Fehler-Muster.

Richten Sie Warnungen für Traffic-Abfälle von über 20% auf einer Seite ein, die zuvor in Ihren Top 50 war.

Häufige TYPO3-Migrations-Fallstricke

Das sind Fehler, die ich über dutzende Migrationen hinweg gesehen habe (und manchmal selbst gemacht):

1. Soft-gelöschte Datensätze ignorieren. TYPO3 verwendet deleted=1-Flags statt Datensätze tatsächlich zu entfernen. Ihre Migrations-Skripte müssen diese filtern, oder Sie werden Tausende von Datensätzen importieren, die vor Jahren gelöscht wurden.

2. Workspaces vergessen. Wenn die Website TYPO3-Workspaces für Editorial-Workflows nutzt, haben Sie möglicherweise Entwurfs-Inhalte in Ihren Export vermischt. Filtern Sie immer nach t3ver_wsid = 0, um nur Live-Inhalte zu erhalten.

3. RTE-Inhalte unterschätzen. Die TYPO3-Rich-Text-Editor-Ausgabe kann Custom-Tags, <link>-Tags mit TYPO3-spezifischer Syntax und t3://-URIs enthalten. Sie müssen alle diese parsen und konvertieren.

4. Datei-Referenzen unterbrechen. TYPOs File Abstraction Layer (FAL) verwendet sys_file_reference, um Dateien mit Inhalten zu verbinden. Es ist nicht einfach ein "image field auf dem Content-Datensatz" — es ist eine Relations-Tabelle. Ihre Migrations-Skripte müssen diesen Referenzen folgen.

5. Nicht mit echten Content-Volumen testen. Ihr Migrations-Skript funktioniert großartig mit 10 Test-Seiten. Es schlägt katastrophal mit 15.000 Seiten und 50.000 Content-Elementen fehl. Testen Sie immer im großen Maßstab.

Wenn Sie eine Migration planen und diese Fallstricke vermeiden möchten, haben wir mehrere Enterprise-Teams durch TYPO3-Migrationen geführt — zögern Sie nicht, uns zu kontaktieren und wir können Ihre spezifische Situation besprechen.

FAQ

Wie lange dauert eine TYPO3-Migration normalerweise? Das hängt stark von der Komplexität Ihrer Installation ab. Ein unkompliziertes TYPO3 v11 zu v13 Upgrade für eine einsprachige Website mit Standard-Erweiterungen könnte 4-6 Wochen dauern. Eine vollständige Plattform-Migration einer mehrsprachigen Enterprise-TYPO3-Website mit benutzerdefinierten Erweiterungen kann leicht 3-6 Monate dauern. Die Content-Audit-Phase allein kann 2-4 Wochen für große Websites dauern.

Kann ich TYPO3-LTS-Versionen während eines Upgrades überspringen? Technisch gesehen sollten Sie nicht. Die offizielle Empfehlung ist, durch jede LTS-Version sequenziell zu upgraden (v8 → v9 → v10 → v11 → v12 → v13), weil jede Version Upgrade-Wizards enthält, die Daten-Migrationen für diesen spezifischen Schritt durchführen. Das Überspringen von Versionen bedeutet, dass diese Daten-Migrationen nicht laufen und Sie endet mit beschädigten oder verwaisten Daten. Einige Agenturen behaupten, Skip-Version-Upgrades durchführen zu können, aber ich habe gesehen, dass es subtile Daten-Probleme verursacht, die Monate später auftauchen.

Sollte ich von TYPO3 zu WordPress migrieren? Das hängt von Ihren Anforderungen ab. WordPress verwaltet einfache Marketing-Sites gut, aber wenn Sie TYPO3 ursprünglich wegen komplexer Mehrsprachlichkeits-Anforderungen, granularer Berechtigungen oder Enterprise-Workflows gewählt haben, könnte WordPress ein Schritt rückwärts sein. Überlegen Sie, ob ein Headless-CMS gekoppelt mit einem modernen Frontend-Framework besser geeignet sein könnte. Wir haben über Headless-CMS-Entwicklung geschrieben, die oft für Teams, die Enterprise-CMS-Plattformen verlassen, einen besseren Sinn ergibt.

Was passiert mit meinen SEO-Rankings während einer TYPO3-Migration? Erwarten Sie einige Ranking-Fluktuationen für 2-6 Wochen, selbst mit perfekten Redirects. Google braucht Zeit, um zu recrawlen und neu zu indexieren. Um die Auswirkungen zu minimieren: Implementieren Sie 301-Redirects für jede URL, halten Sie Ihre Content-Struktur so nah wie möglich am Original, reichen Sie sofort aktualisierte Sitemaps ein und verwenden Sie das Change of Address-Tool in der Google Search Console, wenn Sie Domains ändern. Websites, die Redirects richtig handhaben, erholen sich normalerweise innerhalb von 4-8 Wochen.

Wie handhabe ich TYPO3-Erweiterungen, die auf der Zielplattform nicht existieren? Bestimmen Sie zunächst, was die Erweiterung tatsächlich tut. Viele TYPO3-Erweiterungen bieten Funktionalität, die in modernen Plattformen eingebaut ist (wie Form-Builder, SEO-Tools oder Redirect-Management). Für benutzerdefinierte Funktionalität müssen Sie entweder ein äquivalentes Plugin/Service finden oder benutzerdefinierte Features bauen. Erstellen Sie eine Tabelle, die jede Erweiterung, ihren Zweck und die Ersatz-Strategie auflistet.

Lohnt es sich, zu Headless TYPO3 zu wechseln, statt vollständig zu migrieren? Die TYPO3-Headless-Erweiterung (EXT:headless) ist eine legitime Option, wenn Ihr Team sich mit TYPOs Backend wohlfühlt, aber ein modernes Frontend möchte. Sie stellt TYPO3-Inhalte als JSON-APIs bereit und lässt Sie Ihr Frontend mit Next.js, Nuxt oder Astro bauen. Dieser Ansatz bewahrt Ihre bestehende Content-Struktur und Editorial-Workflows, während er die Präsentationsebene modernisiert. Es ist ein guter Mittelweg, obwohl es bedeutet, dass Sie immer noch ein TYPO3-Backend warten.

Was kostet eine TYPO3-Migration 2025? Ungefähre Zahlen: Ein TYPO3-Versions-Upgrade für eine mittelgroße Website kostet $15.000-$50.000. Eine vollständige Plattform-Migration zu einer Headless-Architektur kostet $40.000-$150.000+ abhängig von Content-Volumen, Anzahl der Sprachen, benutzerdefinierten Funktionalität und Integrations-Komplexität. Das sind keine kleinen Zahlen, aber vergleichen Sie sie mit den Kosten, ein veraltetes, unsicheres CMS-Installation zu warten. Sie können unsere Pricing-Seite überprüfen, um mehr Details darüber zu erfahren, wie wir diese Projekte strukturieren.

Muss ich meine Templates von Grund auf neu bauen? Für TYPO3-Versionsupgrades normalerweise nicht vollständig — aber Sie müssen Fluid-Templates aktualisieren, um veraltete ViewHelpers und neue APIs zu handhaben. Für Plattform-Migrationen ja, Sie bauen ein neues Frontend. Die gute Nachricht ist, dass moderne Frameworks wie Next.js und Astro es bedeutend schneller machen, performante Frontends zu bauen als es in der Fluid/TypoScript-Ära war. Ihr Design kann gleich bleiben; die Implementierung ändert sich einfach.