TYPO3 14 LTS: Upgrade planen

Wer eine TYPO3-Installation auf Hauptversion 12 betreibt, hat seit dem Frühjahr 2026 eine Entscheidung offen, die sich nicht weiter vertagen lässt: Die kostenfreie Pflege dieses Zweigs lief am 30. April 2026 aus (get.typo3.org), und seit dem 1. Mai 2026 liefert die Community dafür weder Wartung noch Sicherheitsaktualisierungen (news.typo3.com). Auf der anderen Seite steht mit TYPO3 14 LTS seit dem 21. April 2026 eine Fassung bereit, die von v12 aus zwei Hauptversionssprünge entfernt liegt (get.typo3.org). Dieser Beitrag ordnet die Wartungsfenster, prüft den Aufwand an den nachrechenbaren Stellen - Änderungsprotokolle, Erweiterungen, PHP-Korridor - und zeigt, wie daraus ein Zeitfenster wird, das zum Betrieb passt statt zum Kalender der Entwicklung. Wer die Planung begleiten lassen möchte, findet den Rahmen in unserer TYPO3-Betreuung.

Was am 30. April 2026 endete

Die kostenfreie Pflege von TYPO3 12 LTS durch die Community lief vom 25. April 2023 bis zum 30. April 2026 (get.typo3.org). Diese gut drei Jahre folgen einem festen Muster: Eine LTS-Fassung wird 1,5 Jahre regulär gewartet und danach weitere 1,5 Jahre vorrangig fehlerbereinigt, Sicherheitsaktualisierungen eingeschlossen (news.typo3.com). Seit dem 1. Mai 2026 liefert die Community für v12 weder Wartung noch Sicherheitsaktualisierungen (news.typo3.com). Für den laufenden Betrieb heißt das zunächst nichts: Die Instanz arbeitet weiter wie am Vortag, Redakteure merken nichts, Bestellstrecken laufen durch. Was fehlt, ist der Nachschub. Eine nach diesem Datum bekannt gewordene Schwachstelle im Kern wird auf diesem Zweig ohne kostenpflichtige Verlängerung nicht mehr geschlossen. Zwischen "läuft" und "wird versorgt" liegt die Lücke, die eine Planung schließen muss.

Wie viele Betreiber in dieser Lage sind, lässt sich nur näherungsweise beziffern. Der Messdienst W3Techs weist für den 1. September 2026 aus, dass 24,2 Prozent der Websites mit erkanntem TYPO3 zuletzt auf Hauptversion 12 erfasst waren, 25,4 Prozent auf Zweig 13 und 1,5 Prozent auf Zweig 14 (W3Techs). Alle drei Anteile beziehen sich auf Websites, deren Content-Management-System der Dienst überhaupt erkennt, nicht auf alle Websites im Netz. Dazu kommen zwei Einschränkungen: Die Versionszuordnung bezieht der Dienst nach eigener Angabe von einem Dritten, und eine erfasste Website wird nur etwa einmal im Monat erneut besucht. Ein Versionswechsel erscheint in dieser Messung also verzögert, und aus den 1,5 Prozent auf Zweig 14 lässt sich kein Umstiegstempo ableiten. Belastbar ist die Größenordnung: Ein knappes Viertel des erfassten Bestands stand zuletzt auf einem Zweig ohne kostenfreie Sicherheitsversorgung.

Innerhalb dieses Viertels ist die Lage einheitlicher, als man erwarten würde: 99,8 Prozent der Websites mit erkanntem TYPO3 12 laufen auf der LTS-Fassung 12.4 (W3Techs, Stand 1. September 2026). Wer auf v12 steht, steht also mit hoher Wahrscheinlichkeit auf demselben Stand wie alle anderen - mit denselben Erweiterungen im Markt und denselben offenen Fragen. Für die Planung ist das eine gute Nachricht, weil sich Erfahrungen übertragen lassen. Es bedeutet aber auch, dass eine im Kern von 12.4 gefundene Schwachstelle einen sehr großen Teil des Bestands auf einmal betrifft. Wer TYPO3 zuerst gegen andere Systeme abwägen möchte, findet die Einordnung im CMS-Vergleich für Unternehmen; hier geht es um den Weg innerhalb von TYPO3.

Die Wartungsfenster nebeneinander

