TYPO3 Update trotz vieler Extensions, eigener Custom Extensions und eigenem Theme

Welche TYPO3-Versionen gerade zählen und welche Fristen gelten

Stand August 2026 erhalten nur TYPO3 13 LTS und TYPO3 14 LTS kostenlose Updates; TYPO3 12 LTS lief am 30. April 2026 aus und läuft seit dem 1. Mai 2026 ausschließlich mit einem ELTS-Vertrag weiter.

TYPO3 folgt einem festen Muster: Nach dem LTS-Release liefert das Core-Team etwa 18 Monate Bugfixes, danach etwa 18 Monate reine Sicherheitsupdates. Nach diesen rund drei Jahren endet der kostenlose Support. Danach bietet die TYPO3 GmbH Extended Long Term Support (ELTS) an, kostenpflichtig und pro Instanz. Wer eine TYPO3 veraltete Version betreibt, bekommt also weder Sicherheitspatches noch Kompatibilitätsanpassungen an neuere PHP-Versionen, solange kein ELTS-Vertrag läuft.

Wichtig für die Planung: Das PHP-Fenster einer TYPO3-Version ist enger als das Supportfenster. Eine Instanz auf TYPO3 11.5 läuft maximal auf PHP 8.3. PHP 8.2 selbst erhält nur bis 31. Dezember 2026 Sicherheitsupdates. Sie planen also nicht nur ein TYPO3 Upgrade, sondern parallel den PHP-Pfad Ihres Servers.

Der PHP-Bereich der ELTS-Versionen wächst mit: 12.4 unterstützt in den ELTS-Releases inzwischen PHP bis 8.4, 11.5 bis 8.3. Für 10.4 und 9.5 bleibt es bei PHP 7.4, was diese Instanzen auf Serverseite zunehmend teuer macht.

Der Upgrade-Pfad führt über die LTS-Stufen

Ein TYPO3 Update springt nicht direkt von einer alten auf die aktuelle Version, sondern arbeitet sich von LTS zu LTS vor, weil die Upgrade Wizards jeweils nur die Datenbank- und Konfigurationsmigrationen einer Stufe kennen.

Praktisch heißt das: Von 9.5 nach 14.3 sind fünf Stufen zu gehen. Jede Stufe hat ihren eigenen Satz Wizards, ihre eigenen entfernten APIs und ihr eigenes PHP-Fenster. Wer die Stufen überspringt, verliert die Migrationen dazwischen, etwa die Umstellung von sys_domain auf Site Handling oder die Umschreibung der Backend-Modul-Registrierung. Diese Migrationen später von Hand nachzubauen kostet ein Vielfaches.

PHP zuerst, dann der Core

Die TYPO3-Dokumentation empfiehlt eine Reihenfolge, die sich in der Praxis bewährt: Heben Sie zuerst PHP auf die höchste Version, die Ihre aktuelle TYPO3-Version noch unterstützt. Prüfen Sie, dass die Seite läuft. Erst danach heben Sie TYPO3 und lassen PHP unverändert. So wissen Sie bei jedem Fehler, ob er aus PHP oder aus dem Core kommt. Zwei getrennte Fehlerquellen in einem Schritt zu debuggen kostet mehr Zeit als der zusätzliche Deploy.

Composer-Umstellung: früh, nicht spät

Wenn Ihre Instanz noch im Classic mode läuft, also ohne Composer und mit Extensions im Verzeichnis typo3conf/ext, dann ziehen Sie diese Umstellung vor die Versionssprünge. Ab TYPO3 14.0 braucht jede Extension eine gültige composer.json, auch im Classic mode. Der Classic mode existiert weiter, aber die Werkzeugkette darum herum schrumpft, und ohne Composer bekommen Sie weder Rector noch Fractor noch den Upgrade Analyser sinnvoll zum Laufen.

Die Umstellung selbst ist überschaubar, wenn alle Extensions im TER oder auf Packagist liegen. Sie wird aufwendig, wenn eigene Extensions keine composer.json und keine sauberen Namespaces haben, oder wenn Patches direkt im Core liegen. Solche Core-Patches müssen Sie vor der Umstellung finden und in Composer-Patches oder eigene Extensions überführen.

Bestandsaufnahme vor dem ersten Commit

Bevor Sie eine Zeile Code ändern, brauchen Sie eine Tabelle mit jeder installierten Extension, ihrer Herkunft, ihrer TYPO3 Extension Kompatibilität zur Zielversion und der Ersatzoption; ohne diese Tabelle ist jede Aufwandsangabe geraten.

