Upgrade oder Relaunch? Warum die eigentliche Entscheidung nichts mit TYPO3-Versionen zu tun hat

Diese Frage begleitet praktisch jedes größere TYPO3-Projekt irgendwann. Je älter eine Installation wird, desto häufiger taucht sie auf – meist nicht bei den Entwicklern, sondern auf Management-Ebene. Denn dort geht es nicht um APIs oder Extensions, sondern um Budgets, Risiken und die Frage, welche Entscheidung die Plattform für die nächsten Jahre tragfähig macht.

Interessanterweise beobachten wir immer wieder, dass diese Diskussion mit den falschen Kriterien beginnt. Es wird über Versionsnummern gesprochen, über veraltete PHP-Versionen, nicht mehr unterstützte Extensions oder den Zustand des Quellcodes. All das ist natürlich relevant. Trotzdem entscheidet aus unserer Sicht keines dieser Themen darüber, ob ein Upgrade sinnvoll ist.

Die eigentliche Frage lautet vielmehr:

Wie viel Wissen steckt heute bereits in dieser Plattform – und was würde es kosten, dieses Wissen noch einmal neu aufzubauen?

Software altert anders als Gebäude

Es ist verlockend, Software mit einem Gebäude zu vergleichen. Irgendwann ist ein Haus alt, die Haustechnik entspricht nicht mehr dem aktuellen Stand und irgendwann stellt sich die Frage, ob eine Sanierung noch sinnvoll ist.

Software funktioniert jedoch anders.

Ein zehn Jahre altes TYPO3-Projekt ist nicht automatisch technisch schlecht. Häufig ist sogar das Gegenteil der Fall. Dass eine Plattform über viele Jahre kontinuierlich genutzt wurde, bedeutet meistens, dass sie einen echten geschäftlichen Mehrwert geschaffen hat. Redakteure haben ihre Arbeitsabläufe daran angepasst, individuelle Prozesse wurden integriert, Schnittstellen sind entstanden und zahlreiche kleine Optimierungen wurden umgesetzt, die in keinem Pflichtenheft dieser Welt stehen.

Genau diese Dinge machen eine Enterprise-Plattform wertvoll. Und genau diese Dinge verschwinden nicht einfach dadurch, dass man beschließt, „alles neu zu machen".

Der Code ist selten das eigentliche Problem

Vor einiger Zeit wurden wir von einer Agentur in ein Upgrade-Projekt eingebunden, dessen technische Ausgangslage auf den ersten Blick durchaus für einen Relaunch sprach.

Die Plattform lief noch auf TYPO3 8.7, war über viele Jahre gewachsen und bestand aus rund vierzig Extensions, mehreren individuell entwickelten Backend-Modulen und einer Fachanwendung, die tief in die Geschäftsprozesse des Endkunden integriert war. Einige der verwendeten Third-Party-Extensions wurden längst nicht mehr aktiv gepflegt, viele APIs waren veraltet und einzelne Teile des Projekts stammten noch aus einer Zeit, in der TYPO3_DB der übliche Weg für Datenbankzugriffe war.

Man hätte gute Argumente dafür finden können, alles neu zu entwickeln. Tatsächlich verlief die Diskussion zu Beginn genau in diese Richtung.

Je länger wir uns jedoch mit dem Projekt beschäftigten, desto deutlicher wurde, dass nicht der technische Zustand des Systems die eigentliche Herausforderung darstellte. Die größere Herausforderung bestand darin, zu verstehen, wie viel Geschäftslogik sich im Laufe der Jahre in dieser Anwendung angesammelt hatte.

Viele Funktionen wirkten auf den ersten Blick klein oder unscheinbar. Manche waren nur wenige Zeilen Code. Trotzdem waren sie für die Anwender selbstverständlich geworden und wurden täglich genutzt. Ein Relaunch hätte bedeutet, all diese Details zunächst wieder zu entdecken, anschließend neu zu entwerfen und schließlich erneut zu testen.

Die eigentliche Komplexität lag also nicht im Code. Sie lag im Wissen.

Warum Upgrades oft unnötig teuer werden

Genau an diesem Punkt hat sich unsere Sichtweise auf TYPO3-Upgrades in den letzten Jahren grundlegend verändert.

Als wir unsere ersten größeren Upgrade-Projekte durchgeführt haben, dachten wir wie viele andere Teams hauptsächlich in technischen Aufgaben. Welche APIs müssen ersetzt werden? Welche Extensions sind kompatibel? Welche Upgrade Wizards müssen ausgeführt werden?

Heute würden wir dieselben Projekte völlig anders beschreiben. Wir sehen Upgrades inzwischen vor allem als Engineering-Aufgabe.

Denn die eigentlichen Kosten entstehen erstaunlich selten durch TYPO3 selbst. Sie entstehen durch wiederholte Arbeit, durch Unsicherheit, durch manuelle Prozesse – durch Dinge, die mehrfach erledigt werden müssen, obwohl sie eigentlich nur einmal notwendig wären.

Ein typisches Beispiel ist die schrittweise Modernisierung einer Codebasis. Viele Upgrade-Projekte passen den Code zunächst so weit an, dass TYPO3 9 funktioniert. Kurz darauf wird dieselbe Stelle erneut geändert, damit TYPO3 10 lauffähig ist. Danach folgen weitere Anpassungen für TYPO3 11 und TYPO3 12.