TYPO3 plant alle 18 Monate eine neue LTS-Fassung (docs.typo3.org). Dieser Rhythmus ist die eigentliche Planungsgröße: Er bestimmt, wie oft ein Betrieb ein Upgradefenster einplanen muss, und er passt auf die Laufzeit eines Wartungsvertrags. Die folgende Übersicht stellt die drei Zweige nebeneinander, die für eine Entscheidung heute zählen. Sie führt nur Termine, die der Herausgeber beziehungsweise die Association selbst ausweist; ein Datum aus zweiter Hand steht nicht darin.

Aus der Tabelle folgt die eigentliche Planungsfrage. TYPO3 v13 LTS erhält kostenfreie Sicherheitsaktualisierungen bis Ende Dezember 2027 (news.typo3.com); denselben Termin nennt der maschinenlesbare Datensatz der Association (get.typo3.org). TYPO3 v14 LTS erhält nach Angabe des Herausgebers Fehlerkorrekturen bis zum 31. Dezember 2027 und Sicherheitskorrekturen bis zum 30. Juni 2029 (news.typo3.com). Wer heute von v12 aus plant, hat damit zwei Zielmarken: Ein Zwischenschritt auf v13 verschafft Luft bis Ende 2027, ein Sprung direkt auf v14 trägt bis Mitte 2029. Die zweite Marke liegt gut eineinhalb Jahre weiter - und dieser Abstand entspricht ziemlich genau einem vollen LTS-Rhythmus.

• Der Zwischenschritt hat ein Ablaufdatum. Wer über v13 geht, muss den nächsten Sprung vor dem 31. Dezember 2027 eingeplant haben (get.typo3.org) - das ist keine Ruhepause, sondern eine Verschiebung.
• Der Direktsprung kauft die längere Frist. Sicherheitskorrekturen für v14 laufen bis zum 30. Juni 2029 (news.typo3.com), also über zwei Planungsjahre hinweg.
• Der 18-Monats-Takt bleibt. Nach v14 folgt planmäßig die nächste LTS-Fassung (docs.typo3.org); ein Betrieb, der einmal aufgeschlossen hat, braucht das Fenster trotzdem wieder.
• Die kostenpflichtige Verlängerung verschiebt nur den Druck. Sie hält den Kern von 12.4 versorgt, ändert aber nichts an Erweiterungen, PHP-Zweig und Redaktionsoberfläche.

Ein Sprung oder v13 als Zwischenschritt

Die Frage, ob man von v12 direkt auf v14 geht oder v13 zwischenschaltet, wird häufig als Geschmacksfrage behandelt. Sie ist keine. Der Unterschied liegt darin, wo die Arbeit anfällt - in einem großen Block oder in zwei kleineren mit einem produktiven Zwischenstand dazwischen -, und darin, welche Warnungen man unterwegs überhaupt zu sehen bekommt. Beides lässt sich an nachprüfbaren Zahlen festmachen: an den Einträgen der Änderungsprotokolle und an den Versionsangaben der Erweiterungen. Beide Größen sind öffentlich, beide haben klare Grenzen, und beide werden regelmäßig überinterpretiert.

Was die Breaking-Einträge sagen und was nicht

Das offizielle Änderungsprotokoll führt für TYPO3 v14 93 Einträge vom Typ Breaking, für v13 sind es 101, für v12 sind es 126 (docs.typo3.org). Diese drei Zahlen nebeneinanderzulegen zulässig, sie als fallenden Trend zu lesen nicht: v12 und v13 umfassen je fünf Veröffentlichungen, v14 bislang vier, und die Entwicklungsphase von v14 war kürzer. Die Zahlen beschreiben also unterschiedlich große Zeiträume. Tragfähig ist die Summe des Weges: Wer von v12 auf v14 geht, hat die Breaking-Einträge zweier Hauptversionen vor sich. Wer den Zwischenschritt einlegt, hat dieselben Einträge, nur verteilt auf zwei Termine. Die Arbeit verschwindet nicht, sie wird anders portioniert.

This strategy gives developers sufficient time to adjust their TYPO3 extensions, assuming many agencies upgrade from one LTS release to the next (usually 1.5 years).

TYPO3 Documentation Team, Pre-upgrade tasks for major TYPO3 Core updates