Extensions aus dem TER

Für jede Extension aus dem TYPO3 Extension Repository prüfen Sie auf extensions.typo3.org, ob es ein Release für Ihre Zielversion gibt, und auf Packagist, wie aktiv das Paket gepflegt wird. Achten Sie auf das Datum des letzten Commits und darauf, ob offene Issues zur Zielversion beantwortet werden. Eine Extension mit passendem Versionsconstraint, aber zwei Jahren ohne Commit, ist ein Risiko, kein Haken auf der Liste.

Sortieren Sie das Ergebnis in vier Körbe: läuft direkt, braucht ein Update mit kleinen Anpassungen, braucht einen Fork oder Patch, muss ersetzt werden. Der vierte Korb bestimmt Ihren Zeitplan, weil dort Datenmigration dazukommt.

Eigene Extensions

Bei jeder Custom Extension interessieren vier Kennzahlen: Umfang des PHP-Codes, Anzahl eigener Datenbanktabellen, Anzahl der Hooks und Events, an denen sie im Core hängt, und ob jemand im Haus sie noch erklären kann. Extensions ohne bekannten Autor und ohne Tests sind die eigentliche Kostenposition, nicht die Extensions mit vielen Zeilen Code.

Sehr oft finden Sie dabei Eigenbau, der heute vom Core abgedeckt wird: eigene Slug-Logik, eigene Redirect-Verwaltung, eigene Formularlösungen, eigene Bildbearbeitung. Solchen Code migrieren Sie nicht, sondern löschen ihn und konfigurieren die Core-Funktion. Das ist der billigste Teil des Projekts und der, der am häufigsten übersehen wird.

Theme und Fluid-Templates

Das Sitepackage bekommt eine eigene Zeile in der Planung. Fluid hat sich über die Versionen deutlich verändert, in TYPO3 14 mit Fluid 5 zuletzt spürbar. Prüfen Sie, wie viele Templates, Partials und Layouts existieren, wie viele eigene ViewHelper darin stecken und ob das Markup an einem gekauften Template klebt. Ein Sitepackage, das über zwei LTS-Stufen nicht angefasst wurde, verhält sich in der Migration eher wie eine Custom Extension als wie Konfiguration.

Werkzeuge, die die Arbeit messbar verkürzen

Upgrade Wizard und Extension Scanner im Core decken die Pflichtarbeit ab, ssch/typo3-rector und a9f/typo3-fractor übernehmen den mechanischen Teil der Code-Migration, und cpsit/typo3-upgrade-analyser liefert vorab die Bestandsaufnahme.

Zwei Dinge zur Erwartungshaltung. Rector nimmt Ihnen die stumpfe Arbeit ab, ersetzt aber kein Review: Jede erzeugte Änderung gehört in einen Commit, den ein Mensch gelesen hat. Und der Extension Scanner findet dynamische Aufrufe kaum, weil er bei variablen Klassennamen selten einen starken Treffer erzeugt. Nach dem Scanner brauchen Sie deshalb einen Klickpfad durch die Anwendung und im besten Fall PHPStan über Ihrem eigenen Code.

Typische Brüche in Custom Extensions und der jeweilige Migrationsschritt

Die meisten Fehler beim TYPO3 Custom Extension migrieren gehen auf vier entfernte Bausteine zurück: die alte Datenbank-API, ObjectManager::get(), das Signal/Slot-System und eigene View-Klassen.

Dependency Injection statt ObjectManager

Der ObjectManager war in älteren Extbase-Extensions der Standardweg, um an Repositories und Services zu kommen. Seit TYPO3 12 ist er weg. Die Umstellung ist mechanisch: Konstruktor-Parameter mit Typ deklarieren, Extension mit einer Configuration/Services.yaml versehen, Autowiring aktivieren. Rector deckt einen großen Teil dieser Änderungen ab. Aufwand entsteht dort, wo alte Extensions Objekte in Schleifen oder abhängig von Konfiguration erzeugen; solche Stellen brauchen eine Factory oder einen expliziten makeInstance-Aufruf und damit eine Entscheidung.

PSR-14 statt Signal/Slot, und wo Hooks bleiben

Signal/Slot wurde ab TYPO3 10.2 nach PSR-14 überführt und in TYPO3 12 vollständig entfernt. Für die Core-Signale existiert jeweils ein Event mit definierten Gettern und Settern. Prüfen Sie im Changelog, welches Event Ihr Signal ersetzt, und rechnen Sie damit, dass das neue Event manchmal einen anderen Zeitpunkt im Ablauf hat. Genau dort entstehen die stillen Fehler, die kein Scanner findet: Der Code läuft, aber zu früh oder zu spät.

