TYPO3 14 LTS — der Upgrade-Guide für Enterprise-Projekte
Ob Ihr TYPO3-Upgrade drängt, entscheidet eine einzige Angabe: Ihre aktuelle Version. Läuft Ihr Projekt auf v12, ist der reguläre Support seit dem 30. April 2026 beendet — dann ist das Upgrade keine Roadmap-Frage mehr. Auf v13 haben Sie bis Ende Dezember 2027 Zeit und können planen. Dieser Guide ordnet beide Situationen ein, zeigt, was TYPO3 14 tatsächlich mitbringt, und benennt die Faktoren, die den Aufwand bestimmen. Für CTOs, IT-Leitung und Entwickler, die ein bestehendes Projekt verantworten.
- TYPO3 14 LTS in Kurzform
-
TYPO3 14 LTS ist seit dem 21. April 2026 als Version 14.3 verfügbar. Das Upgrade setzt PHP 8.2 oder höher und Composer voraus und verlangt die Prüfung aller installierten Extensions. Die wesentlichen Neuerungen sind ein überarbeitetes Backend, Content Blocks im Core, eine Schnittstelle für KI-gestützte Redaktionsarbeit, erweiterte Headless-Fähigkeiten und modernisierte Core-APIs.
-
Abgrenzung
Sprint-Releases (14.0 bis 14.2) waren Vorstufen für Evaluierung und Tests. Für Produktivsysteme kommt ausschließlich die LTS-Version infrage — sie friert den Funktionsumfang ein und erhält über Jahre Sicherheitsupdates.
Wie dringend ist Ihr Upgrade?
Die Antwort hängt allein an Ihrer laufenden Version:
- TYPO3 11 oder älter: Kein regulärer Support, keine Sicherheitsupdates. Das Upgrade ist kein Projekt mehr, sondern eine Sicherheitsmaßnahme.
- TYPO3 12: Der reguläre Support endete am 30. April 2026. Ohne ELTS-Vertrag erhalten Sie seitdem keine Sicherheitsupdates. Entweder ELTS buchen — verfügbar bis April 2030 — oder zügig migrieren.
- TYPO3 13: Support bis Ende Dezember 2027. Kein Zeitdruck, aber ein guter Zeitpunkt, weil die Extension-Landschaft inzwischen weitgehend auf v14 aufgeschlossen hat.
- Bereits auf v14: Nichts zu tun außer regelmäßigen Patch-Updates.
Zwei Faktoren verschieben diese Einschätzung nach vorne: mehr als zehn Third-Party-Extensions im Einsatz oder Eigenentwicklungen mit veralteten APIs. In beiden Fällen beginnt die Arbeit nicht mit dem Upgrade, sondern mit dem Extension-Audit — und der bestimmt den Termin, nicht umgekehrt.
Support-Zeiträume im Überblick
Die Fristen stehen tagesgenau bei der TYPO3 GmbH — sie orientieren sich nicht am Release-Monat, weshalb kursierende Zusammenfassungen regelmäßig voneinander abweichen. Woher die Abweichungen kommen und was der jeweilige Weg kostet, steht in unserer Übersicht der TYPO3-Versionen und Support-Zeiträume.
Regulärer Support der aktuellen LTS-Versionen
| Version | LTS-Release | Regulärer Support bis | Danach |
|---|---|---|---|
| TYPO3 12 LTS | April 2023 | 30. April 2026 (beendet) | ELTS bis April 2030 |
| TYPO3 13 LTS | Oktober 2024 | 31. Dezember 2027 | ELTS regulär bis 31. Dezember 2030 |
| TYPO3 14 LTS | 21. April 2026 | 30. Juni 2029 | ELTS regulär bis 30. Juni 2032 |
Was TYPO3 14 mitbringt
Überarbeitetes Backend. Klarere Navigation, konsistentere Bedienelemente, eine zentrale Breadcrumb und ein Integrations-Modul, das Webhooks und Reactions an einem Ort bündelt. Für Redaktionen der spürbarste Teil: weniger Klicks pro Vorgang und weniger Orientierungsverlust. Das Context Panel erlaubt zusätzlich, Inhalte direkt im Seitenkontext zu bearbeiten.
Content Blocks im Core. Eigene Inhaltselemente entstehen deklarativ über eine config.yaml statt über verteilte TCA-, TypoScript- und Template-Dateien. Aus sechs bis acht Dateien pro Element werden zwei bis drei. Wie das konkret aussieht, steht im Artikel zu Content Blocks.
Schnittstelle für KI-Werkzeuge. TYPO3 baut keine KI ein, sondern stellt eine API-Schicht bereit, über die externe Dienste angebunden werden — Texte entwerfen, kürzen, übersetzen, direkt im Backend. Der modulare Ansatz ist im DSGVO-Kontext der entscheidende Punkt: Anbieterwahl, Datenfluss und Verarbeitungsort bleiben Ihre Entscheidung.
Headless und Mixed Mode. TYPO3 kann Inhalte als JSON ausliefern und damit entkoppelte Frontends bedienen. Der Mixed Mode erlaubt Parallelbetrieb: Anfragen mit Accept: application/json erhalten JSON, alle anderen klassisches HTML. Das macht schrittweise Migrationen möglich, statt alles auf einmal umstellen zu müssen.
Modernisierte APIs. Für Entwickler relevant: ein zentraler SEO-RecordTitleProvider, das TypolinkBuilderInterface als Ersatz für den alten AbstractTypolinkBuilder, eine Registry für TCA-Item-Manipulation anstelle von Hooks, neue ViewHelper für Head- und Footer-Bereiche sowie vereinfachte Locale-Abfragen in TypoScript-Bedingungen.
Was den Aufwand bestimmt
Die Spanne für ein Major-Upgrade ist groß, und sie hängt an drei Größen — der Core-Sprung selbst ist die kleinste davon.
Erstens die Extension-Landschaft. Zehn gepflegte Extensions aus dem TER sind ein Nachmittag. Drei ungepflegte Extensions ohne Nachfolger können Wochen bedeuten, weil jede einzeln bewertet werden muss: forken, ersetzen, neu bauen oder streichen.
Zweitens Eigenentwicklungen. Jede eigene Extension muss gegen entfernte APIs geprüft werden. Das Deprecation-Log der laufenden Installation ist dafür die beste Quelle — vorausgesetzt, es lief lange genug, um auch selten genutzte Codepfade zu erfassen.
Drittens der Versionsabstand. Von v13 auf v14 ist ein Schritt. Von v12 auf v14 sind es zwei Sätze Breaking Changes gleichzeitig — machbar, aber schwerer zu diagnostizieren, weil bei einem Fehler beide Versionssprünge als Ursache infrage kommen.
Was den Aufwand nicht wesentlich beeinflusst: die Anzahl der Seiten oder Inhalte. Ein Projekt mit 2.000 Seiten und Standard-Extensions migriert schneller als eines mit 50 Seiten und fünf Eigenentwicklungen.
Systemvoraussetzungen
- PHP 8.2 oder höher. Empfohlen ist 8.4 oder neuer — PHP 8.2 erhält nur noch bis Ende 2026 Sicherheitsupdates, und niemand möchte zwei Monate nach dem TYPO3-Upgrade ein PHP-Upgrade nachschieben.
- MySQL 8.0+ oder MariaDB 10.4+
- Composer-basiertes Setup. Der Classic Mode wird nicht mehr unterstützt. Wer noch ohne Composer arbeitet, hat vor dem eigentlichen Upgrade einen eigenen Arbeitsschritt vor sich.
- Eine Testumgebung, die den Produktivstand exakt abbildet. In DDEV ist die in Minuten aufgesetzt.
Der Ablauf in drei Phasen
Der Weg ist in jedem Projekt derselbe, nur die Dauer unterscheidet sich:
Phase 1 — Analyse. Extension-Audit, Prüfung von PHP- und Datenbankversion, Auswertung des Deprecation-Logs. Ergebnis ist eine Aufwandsschätzung, die diesen Namen verdient.
Phase 2 — Migration. In der Testumgebung: Core aktualisieren, Extensions nachziehen, Schema synchronisieren, Upgrade Wizards ausführen, Breaking Changes auflösen.
Phase 3 — Verifizierung. Funktionale Tests entlang der kritischen Abläufe, Performance-Vergleich gegen vorher, Redirects prüfen, Go-live, danach 48 Stunden aktives Monitoring.
Die vollständige Schritt-für-Schritt-Anleitung mit allen Befehlen steht in der Upgrade-Checkliste — dieser Guide bleibt bewusst auf der Entscheidungsebene.
Die häufigsten Fehler
Zu spät anfangen. Wer beginnt, wenn der Support ausläuft, arbeitet unter Druck — und Druck erzeugt Abkürzungen, die später doppelt kosten. Sechs Monate Vorlauf sind realistisch.
Ohne Backup arbeiten. Vor jedem Versuch, nicht nur vor dem ersten. Der zweite Anlauf startet sonst auf einem Stand, den der erste bereits verändert hat.
Extensions ohne composer.json. Sie werden in v14 nicht mehr geladen — und zwar wortlos. Nach dem Core-Update mit extension:list prüfen, ob alles erkannt wird.
Upgrade Wizards überspringen. Sie migrieren Strukturen, die die neue Version voraussetzt. Was hier übersprungen wird, fällt Wochen später als schwer zuordenbarer Fehler auf.
Scheduler-Tasks vergessen. Ein Task, dessen CLI-Kommando es nicht mehr gibt, schlägt still fehl. Niemand merkt es, bis jemand nach dem nächtlichen Export fragt.
Site-Konfigurationen nicht abgleichen. Neue Pflichtfelder oder geänderte Standardwerte in config/sites/*/config.yaml können die Ausgabe beeinflussen.
Ohne Testumgebung migrieren. Der Aufwand für eine Kopie steht in keinem Verhältnis zum Risiko eines gescheiterten Produktiv-Upgrades.
Redirects vergessen. Ändern sich URL-Strukturen, gehört ein vollständiges Mapping dazu — siehe Redirect-Strategie.
Häufig gestellte Fragen
Bei gepflegten Standard-Extensions und einem Sprung von v13 reichen wenige Tage. Mit mehreren Eigenentwicklungen, ungepflegten Extensions oder einem Sprung von v12 werden daraus mehrere Wochen. Die Zahl der Seiten spielt fast keine Rolle — die Zahl der Extensions und Eigenentwicklungen bestimmt alles.
Ja. Sie arbeiten dann allerdings die Breaking Changes zweier Hauptversionen gleichzeitig ab, und bei Fehlern kommen beide Sprünge als Ursache infrage. Der Zwischenschritt über v13 kostet mehr Zeit, macht die Diagnose aber deutlich einfacher — bei vielen Eigenentwicklungen ist er die ruhigere Wahl.
Marktüblich liegt der Rahmen bei 2.000–10.000 €, abhängig von Versionsabstand und Extension-Landschaft. Die Kosten entstehen selten am Core-Update, sondern an der Nacharbeit: Anpassungen an Eigenentwicklungen, Template-Korrekturen, Tests. Ein Extension-Audit vorab ersetzt die Schätzung durch eine Zahl.
Sie erhalten seit dem 30. April 2026 keine regulären Sicherheitsupdates mehr. Für bekannt gewordene Lücken gibt es dann keine Patches — was in einem öffentlich erreichbaren System kein theoretisches Risiko ist. ELTS ist bis April 2030 buchbar und verschafft Ihnen Zeit, ersetzt das Upgrade aber nicht.
Meistens nicht gleichzeitig. Machen Sie zuerst das Upgrade sauber fertig, dann die Umstellung einzelner Elemente. Beides parallel macht die Fehlersuche unnötig schwer, weil bei jedem Problem zwei Ursachen infrage kommen.
Nicht zwingend. Ein erfahrenes Team führt das Upgrade anhand der Checkliste selbst durch. Sinnvoll wird externe Hilfe bei vielen Eigenentwicklungen, bei Extensions ohne Nachfolger, wenn keine Testumgebung existiert — oder wenn Ihr System bereits aus dem Support gefallen ist und unter Zeitdruck steht.
Wann sich Unterstützung lohnt
- Ihr System läuft auf v12 oder älter und ist damit ohne Sicherheitsupdates
- Der Extension-Audit ergibt mehrere Pakete ohne absehbares Update
- Es existieren umfangreiche Eigenentwicklungen mit unklarer API-Nutzung
- Keine Testumgebung vorhanden und keine Kapazität, eine aufzusetzen
- Das Upgrade soll mit Relaunch, Redesign oder Barrierefreiheit zusammenfallen
- Im Team fehlt die Zeit für Planung, Tests und einen kontrollierten Go-live
