TYPO3-Upgrade von einer LTS zur nächsten
Der Kern ist in einer Stunde aktualisiert. Die Wochen davor und danach gehören den Erweiterungen, den eigenen Templates und der Konfiguration.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufwand steckt nicht dort, wo die Anleitung anfängt
Wer nach einer Anleitung sucht, findet Release Notes und Agenturangebote. Die Release Notes beschreiben, was sich im Kern geändert hat, die Angebote beschreiben, was es kostet. Was dazwischen fehlt, ist die Reihenfolge: welcher Schritt vor welchem kommt und an welcher Stelle Entscheidungen fallen, die man später nicht mehr billig korrigieren kann.
Die häufigste Fehleinschätzung betrifft die Verteilung des Aufwands. Der Kern selbst wird von Composer gezogen, das dauert Minuten. Danach beginnt die eigentliche Arbeit an drei Stellen: bei Fremderweiterungen, die für die Zielversion bereitstehen müssen, bei eigenem Code, der geänderte Schnittstellen benutzt, und bei Templates und TypoScript, in denen über Jahre Konfiguration gewachsen ist.
Wer in der falschen Reihenfolge anfängt, merkt es spät. Ein Upgrade, das mitten im Composer-Aufruf an einer Erweiterung hängen bleibt, für die es keine passende Fassung gibt, ist an einem Punkt blockiert, an dem alle Beteiligten schon Zeit investiert haben. Die Entscheidung, ob diese Erweiterung ersetzt, angepasst oder gestrichen wird, hätte in Woche eins fallen müssen, nicht am Abend vor dem geplanten Livegang.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Schritt für Schritt
- 1
Alles auflisten, was installiert ist
Zieh eine vollständige Liste der eingesetzten Erweiterungen, aus der Composer-Konfiguration und aus dem Erweiterungsbereich des Backends. Setz hinter jede eine Entscheidung: bleibt, wird ersetzt, entfällt. Für die Kategorie entfällt sprechen zwei Argumente, die selten geprüft werden, nämlich ob die Funktion überhaupt noch genutzt wird und ob sie inzwischen im Kern steckt.
Geschafft, wenn: eine Liste, in der hinter jeder Erweiterung eine Entscheidung steht, und keine offenen Posten
- 2
Zielversion festlegen und Kompatibilität prüfen
Leg die Zielversion fest und prüf für jede verbleibende Erweiterung, ob es eine für diese Version freigegebene Fassung gibt. Für den eigenen Code hilft der Extension Scanner im Upgrade-Bereich der Admin-Werkzeuge: Er durchsucht die Dateien nach Aufrufen, die entfernt oder geändert wurden, und liefert damit die Baustellenliste, bevor irgendetwas installiert ist.
Geschafft, wenn: eine Liste offener Punkte je Erweiterung, und die Gewissheit, dass keine tragende Funktion ohne Nachfolge dasteht
- 3
Eine Kopie zum Üben aufsetzen
Spiel Datenbank und Dateien auf eine getrennte Umgebung, die dem Produktivsystem in PHP-Fassung und Konfiguration möglichst nahekommt. Dort wird geübt, und zwar so oft, bis der Durchlauf ohne Überraschungen klappt. Live geübt wird nie, auch nicht nachts, weil das Zurückrollen einer halb migrierten Datenbank teurer ist als der ganze restliche Ablauf.
Geschafft, wenn: eine Umgebung, auf der sich das Upgrade beliebig oft wiederholen lässt, ohne dass jemand nervös wird
- 4
Den Pfad über die Zwischenversion gehen
Von einer LTS geht es auf die nächste, nicht über zwei hinweg. Wer von v12 nach v14 will, geht erst auf v13 und dann weiter. Der Grund liegt in den Datenbankmigrationen: Die Assistenten einer Version setzen den Datenstand ihrer Vorgängerin voraus, und sie bleiben nicht dauerhaft im Kern, sondern werden entfernt, sobald sie als erledigt gelten. Ein Sprung über zwei Stufen ist deshalb weder vorgesehen noch getestet, und ob die benötigten Assistenten in der Zielversion überhaupt noch enthalten sind, ist eine Frage, die du dann für jede einzelne beantworten musst.
Geschafft, wenn: ein Stand, bei dem jede Zwischenstufe einmal vollständig durchlaufen wurde, inklusive ihrer Assistenten
- 5
Pakete mit Composer heben
Heb die Versionsbeschränkungen für die typo3/cms-Pakete auf die Zielversion an und lass Composer die Abhängigkeiten auflösen. Konflikte an dieser Stelle sind kein Unfall, sondern die Rückmeldung aus Schritt zwei: Es meldet sich genau das Paket, das für die Zielversion noch nicht bereitsteht. Wenn die Bestandsaufnahme sauber war, kommt hier nichts Neues mehr.
Geschafft, wenn: ein Composer-Lauf, der ohne Konflikte durchläuft, mit Kern und Erweiterungen in zueinander passenden Fassungen
- 6
Datenbank abgleichen und Assistenten abarbeiten
Gleich zuerst die Datenbankstruktur ab, dazu gibt es im Wartungsbereich der Admin-Werkzeuge die Analyse der Datenbankstruktur. Danach arbeitest du im Upgrade-Bereich die Assistenten durch, bis keiner mehr offen ist. Sie verschieben Daten in neue Strukturen, und jeder übersprungene Assistent hinterlässt Datensätze, die formal noch da sind, aber nicht mehr gefunden werden. Auf der Kommandozeile gehören dafür zwei Befehle zusammen: typo3 extension:setup für die Datenbankstruktur und anschließend typo3 upgrade:run für die Assistenten.
Geschafft, wenn: keine offenen Assistenten mehr und ein Datenbankabgleich, der beim zweiten Aufruf nichts mehr zu tun findet
- 7
Frontend prüfen und die eigene Konfiguration nacharbeiten
Jetzt beginnt der Teil, den kein Werkzeug übernimmt. Geh die Seitentypen durch, nicht die Seiten: Startseite, eine Inhaltsseite je Layout, Übersichten, Formulare, Suche, Detailansichten aus Erweiterungen und die Sprachfassungen. Auffällig werden meist geänderte Fluid-ViewHelper und TypoScript-Optionen, die es nicht mehr gibt. Nimm dazu das Protokoll für veraltete Aufrufe, denn dort steht, was noch funktioniert, aber beim nächsten Sprung wegfällt.
Geschafft, wenn: alle Seitentypen und Sprachen einmal geprüft, und die Redaktion findet ihre Elemente unverändert vor
Fünf Größen, aus denen sich der Aufwand ergibt
- 01 Die Zahl der Fremderweiterungen und ob sie noch weiterentwickelt werden.
- 02 Die Menge an eigenem Code, vor allem eigene Inhaltselemente und Plugins.
- 03 Das Alter der Templates und die Menge an gewachsenem TypoScript.
- 04 Die Zahl der übersprungenen Hauptversionen, denn jede Stufe kostet zusätzlich.
- 05 Die Frage, ob jemand im Haus die Installation überhaupt noch kennt.
Was du nach diesem Ablauf sicher kannst
Der Weg unten gilt für jeden Sprung von einer LTS auf die nächste. Die Reihenfolge ist dabei wichtiger als jeder einzelne Schritt: Die teuren Entscheidungen fallen alle in den ersten beiden, und wer dort schludert, merkt es erst im fünften, wenn schon alle Beteiligten Zeit investiert haben.
Den Aufwand vorher abschätzen
Du leitest aus der Zahl der Fremderweiterungen, der Menge an eigenem Code und dem Alter der Templates einen Rahmen ab, bevor du das erste Angebot einholst.
Ballast vor dem Sprung abwerfen
Du entscheidest je Erweiterung, ob sie mitkommt, ersetzt wird oder entfällt. Jede gestrichene Erweiterung spart Aufwand in diesem und in jedem folgenden Upgrade.
Den richtigen Pfad wählen
Du gehst von LTS zu LTS und überspringst keine Hauptversion, damit die Datenbankmigrationen in der Reihenfolge greifen, in der sie gedacht sind.
Auf einer Kopie üben
Du führst das Upgrade zuerst auf einer getrennten Umgebung durch und wiederholst es, bis der Ablauf ohne Überraschungen durchläuft.
Die Assistenten vollständig abarbeiten
Du gleichst die Datenbankstruktur ab und arbeitest die offenen Upgrade-Assistenten durch, statt nur zu prüfen, ob die Startseite noch erscheint.
Die Nacharbeit einplanen
Du reservierst Zeit für eigene Templates und gewachsenes TypoScript, denn dort liegt der Teil, den kein Werkzeug für dich erledigt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wie du den Aufwand grob schätzt, bevor du Angebote einholst
Drei Zahlen tragen die Schätzung. Erstens die Zahl der Fremderweiterungen, aufgeteilt danach, ob sie noch weiterentwickelt werden. Eine gepflegte Erweiterung kostet fast nichts, eine verwaiste kostet einen Ersatz oder eine Eigenentwicklung. Zweitens die Menge an eigenem Code, vor allem eigene Inhaltselemente und Plugins. Drittens das Alter der Templates: Wer noch mit einer Fluid-Struktur aus einer Zeit vor zwei Hauptversionen arbeitet, hat mehr Anpassungen vor sich als jemand, der sein Site Package regelmäßig mitgezogen hat.
Eine vierte Größe kommt dazu, sobald mehr als eine Hauptversion übersprungen wird. Zwei Stufen sind nicht doppelt so teuer wie eine, sondern deutlich mehr, weil sich Änderungen überlagern und weil an jeder Zwischenstufe erneut geprüft werden muss. Das ist das stärkste Argument dafür, den Rhythmus einzuhalten, statt zu warten, bis der Druck groß genug ist.
Was sich dagegen kaum auf den Aufwand auswirkt, ist die Zahl der Seiten. Zehntausend Seiten migrieren genauso wie hundert, solange sie mit Standardelementen gebaut sind. Wer den Aufwand nach Seitenzahl schätzt, schätzt das Falsche.
Warum die Bestandsaufnahme wichtiger ist als der Composer-Aufruf
Jede Erweiterung, die du vor dem Upgrade streichst, sparst du in diesem Projekt und in jedem folgenden. Deshalb lohnt sich die unbequeme Frage bei jedem Eintrag: Wird diese Funktion tatsächlich noch benutzt? In gewachsenen Installationen stecken regelmäßig Galerien, Slider, Cookie-Lösungen und Formularerweiterungen aus verschiedenen Jahren nebeneinander, von denen die Hälfte nirgends mehr eingebunden ist.
Die zweite Frage ist, ob die Funktion inzwischen im Kern steckt. TYPO3 bringt Systemerweiterungen für Formulare, für Weiterleitungen, für Suchmaschinenangaben mit XML-Sitemap und für den Redaktionseditor mit. Wer eine Fremdlösung durch eine dieser Systemerweiterungen ersetzt, tauscht eine unsichere Abhängigkeit gegen eine, die mit dem Kern gepflegt wird.
Bei verwaisten Erweiterungen ist die ehrliche Rechnung nötig. Eine Erweiterung, deren letzte Veröffentlichung Jahre zurückliegt, kann man selbst anpassen, das ist zulässig und manchmal richtig. Nur muss dann jemand benannt sein, der sie ab sofort dauerhaft betreut, denn ab diesem Moment gehört sie euch. Ohne diese Zusage ist der Ersatz die günstigere Entscheidung, auch wenn er im Projekt zunächst teurer aussieht.
Was am ersten Tag im Livebetrieb passiert
Nach dem Umschalten kommen die Meldungen aus zwei Richtungen. Aus der Redaktion, wenn ein Element anders aussieht oder ein gewohnter Weg nicht mehr an derselben Stelle liegt, und aus dem Frontend, wenn eine Detailansicht oder ein Formular klemmt. Beides lässt sich vorwegnehmen, indem die Redaktion vor dem Livegang auf der Testkopie arbeitet statt erst danach im Produktivsystem.
Technisch gehören zwei Handgriffe an den Anfang. Erstens alle Caches leeren, einschließlich der Konfigurations- und Klassencaches über die Admin-Werkzeuge, weil sonst alte Zustände in neuen Code hineinregieren. Zweitens das Protokoll beobachten, und zwar mehrere Tage, nicht eine Stunde. Fehler in selten aufgerufenen Bereichen tauchen erst auf, wenn jemand sie besucht.
Plan außerdem einen Puffer für Kleinigkeiten ein, die niemand auf die Liste geschrieben hat: eine Weiterleitung, die nicht mehr greift, ein Bildformat, das anders zugeschnitten wird, ein Filter, dessen Sortierung sich geändert hat. Das sind keine Fehler im Sinne von Ausfällen, aber sie kosten in Summe mehr Zeit als der Sprung selbst.
Die Breaking Changes im Original nachlesen
Was sich zwischen zwei Hauptversionen ändert, steht vollständig und aktuell in den offiziellen Changelogs. Dort ist jede Änderung einzeln dokumentiert, unterteilt in Neuerungen, veraltete und entfernte Funktionen, jeweils mit dem Hinweis, was an ihre Stelle tritt. Diese Sammlung nachzuerzählen, wäre sinnlos, weil sie sich mit jeder Version ändert, und deshalb steht der Verweis darauf unter den Quellen.
Für die Praxis reicht ein einfacher Zugriff darauf: Der Extension Scanner meldet Fundstellen im eigenen Code, und zu jeder Meldung gehört ein Eintrag im Changelog. Diese beiden zusammen ergeben eine Arbeitsliste, die deutlich kürzer ist als die vollständige Änderungsdokumentation, weil sie nur enthält, was euch tatsächlich betrifft.
Eine Einschränkung gehört dazu: Der Scanner findet Aufrufe im Code, aber keine Konfiguration. Entfernte TypoScript-Optionen und geänderte Fluid-ViewHelper zeigen sich erst beim Prüfen des Frontends. Genau deshalb ist Schritt sieben kein Formalakt am Ende, sondern ein eigener Arbeitsblock mit eigener Zeit.
Dazu passende Kurse
Der Ablauf oben lässt sich deutlich leichter steuern, wenn im Haus jemand die Zusammenhänge kennt, dafür gibt es TYPO3 für Entwickler und Redaktion .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr kompetente und freundliche Trainerin. Die Inhalte wurden gut strukturiert und anhand von anschaulichen Beispielen vermittelt.
Häufige Fragen
Kann man zwei Hauptversionen auf einmal überspringen?
Wie lange dauert ein Upgrade?
Müssen die Redakteure nach dem Upgrade neu geschult werden?
Brauchen wir für das Upgrade eine Agentur?
Passt thematisch dazu
Der Versionssprung auf dem Server darunter folgt derselben Reihenfolge, und dort übernimmt der Preupgrade-Bericht als eigentliches Arbeitsdokument genau die Rolle, die bei TYPO3 die Bestandsaufnahme der Erweiterungen hat.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem TYPO3-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Ein Upgrade ist so teuer wie das fehlende Wissen darüber
Wer Site Package, TypoScript und Erweiterungen selbst einordnen kann, führt ein Upgrade planbar durch statt es zu erleiden, und genau darauf zielen die TYPO3-Kurse bei cmt.