Dieser Satz beschreibt den wichtigsten Nebeneffekt der Entscheidung. Zu entfernende Klassen, Methoden, Konstanten, Funktionen oder Parameter werden zuerst als veraltet markiert und erst in der nächsten Hauptversion entfernt (docs.typo3.org). Die Vorlaufregel unterstellt dabei, dass von einer LTS-Fassung zur nächsten aktualisiert wird, in der Regel im Abstand von 1,5 Jahren (docs.typo3.org). Wer v13 überspringt, bekommt die Warnungen dieser Zwischenstufe im eigenen Betrieb nicht zu sehen: Was in v13 als veraltet markiert und in v14 entfernt wurde, taucht auf der v12-Instanz an keiner Stelle auf. Man findet es entweder beim statischen Prüflauf vor dem Upgrade oder im Fehlerprotokoll danach. Das spricht nicht gegen den Direktsprung, verschiebt aber Aufwand vom Betrieb in die Vorbereitung.

Was die Erweiterungszahlen hergeben

Die zweite nachprüfbare Größe sind die Erweiterungen. Im TYPO3 Extension Repository lässt sich die Suche nach der unterstützten Hauptversion filtern; die Zähler daneben geben an, wie viele Erweiterungen eine Angabe für die jeweilige Fassung tragen. Wichtig ist, was diese Zähler nicht sind: Sie beruhen auf Versionsangaben, die Erweiterungsautoren selbst hinterlegen, nicht auf einer gemessenen Lauffähigkeit. Und sie stehen nicht still - auf der Seite tragen sie kein Datum und bewegen sich im Tagesverlauf. Für eine Planung taugen sie darum als gerundete Größenordnung mit Abrufdatum, nicht als Stichtagswert. Aussagekräftig ist ohnehin weniger der Gesamtzähler als die Schnittmenge: wie viele der Erweiterungen, die eine Angabe für die eigene Ausgangsfassung tragen, zugleich eine für 14 LTS führen.

Die Abdeckung ist aus v13 heraus dichter als aus v12: Schaltet man im Erweiterungsverzeichnis zum Filter der Ausgangsfassung den Filter für 14 LTS hinzu, steht der Zähler für 13 LTS klar über dem für 12 LTS. Eine feste Zahl steht hier bewusst nicht - die Zähler tragen kein Datum und bewegen sich im Tagesverlauf; wer sie für eine Planung braucht, ruft sie am Tag der Planung selbst ab. Der Abstand ist erwartbar, weil viele Autoren ihre Pakete von der jeweils aktuellen Fassung aus weiterpflegen. Für die Planung heißt es: Der Zwischenschritt über v13 ist auch beim Erweiterungsumfeld der besser versorgte Weg. Dagegen steht, dass der zweite Sprung ohnehin bis Ende 2027 nachzuholen ist.

Der Zähler sagt allerdings nichts über die eigene Installation. Entscheidend ist nicht, wie viele Erweiterungen im Verzeichnis eine Angabe tragen, sondern welche zwölf oder zwanzig Erweiterungen in der eigenen Instanz aktiv sind und ob genau diese eine Angabe tragen. Dazu kommt der zweite Veröffentlichungsweg: Im Composer-Verzeichnis sind über 4.400 Pakete vom Typ typo3-cms-extension gelistet (Packagist, Abruf 14.09.2026). Installationen, die über Composer verwaltet werden, beziehen ihre Erweiterungen von dort, teils zusätzlich zum Verzeichnis, teils ausschließlich. Eine Bestandsaufnahme, die nur eine der beiden Quellen ansieht, übersieht regelmäßig einen erheblichen Teil des Bestands.

Zuerst die Plattform: der PHP-Korridor

Der Herausgeber empfiehlt für den Umstieg, zuerst die Plattform zu aktualisieren und danach die TYPO3-Instanz (news.typo3.com). Das ist mehr als eine Reihenfolgeempfehlung, es ist der Grund, warum sich ein Upgrade überhaupt auf zwei Termine verteilen lässt. TYPO3 12 setzt PHP 8.1.0 bis 8.4.99 voraus, TYPO3 14 setzt PHP 8.2.0 bis 8.5.99 voraus (get.typo3.org). Gemeinsam lauffähig sind beide Fassungen damit nur im geschlossenen Bereich von PHP 8.2.0 bis 8.4.99. Dieser Korridor ist die eigentliche Arbeitsfläche: Wer die Plattform vorzieht, hebt PHP innerhalb dieses Bereichs an, prüft die laufende v12-Instanz darauf und macht den TYPO3-Sprung danach in einem zweiten Termin.