Klassische Hooks im Array $GLOBALS['TYPO3_CONF_VARS'] existieren teilweise weiter, werden aber Stufe um Stufe durch Events ersetzt. Wenn Ihre Extension an einem Hook hängt, für den es ein Event gibt, migrieren Sie ihn im gleichen Durchgang. Sie sparen sich damit die Suche beim nächsten Sprung.

Datenbankzugriff über Doctrine

Instanzen, die aus TYPO3 8 oder früher kommen, enthalten fast immer noch handgeschriebenes SQL über die alte Datenbank-API. Die Umstellung auf ConnectionPool und QueryBuilder ist der Teil, bei dem Sie Tests brauchen. Restrictions verhalten sich anders als die alten enableFields-Aufrufe, Prepared Statements ändern das Verhalten bei leeren IN-Listen, und Sprachüberlagerungen laufen über andere Methoden. Rechnen Sie hier mit echter Prüfarbeit pro Abfrage statt mit einem Sammel-Refactoring.

TypoScript: neuer Parser und Site Sets

TYPO3 12 hat den TypoScript-Parser neu geschrieben, TYPO3 13 hat den alten entfernt. Die häufigste Stolperstelle betrifft Konstanten: Rekursive Konstanten, also eine Konstante, die eine andere Konstante liest, funktionieren nicht mehr. In gewachsenen Sitepackages steckt das oft in Farb- und Pfadkonstanten. Die Regel für die Migration ist knapp: Greifen Sie in einer Konstante niemals auf eine andere Konstante zu.

Ab TYPO3 13.1 stehen Site Sets bereit. Sie bündeln TypoScript, TSconfig und Settings einer Extension in einer Einheit mit deklarierten Abhängigkeiten und lösen die Reihenfolgeprobleme langer Include-Ketten. Der Template-Datensatz auf der Root-Seite kann dann entfallen. Das ist kein Pflichtschritt beim Upgrade, spart aber bei jeder weiteren Änderung Zeit und lohnt sich, wenn Sie das Sitepackage sowieso anfassen.

Fluid 5 in TYPO3 14

Drei Änderungen in Fluid 5 treffen fast jedes Projekt. Inhalte in CDATA-Blöcken ignoriert der Parser jetzt, was inline eingebettetes CSS und JavaScript einfacher macht, aber bestehende Templates verändert. Variablennamen mit führendem Unterstrich sind nicht mehr erlaubt. Und ViewHelper arbeiten strikter mit Typen: Argumente werden validiert, null-Werte führen bei tag-basierten ViewHelpern dazu, dass das HTML-Attribut ganz entfällt, und eigene ViewHelper brauchen Typdeklarationen. Ab TYPO3 13.4.21 schreibt der Core Warnungen für die ersten beiden Punkte in das Deprecation-Log. Nutzen Sie diese Phase: Lassen Sie die Instanz einige Wochen auf 13.4 mit aktivem Log laufen, bevor Sie auf 14 gehen.

Aufwandsabschätzung nach Anzahl und Art der Extensions

Ein belastbarer Aufwand entsteht erst nach der Bestandsaufnahme, aber die folgenden Bandbreiten helfen, eine Größenordnung zu prüfen, bevor Sie Budget beantragen.

Annahmen für die Tabelle: ein einzelner LTS-Sprung, das Team kennt TYPO3 und Extbase, der gesamte Code liegt in Git, es existiert eine Staging-Umgebung mit aktuellem Datenbank-Abzug, und ein Personentag entspricht acht Arbeitsstunden. Die Zahlen sind Personentage für Umsetzung inklusive Entwicklertest, ohne Redaktionsabnahme und ohne Projektleitung. Bei zwei oder mehr Stufen multiplizieren Sie nicht einfach, sondern rechnen für jede zusätzliche Stufe grob mit 50 bis 70 Prozent des ersten Sprungs, weil Werkzeuge und Wissen wiederverwendet werden.

Zur Einordnung ein gerechnetes Beispiel mit den obigen Annahmen: Eine Instanz auf TYPO3 11.5, Composer-basiert, 25 Extensions, davon 19 aus dem TER mit Release für 13.4, drei TER-Extensions ohne Release, fünf eigene Extensions mittlerer Größe, ein Sitepackage aus der 10.4-Zeit. Ziel ist 13 LTS über die Stufe 12.4. Für die reine Umsetzung landen Sie mit dieser Struktur im Bereich von etwa 35 bis 70 Personentagen, plus Abnahme. Die Spanne ist weit, und sie wird nach der Bestandsaufnahme deutlich schmaler. Weit bleibt sie vor allem wegen der drei TER-Extensions ohne Release und wegen der Frage, ob das Sitepackage migriert oder neu gebaut wird.

