Wie viele TYPO3-Versionen kann ich bei einem Update überspringen?

Ja, TYPO3-Versionen lassen sich teilweise überspringen. Je komplexer das Projekt ist, desto weniger sinnvoll ist es aber, mehrere Major-Versionen in einem großen Sprung zusammenzufassen.

Bei kleinen und technisch überschaubaren Projekten kann ein direkter Sprung gut funktionieren. TYPO3 11 direkt auf 13 würde ich bei einem passenden Projekt durchaus machen.

Von TYPO3 11 direkt auf 14 würde ich dagegen nicht springen. Dafür gab es gerade zwischen 11 und 12 sowie zwischen 13 und 14 zu viele relevante Änderungen.

Als grobe Faustregel gilt für mich: Ab ungefähr drei Major-Versionen Abstand würde ich nicht mehr einfach alles überspringen. Wie immer hängt das aber vom konkreten Projekt ab. Manche Versionswechsel sind deutlich unspektakulärer als andere.

Warum wird TYPO3 häufig Schritt für Schritt aktualisiert?

Das schrittweise Vorgehen ist bei größeren Updates schlicht Best Practice.

Ich kann für unterschiedliche Versionsstände eigene Git-Branches anlegen und habe damit klar getrennte Zwischenstände des Projekts. Wenn bei einem Schritt etwas nicht funktioniert, lässt sich sauber nachvollziehen, wo das Problem entstanden ist. Im Zweifel kann ich jederzeit auf den vorherigen Stand zurückspringen.

Die Zwischenversionen sind dabei nicht unbedingt Versionen, auf denen die Website später produktiv laufen soll. Sie dienen als kontrollierte Migrationsschritte auf dem Weg zur eigentlichen Zielversion.

Welche Rolle spielen die TYPO3 Upgrade Wizards?

TYPO3 bringt für neue Versionen sogenannte Upgrade Wizards mit. Diese übernehmen viele Änderungen, die beim Wechsel auf eine neue Version notwendig werden.

Dazu können zum Beispiel Änderungen an Datenbankfeldern gehören. Ein Feld bekommt einen anderen Typ, wird umbenannt, fällt weg oder ein neues Feld kommt hinzu.

Das Problem bei größeren Sprüngen: Die Upgrade Wizards einer TYPO3-Version gehen normalerweise davon aus, dass die Installation aus der direkt vorherigen Version kommt.

Ein Wizard für TYPO3 13 erwartet also grundsätzlich einen Datenstand, der aus TYPO3 12 stammt und nicht aus einer viel älteren Installation.

Genau deshalb ist der klassische Weg über die einzelnen Major-Versionen bei komplexen Projekten weiterhin sehr sinnvoll.

Es gibt auch Werkzeuge für größere Sprünge

Mittlerweile gibt es Extensions, die Upgrade Wizards aus mehreren TYPO3-Versionen bündeln. Damit können auch größere Versionssprünge in einem Durchgang funktionieren.

Bei kleineren Projekten habe ich damit gute Erfahrungen gemacht.

Ich prüfe vorher aber immer, ob die betreffende Extension für den aktuellen Zielstand gepflegt ist und die benötigten Migrationen tatsächlich enthält.

Bei drei oder mehr übersprungenen Major-Versionen würde ich mich darauf bei einem komplexeren Projekt nicht verlassen. Dafür ist mir das Risiko zu hoch, dass eine notwendige Migration übersehen wird oder ein Sonderfall des Projekts nicht sauber abgedeckt ist.

Manchmal reichen die TYPO3-eigenen Migrationen nicht

Upgrade Wizards kümmern sich nur um Dinge, die TYPO3 oder die jeweilige Extension kennen.

Bei individuellen Projekten gibt es aber oft eigene Datenstrukturen oder Extensions. Wenn sich dort mit einer neuen Version die Art ändert, wie Daten gespeichert werden, muss ebenfalls eine Migration stattfinden.

Wenn eine Extension dafür keinen eigenen Upgrade Wizard mitliefert, schreibe ich den notwendigen Migrationsschritt selbst.

Das ist gerade bei älteren oder stark angepassten Projekten nichts Ungewöhnliches.

Ein Update besteht deshalb nicht nur daraus, neuen Code zu installieren. Die vorhandenen Daten müssen ebenfalls in einen Zustand gebracht werden, den die neue Version erwartet.

Muss auch die Datenbank jede Version mitmachen?

Bei einem größeren Update verändert sich nicht nur PHP-Code. Auch das Datenbankschema entwickelt sich weiter.

Zwischen TYPO3-Versionen können unter anderem:

• neue Datenbankfelder hinzukommen
• bestehende Felder umbenannt werden
• Datentypen geändert werden
• alte Felder entfernt werden
• Inhalte in eine neue Struktur migriert werden

Deshalb müssen die vorgesehenen Datenbank- und Upgrade-Schritte sauber durchgeführt werden.

Gerade bei einem großen Legacy-Projekt ist das ein weiterer Grund, warum ich lieber kontrolliert von Version zu Version gehe, anstatt mehrere Jahre Entwicklung in einem einzigen Sprung zu überspringen.

Was passiert mit Extensions bei mehreren Versionssprüngen?

Auch Extensions entwickeln sich parallel zu TYPO3 weiter.

Welche Extension-Version bei welchem Schritt benötigt wird, lässt sich nicht pauschal sagen. Manche Extensions lassen sich relativ problemlos direkt auf eine neuere Version bringen. Bei anderen gab es zwischenzeitlich Änderungen an Konfiguration, Datenstruktur oder APIs.

Deshalb schaue ich mir bei größeren Updates die Changelogs der jeweiligen Extension an.

Das spart oft erheblich Zeit. Dort steht zum Beispiel, ob ein eigener Upgrade-Schritt notwendig ist, Einstellungen geändert wurden oder sich Datenstrukturen verändert haben.

Bei wichtigen Extensions würde ich nicht einfach ausprobieren, welche Version irgendwie startet. Ich möchte vorher wissen, welcher Migrationsweg vom Hersteller vorgesehen ist.

Custom Extensions passe ich direkt an die Zielversion an

Bei eigenen Extensions gehe ich anders vor.

Den eigenen Code würde ich normalerweise direkt auf die gewünschte Zielversion anpassen und nicht für jede Zwischenversion eine eigene vollständig kompatible Variante bauen.

Die Zwischenstände des TYPO3-Cores und der Datenmigrationen bleiben trotzdem kontrolliert. Der Custom Code kann aber direkt auf den Stand gebracht werden, auf dem er am Ende tatsächlich laufen soll.

Das vermeidet unnötige Arbeit an Zwischenlösungen, die nach dem nächsten Schritt sowieso wieder geändert werden müssten.

Spare ich Geld, wenn ich Versionen überspringe?

Nicht unbedingt.

Auf den ersten Blick klingt es natürlich günstiger, statt drei einzelnen Updates nur einen großen Sprung zu machen.

In der Praxis verschwindet die Arbeit dadurch aber nicht. Die Änderungen aus den übersprungenen Versionen müssen trotzdem berücksichtigt werden.

Man macht die Arbeit dann eher in einem großen Paket statt in mehreren kleineren Paketen.

Bei einem kleinen Projekt kann ein direkter Sprung durchaus etwas Aufwand sparen, weil weniger Zwischenstände aufgebaut und geprüft werden müssen.

Bei einem komplexen Projekt ist mir die Sicherheit und Nachvollziehbarkeit wichtiger als ein theoretisch etwas kürzerer Updateweg.

Muss der Kunde den Updateweg selbst festlegen?

Nein.

Für den Kunden ist vor allem wichtig, welche TYPO3-Version aktuell eingesetzt wird und welche Zielversion sinnvoll ist.

Ob ich technisch direkt auf diese Version gehe oder das Projekt zunächst über TYPO3 12, 13 und anschließend 14 migriere, ist Teil meiner Updateplanung.

Der Kunde muss nicht entscheiden, welche Zwischenversionen technisch notwendig sind.

Das kläre ich nach der Analyse des Projekts anhand von Core, Extensions, Datenbank, eigener Logik und den Änderungen zwischen den jeweiligen TYPO3-Versionen.

Wie viele TYPO3-Versionen kann man also überspringen?

Bei kleinen, sauberen Projekten kann man durchaus eine Major-Version überspringen. Ein direkter Sprung von TYPO3 11 auf 13 kann zum Beispiel sinnvoll sein, wenn das Projekt technisch dafür geeignet ist.

Bei größeren Abständen und komplexen Projekten würde ich vorsichtiger werden. Ab ungefähr drei Major-Versionen gehe ich lieber Schritt für Schritt vor.

Der Grund ist nicht, dass ein großer Sprung grundsätzlich unmöglich wäre. Es geht darum, Migrationen kontrollierbar zu halten, Fehler leichter zu finden und jederzeit einen klaren funktionierenden Zwischenstand zu haben.

Am Ende entscheidet deshalb nicht nur die Zahl der übersprungenen TYPO3-Versionen, sondern vor allem, wie komplex das konkrete Projekt ist und was sich zwischen diesen Versionen geändert hat.