Der obere Rand gehört in jede Planung: PHP 8.5 ist von TYPO3 12 nicht gedeckt (get.typo3.org). Wer die Plattform zu weit hebt, steht mit einer v12-Instanz auf einem nicht unterstützten PHP-Zweig und hat sich den gestaffelten Weg selbst verbaut. Am unteren Rand steht die Gegenfrage: TYPO3 v14 LTS verlangt mindestens PHP 8.2 und unterstützt daneben PHP 8.3, 8.4 und 8.5 (news.typo3.com). Der PHP-Zweig 8.2 erhält allerdings nach Angabe der PHP Group nur noch bis zum 31. Dezember 2026 Sicherheitsaktualisierungen (php.net). Sinnvoll ist deshalb die Mitte des Korridors, 8.3 oder 8.4 - dort sind v12 und v14 beide abgedeckt, und der Zweig trägt über den Upgradetermin hinaus.

Die Reihenfolge hat einen praktischen Vorteil. Ein Plattformwechsel lässt sich auf einem Klon erproben und in einem kurzen Wartungsfenster ausrollen, weil an Inhalten und Redaktionsoberfläche nichts verändert wird. Der TYPO3-Sprung dagegen berührt Backend, Erweiterungen und in der Regel auch Templates. Beides in einen Termin zu legen bedeutet, dass ein Fehler in der Nacht nicht mehr eindeutig zuzuordnen ist. Für die Infrastrukturfragen, die dabei aufschlagen - Laufzeiten, Arbeitsspeicher, Zwischenspeicher -, ist unsere Cloud- und Hostingbetreuung der passende Ort.

Erweiterungen zählen, bevor der Termin steht

Bevor ein Datum im Kalender steht, gehört eine Bestandsaufnahme auf den Tisch. Sie ist in einem halben Tag zu machen und entscheidet über die Größenordnung des gesamten Vorhabens. Die öffentlichen Zähler helfen dabei nur zur Einordnung; was zählt, ist die Liste der aktiven Erweiterungen der eigenen Instanz, abgeglichen gegen die Angaben für 14 LTS. Der folgende Ablauf hat sich dafür bewährt und lässt sich unabhängig davon durchlaufen, ob am Ende der Direktsprung oder der Zwischenschritt steht.

1. Aktive Erweiterungen auflisten, getrennt nach Veröffentlichungsweg - Verzeichnis, Composer, Eigenentwicklung. Inaktive Pakete gehören auf eine eigene Liste; sie werden nicht migriert, sondern entfernt.
2. Für jede öffentliche Erweiterung prüfen, ob eine Angabe für 14 LTS vorliegt. Der Filter im TYPO3 Extension Repository zeigt, wie viele Pakete mit Angabe für die eigene Ausgangsfassung zugleich eine für 14 LTS tragen - ob die eigenen dazugehören, entscheidet die Einzelprüfung.
3. Eigenentwicklungen gegen die Breaking-Einträge der Protokolle von v13 und v14 abgleichen (docs.typo3.org). Den größten Teil findet der statische Prüflauf, den Rest findet die Testinstanz.
4. Alle Upgrade-Assistenten der laufenden Hauptversion durchlaufen lassen - das ist Voraussetzung für den Sprung, nicht Nacharbeit (docs.typo3.org).
5. Aufwand je Erweiterung grob in drei Töpfe sortieren: ersetzbar, anpassbar, neu zu bauen. Erst diese Sortierung macht aus einer Liste eine Schätzung.

Der vierte Punkt wird am häufigsten übersehen. Vor dem Sprung auf die nächste Hauptversion müssen alle Upgrade-Assistenten der laufenden Hauptversion durchgelaufen sein (docs.typo3.org). In einer Instanz, die seit Jahren im Betrieb ist und ihre Sprünge zügig hinter sich gebracht hat, stehen dort regelmäßig noch offene Punkte. Sie kosten einzeln wenig Zeit, blockieren aber den nächsten Schritt - und sie fallen typischerweise genau dann auf, wenn das Wartungsfenster schon läuft.

#!/usr/bin/env bash
# Bestandsaufnahme vor dem TYPO3-Upgrade - Ergebnisse nach bericht/
set -euo pipefail
mkdir -p bericht

# Offene Upgrade-Assistenten der laufenden Hauptversion
./vendor/bin/typo3 upgrade:list --all > bericht/assistenten.txt

# Installierte Pakete mit Fassung, Grundlage für den Abgleich
composer show --format=json \
  | jq -r '.installed[] | .name + " " + .version' \
  > bericht/pakete.txt

# Eigenentwicklungen: alles, was im Projekt selbst liegt
find packages -maxdepth 2 -name composer.json -printf '%h\n' \
  > bericht/eigenentwicklungen.txt

