Zum Inhalt springen
Abstrakte Formen aus Glas und dunklem Papier: ein Block mit vielen Anbauteilen wird auf einen höheren Sockel gehoben

TYPO3-Major-Update: Aufwand realistisch einschätzen

Den Aufwand eines TYPO3-Updates auf die nächste LTS-Version bestimmen die Extensions, die eigenen Templates und die Zahl der Hauptversionen bis zum Ziel, kaum die Zahl der Seiten. Eine Inventur vorab zeigt, ob Update in Stufen, Neuaufbau oder ein anderes System passt.

8 min Lesezeit Performance & DevOps

Ein Major-Update von TYPO3 ist ein eigenes kleines Projekt. Der Core bringt Werkzeuge mit, die Datenbank und Konfiguration anpassen, und für PHP-Code gibt es Hilfen, die Änderungen automatisch vorschlagen. Was keine Automatik übernimmt, sind Extensions ohne passende Version, eigene Erweiterungen und Templates, die auf entfernte Funktionen bauen. Diese drei Posten schätzen Sie einzeln, bevor Sie einen Gesamtaufwand nennen.

Zum Stichtag dieses Beitrags, dem 20.08.2026, betrifft das vor allem zwei Gruppen: Betreiber von TYPO3 12, dessen kostenloser Support am 30.04.2026 endete, und Betreiber von TYPO3 13, die den Wechsel auf TYPO3 14 LTS vor Ende 2027 einplanen wollen.

Treiber

Was den Aufwand bestimmt

Vier Faktoren entscheiden, ob ein Update Tage oder Wochen dauert:

  1. Extensions. Jede Extension braucht eine Version für die Ziel-LTS. Gibt es sie, ist es meist ein Versionssprung mit Test. Gibt es sie nicht, muss jemand die Extension anpassen, ersetzen oder ihre Funktion neu bauen.

  2. Eigener Code. Eigene Extensions, Hooks und überschriebene Core-Klassen greifen auf Schnittstellen zu, die TYPO3 mit jeder Hauptversion umbaut. Was eine Version vorher als veraltet markiert war, ist in der nächsten entfernt.

  3. Templates und Konfiguration. Das Sitepackage mit Fluid-Templates, TypoScript, FlexForms und Backend-Layouts muss zur neuen Version passen.

  4. Abstand zur Ziel-LTS. Von TYPO3 13 auf 14 ist es ein Schritt, von TYPO3 11 auf 14 sind es drei.

Die Größe der Website fällt dagegen kaum ins Gewicht. Tausend Seiten mit denselben Inhaltselementen machen beim Update kaum mehr Arbeit als hundert, weil die Upgrade-Assistenten die Datensätze in einem Durchlauf anpassen.

Supportfristen

LTS-Zyklen und Supportende

TYPO3 veröffentlicht pro Hauptversion mehrere Zwischenversionen und am Ende eine LTS-Version mit langer Pflege. Die Termine laut get.typo3.org und der TYPO3-Ankündigung vom 29.04.2026, Stand 20.08.2026:

  • TYPO3 11 LTS: Sicherheits- und kritische Korrekturen bis Oktober 2024, danach nur noch kostenpflichtig über ELTS.

  • TYPO3 12 LTS: erschienen am 25.04.2023, kostenlose Pflege bis 30.04.2026. Danach bietet die TYPO3 GmbH kostenpflichtigen Extended Long Term Support (ELTS) bis 30.04.2030 an. Läuft PHP 8.1 bis 8.4.

  • TYPO3 13 LTS: erschienen am 15.10.2024, Sicherheitsupdates bis Ende Dezember 2027. Läuft PHP 8.2 bis 8.5.

  • TYPO3 14 LTS: Version 14.3 erschien am 21.04.2026, Fehlerbehebungen bis Dezember 2027, Sicherheitsupdates bis Ende Juni 2029. Läuft PHP 8.2 bis 8.5.

Für die Planung folgt daraus: Wer auf TYPO3 12 ohne ELTS-Vertrag läuft, bekommt seit dem 01.05.2026 keine Sicherheitskorrekturen mehr. Wer auf TYPO3 13 läuft, hat Zeit bis Ende 2027, sollte das Update aber nicht in den letzten Monaten erledigen wollen. Hinzu kommt die PHP-Version darunter: PHP 8.2 bekommt ab dem 01.01.2027 keine Sicherheitsupdates mehr, die Folgen beschreibt der Beitrag PHP 8.2 Supportende. Ein Wechsel auf TYPO3 14 lässt sich gut mit dem Wechsel auf PHP 8.4 oder 8.5 verbinden, weil TYPO3 13 diese Versionen ebenfalls unterstützt. So kann der Server zuerst und für sich allein umgestellt werden.

Ein Sortimentskasten mit Kleinteilen in ihren Fächern, drei Teile sind orange, sie müssen geprüft werden.

Inventur

Bestandsaufnahme vor der Schätzung

