TYPO3 LTS: Warum der Update-Rhythmus ein strategischer Vorteil ist
Was LTS im TYPO3-Kontext konkret bedeutet
TYPO3 folgt einem klar definierten Release-Modell: Jede LTS-Version (Long Term Support) erhält drei Jahre aktiven Community-Support. In dieser Zeit werden Sicherheitslücken geschlossen, schwerwiegende Fehler behoben, und die Version bleibt offiziell gepflegt. Danach folgt optional eine weitere Phase: ELTS, Extended Long Term Support, für vier weitere Jahre. Diese Phase ist kostenpflichtig und wird außerhalb des Community-Rahmens von der TYPO3 GmbH organisiert.
Das bedeutet in der Praxis: Wer eine TYPO3-LTS-Version betreibt, hat bis zu sieben Jahre eine technisch gestützte Basis: drei Jahre gratis, vier Jahre gegen Lizenzgebühr. Wer weder das eine noch das andere wahrnimmt, betreibt ein System ohne aktive Sicherheitskorrekturen. Eine direkte Konsequenz des Modells, keine Interpretation.
Die bisherige LTS-Sequenz zeigt, wie verlässlich der Rhythmus läuft: 4.5 → 4.7 → 6.2 → 7.6 → 8.7 → 9.5 → 10.4 → 11.5 → 12.4 → 13.4 → 14.3. Zwischen zwei Major-Versionen liegen typischerweise 18 Monate, ein Takt, der sich über mehr als eine Dekade als stabil erwiesen hat. Die offizielle Timeline mit exakten Daten für aktive Support- und ELTS-Phasen jeder Version finden Sie unter typo3.org/cms/roadmap; die dort bereitgestellte Grafik zeigt den Support-Horizont auf einen Blick.
Der Rhythmus als Planungsbasis
Wer den 18-Monats-Takt kennt und konsequent nutzt, kann ihn einplanen — nicht reagieren, sondern antizipieren. Das ist der eigentliche strategische Vorteil: nicht die Technologie an sich, sondern die Vorhersehbarkeit, die sie bietet. Denn ein vorhersehbares System lässt sich budgetieren, mit Jahresplanungen verzahnen und in Ruhe testen, ohne dass ein auslaufendes Support-Datum plötzlich zur Notfall-Priorität wird. Wer eine TYPO3-Site betreibt, kann den nächsten LTS-Wechsel bereits im aktuellen Budget einplanen; der Termin ist bekannt. Gleiches gilt für ELTS: Wer heute weiß, wann sein LTS-Support ausläuft, kann frühzeitig entscheiden, ob er wechselt oder überbrückt.
Wann ist der richtige Zeitpunkt zum Wechsel?
Unsere Empfehlung: nicht sofort mit der .0-Version des LTS einsteigen, aber auch nicht bis zum Ende des aktiven Supports zögern. Der sinnvolle Einstiegspunkt liegt bei der ersten Patch-Version nach dem LTS-Release, also beispielsweise 13.4.1 statt 13.4.0. Zu diesem Zeitpunkt sind die gröbsten Anlaufprobleme behoben, die Community hat erste Praxiserfahrungen dokumentiert, und Extensions sind in der Regel angepasst, da Maintainer ihre Pakete üblicherweise kurz nach dem LTS-Release aktualisieren. Extensions vorab testen lässt sich selbstverständlich bereits an 13.4.0 — das Produktivsystem würde CWD aber erst nach dem ersten Patch darauf heben.
Das Prinzip dahinter: Wer auf den ersten Patch des LTS-Release wartet und dann wechselt, muss weder einem frischen Release vertrauen noch auf Sicherheitskorrekturen für eine auslaufende Version warten. Der Wechsel kommt, bevor er dringend wird. Genau das ist der Unterschied zwischen geplantem Aufwand und ungeplanter Krise.
Minor-Updates und Major-Updates sind nicht dasselbe
Ein Punkt, der in der Praxis regelmäßig unterschätzt wird: Minor-Updates, also 13.0 → 13.1 → 13.4, sind planbare Pflege. Sie sind in der Regel rückwärtskompatibel, erfordern selten manuelle Eingriffe in Konfigurationen oder Templates und lassen sich in vielen Projekten innerhalb weniger Stunden sauber abwickeln. Das gehört zur laufenden Wartung, nicht zu einem dedizierten Projekt.
Major-Updates sind echte Arbeit. Beim Sprung von 12.4 auf 13.4 werden Deprecations hart entfernt, Extensions müssen auf Kompatibilität geprüft oder ausgetauscht werden, Templates und TypoScript können sich nennenswert verändern. Kein Grund, Major-Updates zu scheuen. Aber ein Grund, sie nicht zu ignorieren, bis zwei Versionen übersprungen wurden — dann wird aus einem planbaren Vorhaben ein ungeplanter Notfall.
ELTS: Der kostenpflichtige Puffer
ELTS existiert als Sicherheitsnetz, nicht als Dauerlösung. Wer aus projektbedingten oder organisatorischen Gründen nicht rechtzeitig aktualisieren kann, kauft sich mit ELTS Zeit: Sicherheitskorrekturen laufen weiter, das System bleibt auditierbar, und der Betrieb ist nicht unmittelbar gefährdet. Das ist legitim und in bestimmten Konstellationen wirtschaftlich vernünftig.
Die Kosten sind gestaffelt nach Version und Zeitraum; die Lizenz gilt pro Instanz, nicht pro Modul. Aktuelle Konditionen listet typo3.com/products-services/extended-support-elts. Für größere Installationen, bei denen ein Versions-Wechsel komplex ist — viele Custom-Extensions, gewachsene Integrations-Layer, lange interne Test-Zyklen — kann ELTS wirtschaftlich sinnvoll sein, sodass der Wechsel in Ruhe und ohne Zeitdruck vorbereitet werden kann.
Für die meisten mittelgroßen TYPO3-Installationen gilt das nicht. Wer seinen Bestand konsequent pflegt — aktuelle LTS, regelmäßige Minor-Updates, Extensions mit aktiven Maintainern — für den ist ELTS keine operative Notwendigkeit, sondern eine Option, die man kennen, aber selten brauchen sollte.
Was passiert, wenn man den Rhythmus ignoriert
Hier liegt der eigentliche Kostentreiber: nicht der einzelne Major-Update, sondern der akkumulierte Rückstand. Wer zwei Versionen überspringt, hat kein kleines, sondern ein doppeltes Major-Upgrade vor sich. Änderungen, die schrittweise über zwei Zyklen hätten migriert werden können, müssen nun in einem Durchgang abgearbeitet werden, inklusive aller Zwischenschritte, die man nie aktiv betrieben und damit auch nie produktiv getestet hat.
Das ist technisch lösbar, aber teuer: im Zeitaufwand, in der Testtiefe, in den Risiken. Extensions, die über zwei Major-Versionen eingefroren waren, müssen auf Kompatibilität geprüft werden; manche haben in dieser Zeit keinen aktiven Maintainer mehr. TypoScript und Fluid-Templates, die sich über zwei Generationen verändert haben, müssen in einem Zug analysiert und angepasst werden. Und das alles unter dem Druck eines bereits überfälligen Systems, das keinen Spielraum für sorgfältige Tests lässt.
Der Gegenbeweis liegt im Rhythmus selbst: Wer konsequent nach dem ersten Patch einer neuen LTS wechselt, trägt den Aufwand in kleinen, planbaren Einheiten. Pro Major-Update möglicherweise ein bis zwei Tage Abstimmungs- und Testaufwand — statt einer mehrwöchigen Notfall-Migration mit unklarem Ausgang. Für die meisten gepflegten TYPO3-Installationen ist das erreichbar.
Der Wechsel auf eine neue LTS-Version kostet Aufwand — daran führt kein Weg vorbei. Extensions müssen geprüft, Templates validiert, Staging-Tests durchgeführt werden. Wer erwartet, dieser Aufwand entfalle durch frühzeitiges Handeln, irrt. Er wird kleiner und planbar. Das ist der Unterschied zwischen einer Wartungsposition im Jahresbudget und einem ungeplanten Notfall-Auftrag.