# Gemeinsamer PHP-Bereich von v12 und v14: 8.2.0 bis 8.4.99
php -v | head -n 1 > bericht/plattform.txt

echo "Bestandsaufnahme liegt unter bericht/ - die Bewertung bleibt Handarbeit."

Aus der Bestandsaufnahme wird eine Zahl, sobald jede Position einem der drei Töpfe zugeordnet ist. Ersetzbar heißt, dass der Kern oder eine gepflegte Erweiterung die Funktion inzwischen mitbringt. Anpassbar heißt, dass eine Fassung existiert und nur Konfiguration und Templates nachzuziehen sind. Neu zu bauen heißt, dass es keine Fassung gibt und die Funktion trotzdem gebraucht wird. Erfahrungsgemäß entscheidet die Größe des dritten Topfs darüber, ob ein Upgrade ein Wartungsvorgang bleibt oder zu einem Vorhaben mit eigenem Zeitplan wird. Fällt die Entscheidung in Richtung Neubau größerer Teile, lohnt der Blick auf die Systemfrage insgesamt - der Beitrag zur CMS-Migration vom Legacy-System beschreibt diesen Übergang.

ELTS verlängert, ersetzt aber keinen Plan

Für Betriebe, die den Termin nicht rechtzeitig legen können, gibt es eine kostenpflichtige Verlängerung. Das ELTS-Programm für TYPO3 12.4 läuft bis zum 30. April 2029, für offizielle Partner bis zum 30. April 2030 (typo3.com). Ein ELTS-Zeitraum umfasst jeweils ein Jahr und lässt sich in einem Zug für zwei oder drei Jahre buchen (typo3.com). Der Anbieter nennt dafür 3.200 Euro je Lizenz und Jahr vor Rabatten, und zwar über die gesamte Laufzeit von bis zu vier Jahren (news.typo3.com). Das ist ein Listenpreis vor Mitgliederrabatten mit Preisstand 14. September 2026, keine Zusage - wer damit rechnet, holt ein aktuelles Angebot ein.

Rechnet man das durch, ergibt sich ein einfaches Bild: Die Verlängerung wird jährlich fällig, und am Ende der gebuchten Jahre steht dieselbe Aufgabe - nur mit mehr Abstand zum aktuellen Stand und in einem Umfeld, das sich weitergedreht hat. Das vierte Jahr des Programms, der Zeitraum vom 1. Mai 2029 bis zum 30. April 2030, steht zudem nur offiziellen TYPO3-Partnern offen (typo3.com). ELTS ist damit ein taugliches Mittel, um ein Fenster zu überbrücken, das aus betrieblichen Gründen erst später aufgeht - eine Alternative zum Upgrade ist es nicht.

Das Zeitfenster legen

Ein Upgradetermin steht nicht im Kalender der Entwicklung, sondern im Kalender des Betriebs. Das klingt selbstverständlich und wird trotzdem regelmäßig andersherum gehandhabt. Nützlich ist die Rückwärtsrechnung von der äußeren Marke: Wer über v13 geht, muss den zweiten Sprung vor dem 31. Dezember 2027 stehen haben (get.typo3.org). Wer direkt auf v14 geht, hat bis zum 30. Juni 2029 Ruhe vor der nächsten Pflichtübung (news.typo3.com), sollte aber den 18-Monats-Takt der Veröffentlichungen im Blick behalten (docs.typo3.org). Zwischen diesen Marken liegen Saison, Budgetjahr, Personalplanung und der Umstand, dass eine Testinstanz Zeit braucht, in der jemand sie tatsächlich benutzt.

• Äußere Marke festlegen: 31.12.2027 beim Zwischenschritt über v13, 30.06.2029 beim Direktsprung auf v14
• Plattformtermin vorziehen und PHP innerhalb von 8.2.0 bis 8.4.99 heben, solange v12 läuft
• Alle Upgrade-Assistenten der laufenden Hauptversion abarbeiten, bevor das Fenster geöffnet wird
• Testinstanz mit echtem Inhaltsstand aufsetzen und eine Redaktionsabnahme einplanen, nicht nur eine technische
• Erweiterungsliste in ersetzbar, anpassbar und neu zu bauen sortieren und den dritten Topf zuerst angehen
• Rückfallweg schriftlich festhalten: Stand, Datenbankabzug, Zeitpunkt der Entscheidung