Die Bestandsaufnahme beantwortet für jedes Teil der Installation eine Frage: Gibt es eine Version für die Ziel-LTS, und wenn nicht, was dann?

Extensions

Im Backend zeigt der Extension Manager alle installierten Extensions, in Composer-Installationen steht die vollständige Liste in der composer.lock. Für jede Extension aus dem TYPO3 Extension Repository (TER) oder von Packagist prüfen Sie, ob eine Version die Ziel-LTS als kompatibel angibt und wann sie zuletzt aktualisiert wurde. Eine Extension ohne Veröffentlichung seit zwei Hauptversionen ist ein Kandidat für Ersatz.

Eigener Code

Für eigene Extensions bringt TYPO3 im Modul „Upgrade“ den Extension Scanner mit. Er durchsucht den Code nach Stellen, die laut Changelog veraltet oder entfernt sind, und unterscheidet sichere und unsichere Treffer. Für die eigentliche Anpassung gibt es TYPO3 Rector (Paket ssch/typo3-rector), das PHP-Code für die TYPO3-Versionen 10 bis 14 umschreibt, und Fractor (Paket a9f/typo3-fractor) für TypoScript, FlexForms, Fluid und YAML. Beide Projekte warnen ausdrücklich davor, sie auf dem Produktivsystem laufen zu lassen. Ihre Vorschläge gehören in eine Versionsverwaltung und in eine Prüfung durch einen Entwickler.

Server und Datenbank

Prüfen Sie die PHP-Version, mit der der Webserver wirklich läuft, und die Datenbankversion. TYPO3 13 und 14 verlangen laut get.typo3.org mindestens MySQL 8.0.17 oder MariaDB 10.4.3. Ein älterer Datenbankserver ist ein eigener Arbeitsschritt beim Hoster.

Inventurliste

Eine Zeile je Bestandteil

Legen Sie in einer Tabellenkalkulation eine Zeile je Bestandteil der Installation an: Core, PHP, Datenbank, jede Extension, jede eigene Extension, Fluid-Templates, TypoScript und TSconfig, FlexForms und Backend-Layouts sowie jede Schnittstelle zu Formularen, Newsletter, Shop oder Single Sign-on. Diese Spalten haben sich für die Schätzung als ausreichend erwiesen:

  1. Bereich und Name: zum Beispiel „Extension“ und der Extension-Key.

  2. Installierte Version und Quelle: TER, Composer oder eigene Entwicklung.

  3. Version für die Ziel-LTS vorhanden: vorhanden, nicht vorhanden oder unklar, mit Datum der letzten Veröffentlichung.

  4. Ersatz: ein gepflegtes Paket mit derselben Funktion, falls es keine passende Version gibt.

  5. Aufwandsklasse: S, M oder L.

  6. Notiz: Treffer des Extension Scanners, Zahl der Templates und Partials, Besonderheiten wie die PHP-Version laut Webserver statt laut Kommandozeile.

Die Spalte Aufwandsklasse ist eine Einschätzung, keine Messung. Die drei Klassen bedeuten:

  • S: Eine kompatible Version existiert. Version anheben, Änderungsprotokoll lesen, Funktion testen. Meist Stunden.

  • M: Eigener Code oder Templates müssen angepasst werden. Rector und Fractor nehmen einen Teil ab, das Ergebnis muss geprüft werden. Meist Tage.

  • L: Keine kompatible Version und kein direkter Ersatz. Die Funktion wird ersetzt oder neu gebaut. Das kann Wochen dauern.

Die Zahl der L-Zeilen sagt mehr über den Gesamtaufwand als jede andere Zahl in der Liste, weil jede L-Zeile ein eigenes kleines Entwicklungsprojekt mit Fachfragen auslöst.

Drei Wege

Update, Neuaufbau oder Wechsel

Mit der ausgefüllten Liste lassen sich drei Wege vergleichen.

Update in Stufen. Die bestehende Installation wird Hauptversion für Hauptversion angehoben. Laut TYPO3-Dokumentation enthält der Core die Upgrade-Assistenten für zwei aufeinanderfolgende Hauptversionen. Ältere Assistenten bündelt die Extension wapplersystems/core-upgrader; ihre Beschreibung nennt Upgrades von TYPO3 7.6 bis 11.5 mit Ziel TYPO3 13.4. Für einen Sprung direkt auf TYPO3 14 ist sie nicht ausgewiesen, dort führt der Weg über 13.4. Vor jedem Sprung laufen die Assistenten der installierten Version vollständig durch. Dieser Weg passt, wenn die Liste überwiegend S- und M-Zeilen zeigt.

Neuaufbau in TYPO3. Eine frische Installation von TYPO3 14 mit neuem Sitepackage, in die Seitenbaum und Inhalte übernommen werden. Er passt, wenn das Sitepackage mehrere Versionen alt ist und ohnehin neu gestaltet werden soll, die Redaktion aber bei TYPO3 bleiben will.