Was den Aufwand am stärksten treibt

• Fehlende Tests in eigenen Extensions. Ohne Tests verlagert sich der Aufwand vom Code in die manuelle Prüfung, und zwar bei jeder Stufe erneut.
• Extensions ohne Ansprechpartner. Code, den niemand erklärt, muss erst gelesen werden, bevor er migriert werden kann.
• Patches direkt im Core oder in Vendor-Verzeichnissen. Diese verschwinden beim Update und fallen erst im Betrieb auf.
• Content, der an Extension-Strukturen klebt. Eigene Content-Element-Typen mit FlexForm-Feldern binden Redaktionsdaten an Code.
• Schnittstellen, deren Gegenstelle nicht testbar ist. Ein ERP ohne Testsystem verlängert jede Abnahme.

ELTS: wann Zeitkauf sinnvoll ist

TYPO3 ELTS kauft Ihnen Zeit für eine Instanz, deren Upgrade organisatorisch noch nicht möglich ist, ersetzt aber kein Upgrade und läuft selbst mit einem festen Enddatum.

ELTS liefert Sicherheitsupdates und Kompatibilitätsanpassungen für eine Version, die kostenlos nicht mehr unterstützt wird. Die TYPO3 GmbH lizenziert pro Instanz und pro Jahr; jedes Projekt braucht seinen eigenen Vertrag. Für 12.4 begann ELTS am 1. Mai 2026 und lässt sich bis 30. April 2030 verlängern, wobei das vierte Jahr nur TYPO3-Partnern offensteht. Für 11.5 endet ELTS am 31. Oktober 2028, für 10.4 am 30. April 2027. Für 9.5 ist es am 30. September 2025 ausgelaufen; solche Instanzen laufen heute ohne jede Sicherheitsversorgung.

Die Preise nennt TYPO3 versions- und jahresabhängig; für das vierte ELTS-Jahr von 12.4 gibt TYPO3 3.200 Euro pro Single Plan an. Verbindliche Zahlen für Ihre Version und Ihren Zeitraum holen Sie über my.typo3.org oder direkt bei TYPO3 ein. Rechnen Sie diese Summe gegen die verschobenen Upgrade-Kosten: ELTS ist sinnvoll, wenn ein Relaunch bereits terminiert ist und Sie eine Lücke von zwölf bis vierundzwanzig Monaten überbrücken. ELTS ist ein schlechtes Geschäft, wenn Sie damit jahrelang den gleichen Aufschub finanzieren, denn der Migrationsaufwand wächst mit jeder Stufe, die zwischen Ihnen und der aktuellen Version liegt.

Jede LTS-Stufe, die Sie überspringen, bezahlen Sie später doppelt: einmal für die Migration selbst und einmal dafür, dass niemand mehr weiß, warum der Code so aussieht.

Wann Neubau günstiger ist als Update

Ein Neubau rechnet sich, wenn der Migrationsaufwand des Eigenbaus höher liegt als der Aufwand, dieselbe Funktion auf heutigen Core-Mitteln neu zu bauen, und das entscheiden Sie pro Baustein, nicht pauschal für die ganze Instanz.

Diese Anzeichen sprechen für Neubau der betroffenen Teile:

• Die Instanz kommt aus TYPO3 8 oder älter, läuft im Classic mode, ohne Site Handling und mit RealURL. Vier bis fünf Stufen Migration kosten dann mehr als ein sauberer Aufsatz mit Content-Import.
• Mehr als die Hälfte der eigenen Extensions hat keine Tests, keine Dokumentation und keinen Autor im Haus.
• Die eigenen Extensions bauen nach, was der Core heute liefert: Formulare, Redirects, Slugs, Content-Elemente, Dateiverwaltung.
• Das Theme klebt an einem gekauften HTML-Template, und das Markup ist über Partials und ViewHelper verstreut.
• Ein Design-Relaunch oder eine neue Informationsarchitektur steht in den nächsten zwölf Monaten ohnehin an.
• Die Inhaltsmenge ist überschaubar, sodass Redaktionsdaten über einen Import statt über Schema-Migrationen übernommen werden können.

Diese Anzeichen sprechen gegen Neubau und für das Update:

• Viele Seiten und viele Assets mit gepflegten Metadaten, Kategorien und Verweisen. Der Import wird dann selbst zum Projekt.
• Ein eingespieltes Redaktionsteam mit gelernten Abläufen, Rechten und Freigaben. Ein Neubau bedeutet hier Schulung und Produktivitätsverlust.
• Schnittstellen zu ERP, PIM oder Shop, die an Custom Extensions hängen und vertraglich abgesichert sind.
• SEO-Bestand mit gewachsener URL-Struktur, die im Neubau vollständig abgebildet werden müsste.

In der Praxis gewinnt meist der Mittelweg: Core und Extensions per Update über die Stufen heben, das Sitepackage neu bauen und die zwei oder drei Custom Extensions, die Core-Funktionen nachbauen, ersatzlos löschen. Sie behalten Inhalte, Redaktionsabläufe und URLs, und Sie werfen genau den Code weg, der die Migration teuer macht. Das ist bei gewachsenen Instanzen fast immer die günstigste Variante, und sie hält den Betrieb während des Projekts lauffähig.

Ein Vorgehen, das im Mittelstand hält

Ein Upgrade-Projekt läuft dann verlässlich, wenn jede Stufe für sich deploybar ist und die Produktion bis zum Umschalten unangetastet bleibt.

• Bestandsaufnahme: Extension-Liste mit Herkunft und Zielversions-Status, Report aus cpsit/typo3-upgrade-analyser, Sichtung der Custom Extensions.
• Zielversion festlegen. 13 LTS, wenn Sie Extension-Verfügbarkeit priorisieren und in etwa einem Jahr wieder anfassen können. 14 LTS, wenn Sie den längeren Sicherheitshorizont bis 30. Juni 2029 wollen und den Fluid-5-Aufwand einplanen.
• Staging aufsetzen: aktueller Datenbank-Abzug, gleiche PHP-Version wie Produktion, alles in Git, Deployment automatisiert.
• PHP auf das Maximum der aktuellen TYPO3-Version heben und produktiv nehmen. Das ist der erste messbare Gewinn und senkt das Risiko der Folgeschritte.
• Stufe für Stufe: Core per Composer heben, Extensions nachziehen, Extension Scanner laufen lassen, Rector und Fractor anwenden, Upgrade Wizards abarbeiten, Database Analyzer prüfen, Klickpfad testen, Stufe committen.
• Deprecation-Log auf der letzten Zwischenstufe aktiv lassen und auswerten, bevor Sie auf die Zielversion gehen.
• Redaktion früh einbeziehen. Zwei Personen aus dem Team testen ihre echten Arbeitsabläufe auf Staging, nicht eine Checkliste.
• Umschalten mit Content-Freeze, Redirect-Prüfung und einem Rollback-Plan, der getestet ist und nicht nur dokumentiert.

Planen Sie außerdem den Zeitpunkt für das nächste Upgrade direkt mit ein. Wenn Sie nach dem Projekt jährlich zwei bis vier Personentage für Extension-Pflege und Core-Minor-Updates reservieren, bleibt der nächste LTS-Sprung ein normales Vorhaben statt eines Sonderprojekts. Genau dieser Posten fehlt in den Instanzen, die heute vier Stufen zurückliegen.

Was Sie in den nächsten Wochen entscheiden sollten

Wenn Ihre Instanz auf TYPO3 12 oder älter läuft, brauchen Sie zwei Entscheidungen: die Zielversion und die Frage, ob ELTS die Übergangszeit abdeckt.

Für TYPO3 12 ist der kostenlose Support seit 1. Mai 2026 beendet. Ohne ELTS-Vertrag läuft die Instanz ohne Sicherheitsupdates, was bei Kundendaten und bei jeder Form von E-Commerce-Anbindung ein Haftungsthema ist. Für TYPO3 11 und 10 gilt das schon länger. Die technische Arbeit unterscheidet sich dabei kaum zwischen den Ausgangsversionen; unterschiedlich ist nur die Anzahl der Stufen und damit der Preis.

Der nächste sinnvolle Schritt ist die Bestandsaufnahme, nicht das erste Composer-Kommando. Eine Extension-Liste mit Kompatibilitätsstatus und eine ehrliche Bewertung der eigenen Extensions kosten wenige Tage und verschieben die Aufwandsschätzung von einer Spanne über den Faktor zwei auf eine Spanne, mit der sich planen lässt. Auf dieser Grundlage entscheiden Sie pro Baustein zwischen Migration, Ersatz und Löschen, und Sie wissen, welche Teile Sie neu bauen.

Alle Fristen und Versionsangaben nach den unten genannten Quellen, Stand August 2026.