Die Redaktionsabnahme ist der Punkt, an dem Zeitpläne am häufigsten reißen. Ein Hauptversionssprung verändert das Backend, und zwei Sprünge auf einmal verändern es deutlich. Wer die Testinstanz nur technisch abnimmt, verlagert die Rückmeldungen der Redaktion hinter den Produktivtermin - dorthin, wo sie am teuersten sind. Zwei Wochen, in denen die Redaktion im Testsystem tatsächlich arbeitet, sind erfahrungsgemäß besser investiert als jede zusätzliche Runde automatisierter Prüfungen. Wie sich ein solcher Ablauf insgesamt planen lässt, steht im Beitrag zur Relaunch-Planung.

Was beim Upgrade gleich mit aufgeräumt wird

Ein Hauptversionssprung ist oft der einzige Termin im Jahr, an dem ohnehin alles angefasst wird. Das macht ihn zum günstigsten Zeitpunkt für Arbeiten, die sonst kein eigenes Budget bekommen. Dazu gehört die Adressstruktur: Ändern sich beim Sprung Seitenpfade oder Dateinamen, gehört ein Weiterleitungskonzept in denselben Termin. Dazu gehören ebenso die Anforderungen an die Barrierefreiheit, deren Umsetzung in Templates und Formularen liegt - den Rahmen dafür setzt unsere Betreuung zur Barrierefreiheit.

Zwei Themen dieser Woche schließen hier unmittelbar an. Wer beim Upgrade ohnehin die Plattform anfasst, prüft sinnvollerweise gleich den Hostingvertrag: Welche Wechselrechte ab 2027 gelten, steht im Beitrag zum Anbieterwechsel in der Cloud ab 2027. Und wer die Templates ohnehin überarbeitet, legt die Erklärung zur Barrierefreiheit und den Rückmeldeweg gleich mit an - wie beides aussehen muss, steht im Beitrag zur Erklärung zur Barrierefreiheit und zum Rückmeldeweg. Beides sind Arbeiten, die ein geöffnetes Wartungsfenster nahezu mitnimmt.

Woher die Zahlen stammen und was sie nicht sagen

Die Termine in diesem Beitrag stammen aus zwei Quellen: den Meldungen der TYPO3 GmbH und dem maschinenlesbaren Datensatz der TYPO3 Association auf get.typo3.org. Die Zahl zu den Erweiterungen im Composer-Verzeichnis stammt aus der Paketliste von Packagist, abgerufen am 14. September 2026 und hier gerundet geführt, weil sie sich im Tagesverlauf bewegt; die Facettenzähler des TYPO3 Extension Repository stehen hier bewusst ohne festen Wert, weil sie kein Datum tragen und sich im Tagesverlauf bewegen. Die Anteilszahlen stammen von W3Techs und beziehen sich auf Websites mit erkanntem Content-Management-System; der Erhebungsbestand umfasst nach Anbieterangabe deutlich mehr als 20 Millionen Websites (W3Techs).

Was die Zahlen nicht sagen, ist ebenso wichtig. Unter Websites mit der Endung .de kommt TYPO3 auf 6,7 Prozent der Seiten mit erkanntem Content-Management-System, weltweit sind es 0,5 Prozent (W3Techs, Abruf 27. September 2026). Daraus folgt, dass die Verbreitung im deutschen Segment um ein Vielfaches höher liegt - nicht, wie sich die Installationen auf Länder verteilen. Das sind Quoten je Segment, kein Bestand. Ebenso wenig lässt sich aus den Versionsanteilen ein Tempo ablesen: Sie sagen, was zuletzt erfasst wurde, nicht, wie schnell umgestellt wird.

Der nächste Schritt

Die Entscheidung zwischen Direktsprung und Zwischenschritt fällt nicht am Schreibtisch, sondern an der Erweiterungsliste. Steht dort überwiegend Standard mit Angabe für 14 LTS, ist der Direktsprung der kürzere Weg und trägt bis Mitte 2029 (news.typo3.com). Steht dort viel Eigenentwicklung, ist der Zwischenschritt über v13 die ruhigere Strecke - mit der Auflage, den zweiten Sprung vor Ende 2027 zu setzen (get.typo3.org). In beiden Fällen ist der erste Schritt derselbe: die Bestandsaufnahme. Wir übernehmen sie als abgeschlossene Leistung, mit belastbarer Liste, Aufwandsschätzung je Position und einem Terminvorschlag - der Einstieg steht auf der Seite zur TYPO3-Betreuung, die Einordnung zwischen den Systemen auf der Seite zu Content-Management-Systemen.