Technisch ist dieser Weg vollkommen korrekt. Aus Engineering-Sicht erzeugt er jedoch Arbeit, die ausschließlich deshalb existiert, weil sich der Entwicklungsprozess an Zwischenversionen orientiert. Für den späteren Betrieb der Plattform bringt diese Arbeit keinen zusätzlichen Nutzen.

Dasselbe beobachten wir beim Testen. Wenn nach jeder größeren Änderung umfangreiche manuelle Regressionstests notwendig werden, steigen Aufwand und Projektrisiko kontinuierlich an. Das eigentliche Problem liegt jedoch nicht im Testen selbst, sondern darin, dass der Entwicklungsprozess zu wenige Möglichkeiten bietet, Fehler frühzeitig automatisch sichtbar zu machen.

Je häufiger wir solche Muster gesehen haben, desto klarer wurde uns, dass die Qualität eines Upgrades nicht allein davon abhängt, wie gut Entwickler programmieren. Sie hängt mindestens genauso stark davon ab, wie gut der Upgrade-Prozess selbst entwickelt wurde.

Gute Engineering-Prozesse verändern die Wirtschaftlichkeit eines Upgrades

Das war vermutlich die wichtigste Erkenntnis der letzten Jahre.

Viele Unternehmen betrachten Engineering als zusätzlichen Aufwand. Skripte müssen geschrieben werden. Automatisierte Tests kosten Zeit. Deployment-Prozesse werden aufgebaut. Interne Werkzeuge entstehen, obwohl der Kunde sie später nie sieht.

Kurzfristig betrachtet stimmt das sogar. All diese Dinge kosten Zeit. Langfristig verändern sie jedoch die Wirtschaftlichkeit eines Projekts erheblich.

• Ein reproduzierbarer Migrationsprozess reduziert wiederholte Arbeit.
• Automatisierte Regressionstests verringern den manuellen Testaufwand.
• Eine gemeinsame Wissensbasis verhindert, dass dieselben Probleme in jedem Projekt erneut gelöst werden.
• Eine strukturierte Checkliste reduziert das Risiko beim Go-live.

Keine dieser Maßnahmen erzeugt unmittelbar eine neue Funktion für den Endkunden. Zusammen sorgen sie jedoch dafür, dass ein Upgrade planbarer, qualitativ hochwertiger und häufig auch wirtschaftlicher wird.

Aus unserer Sicht ist genau das der Unterschied zwischen Entwicklung und Engineering. Entwicklung löst ein Problem. Engineering sorgt dafür, dass dasselbe Problem möglichst nie wieder auf dieselbe Weise gelöst werden muss.

Warum wir uns für das Upgrade entschieden haben

Im beschriebenen Projekt führte genau diese Denkweise schließlich zu einer anderen Entscheidung.

Wir betrachteten das Projekt nicht mehr als eine Folge einzelner TYPO3-Versionen, sondern als eine Plattform, die auf eine neue Zielarchitektur gebracht werden sollte. Daraus entstand unser Ansatz, Code- und Datenbankmigration konsequent voneinander zu trennen. Dadurch konnten wir viele Zwischenschritte vermeiden, die in einem klassischen Upgrade-Prozess unvermeidbar erscheinen.

Werkzeuge wie Rector, der TYPO3 Extension Scanner, unsere eigene Legacy-Updater-Erweiterung sowie visuelle Regressionstests mit BackstopJS waren dabei wichtige Bausteine. Entscheidend war jedoch nicht das einzelne Werkzeug, sondern die Art, wie sie zusammenspielten.

Jedes Werkzeug hatte nur eine Aufgabe: eine bestimmte Kategorie wiederkehrender Arbeit dauerhaft zu eliminieren.

Das Ergebnis war nicht nur eine erfolgreiche Migration auf TYPO3 14.3. Die Plattform profitierte zusätzlich von einer moderneren Architektur, einer spürbar besseren Performance und einer Codebasis, die sich in Zukunft deutlich einfacher weiterentwickeln lässt.

Vor allem aber wurde aus einer Diskussion über einen möglichen Relaunch ein Upgrade, das wirtschaftlich überzeugender war als ein kompletter Neubau. Nicht weil TYPO3 einfacher geworden wäre, sondern weil wir den Engineering-Prozess verändert haben.

Was wir aus diesem Projekt mitgenommen haben

Wenn wir heute auf dieses Projekt zurückblicken, denken wir kaum noch an TYPO3 8.7 oder TYPO3 14.3. Die Versionsnummern waren letztlich nur der Rahmen. Die eigentliche Erkenntnis war eine andere.

Die Kosten eines Enterprise-Upgrades werden wesentlich stärker durch den Engineering-Prozess bestimmt als durch die Anzahl der Major-Versionen, die dazwischenliegen.

Je besser es gelingt, wiederholte Arbeit zu vermeiden, Unsicherheit frühzeitig sichtbar zu machen und Qualität systematisch in den Prozess einzubauen, desto wirtschaftlicher wird ein Upgrade – und desto höher ist gleichzeitig die Qualität des Ergebnisses.

Vielleicht ist genau das der wichtigste Grund, warum wir heute deutlich seltener über Versionsnummern sprechen als noch vor einigen Jahren. Nicht, weil sie unwichtig wären, sondern weil sie selten die eigentliche Herausforderung darstellen.