Wechsel des Systems. Wenn die Liste viele L-Zeilen zeigt und die Website die Rechte- und Workflow-Tiefe von TYPO3 nicht nutzt, steht auch ein anderes CMS zur Wahl. Ein Wechsel ist allerdings selbst ein Projekt: Inhalte werden übertragen, Templates neu gebaut, die Redaktion lernt eine neue Oberfläche. Unsere Gegenüberstellung Statamic und TYPO3 nennt für Behörden, Hochschulen und große Redaktionen mit Freigabestufen TYPO3 als die bessere Wahl. Wie Inhalte bei einem Wechsel auf neue Felder abgebildet werden, zeigt der Beitrag ACF-Felder nach Statamic übertragen am Beispiel WordPress.

Vergleichen Sie die drei Wege mit denselben Zeilen: Aufwand laut Inventur, Dauer, Schulungsbedarf der Redaktion und die nächste Frist, zu der wieder ein großes Update ansteht. Bei TYPO3 14 LTS ist das laut Plan Ende Juni 2029.

Abnahme

Zeitplan und Abnahme für das Update

Ein Update wird in Abschnitten geplant, die jeweils für sich abgenommen werden. Eine Reihenfolge, die sich aus der Inventur ergibt:

  1. Server vorbereiten: PHP und Datenbank auf Versionen heben, die Ausgangs- und Zielversion beide unterstützen, und das allein ausliefern.

  2. Kopie aufsetzen: eine vollständige Kopie mit dem Inhaltsstand des Produktivsystems auf einer Staging-Umgebung.

  3. Je Hauptversion: Extensions anheben, Code anpassen, Datenbank über den Database Analyzer abgleichen, Upgrade-Assistenten ausführen, testen.

  4. Abnahme auf Staging: nach einer vorher vereinbarten Liste, zum Beispiel alle Seitentypen, alle Formulare mit Testversand, Suche, Mehrsprachigkeit, Rechte der Redakteure, Weiterleitungen.

  5. Umstellung: im angekündigten Wartungsfenster, mit Datenbanksicherung und einem vorbereiteten Rückweg.

Dass sich Abnahmekriterien pro Abschnitt auch bei TYPO3-Projekten tragen, zeigt unsere Case Study Online-Portal mit zwei CMS unter einem Dach aus dem Jahr 2012: Das Portal auf TYPO3 und WordPress haben wir zum Festpreis in zehn Meilensteine geteilt, mit eindeutigen Abnahmekriterien pro Rate, und jeder Schritt wurde abgenommen, bevor der nächste begann.

Nach der Umstellung beginnt die Vorbereitung auf das nächste Update. Wer Patch-Versionen laufend einspielt, hat beim nächsten Major-Update weniger nachzuholen. Warum kleine, regelmäßige Updates günstiger sind, begründet der Beitrag Patch-Disziplin. Die gleiche Stufenlogik für Laravel-Anwendungen beschreibt Laravel-Upgrade planen.

Fragen zum Upgrade

Häufige Fragen

  • Für TYPO3 13 nennt TYPO3 Sicherheitsupdates bis Ende Dezember 2027, für TYPO3 14 Fehlerbehebungen bis Dezember 2027 und Sicherheitsupdates bis Ende Juni 2029. Danach verkauft die TYPO3 GmbH Extended Long Term Support, für TYPO3 12 zum Beispiel bis 30.04.2030. ELTS liefert Sicherheitskorrekturen für die alte Version, aber keine neuen Funktionen und keine Unterstützung neuerer PHP-Versionen über die genannten hinaus.

  • Die Zielversion lässt sich direkt installieren, die Upgrade-Assistenten im Core decken aber nur zwei aufeinanderfolgende Hauptversionen ab. Für ältere Sprünge gibt es die Extension wapplersystems/core-upgrader, die laut Beschreibung bis TYPO3 13.4 reicht, und alle Änderungen dazwischen wirken gleichzeitig. Bei großem Abstand ist deshalb ein Neuaufbau mit Übernahme der Inhalte oft die übersichtlichere Wahl.

  • Sie blockiert das Update, sobald sie die Ziel-LTS nicht unterstützt. Dann bleibt die Wahl zwischen einem gepflegten Ersatz, einer eigenen Weiterentwicklung der Extension oder dem Verzicht auf die Funktion. Diese Entscheidung gehört vor dem Projektstart in die Inventurliste.

Updates, die nicht liegen bleiben

Ist das Major-Update geschafft, halten regelmäßige System- und Sicherheitsupdates mit Backups die Installation auf Stand, bis die nächste LTS ansteht. So beschreiben wir es auf der Seite zur Wartung.

Zur Wartung

Nachweise

Quellen und Stand

Stand: 20.08.2026. Supportfristen und Systemanforderungen laut get.typo3.org und TYPO3-Ankündigung vom 29.04.2026, Upgrade-Werkzeuge laut TYPO3-Dokumentation und den Projektseiten von TYPO3 Rector, Fractor und core-upgrader. Die Aufwandsklassen S, M und L sind Erfahrungswerte zur Einordnung, keine Messwerte.