Wenn sich Third-Party-Extensions verändern: Warum es bei TYPO3-Upgrades selten die perfekte Lösung gibt

Wer schon einmal eine TYPO3-Installation modernisiert hat, die über viele Jahre produktiv im Einsatz war, kennt die Situation.

Die eigentliche Migration läuft gut. Die Codebasis wird modernisiert, Deprecations verschwinden nach und nach, Datenbankmigrationen sind vorbereitet und die Plattform nähert sich der Zielversion. Irgendwann stößt man jedoch auf eine Extension, die technisch zwar weiterhin existiert, sich funktional jedoch deutlich verändert hat.

Die neue Version unterstützt TYPO3 14 problemlos, sie wird aktiv gepflegt, und sie erhält Sicherheitsupdates. Und trotzdem fehlt plötzlich eine Funktion, die der Kunde seit Jahren selbstverständlich nutzt.

An diesem Punkt beginnt keine technische Diskussion mehr. Es beginnt eine Produktentscheidung.

Software entwickelt sich weiter – auch wenn das eigene Projekt stillsteht

Eine TYPO3-Installation wird häufig über viele Jahre kontinuierlich genutzt. Währenddessen entwickelt sich nicht nur TYPO3 selbst weiter. Auch die eingesetzten Extensions verändern sich permanent.

• Maintainer reagieren auf neue Anforderungen.
• Architekturen werden modernisiert.
• Benutzeroberflächen werden überarbeitet.
• Neue Funktionen entstehen.
• Alte verschwinden.

Teilweise, weil sie technisch nicht mehr sinnvoll sind, teilweise, weil sie nur von wenigen Projekten genutzt wurden, und manchmal schlicht deshalb, weil sich die Ausrichtung einer Extension verändert hat.

Aus Sicht der Maintainer ist das völlig nachvollziehbar. Eine aktiv gepflegte Software muss sich weiterentwickeln.

Für ein Upgrade-Projekt entsteht dadurch allerdings ein neues Problem. Die Plattform des Kunden soll modernisiert werden. Gleichzeitig erwartet der Kunde verständlicherweise, dass sich seine täglichen Arbeitsabläufe möglichst wenig verändern.

Diese beiden Ziele lassen sich nicht immer vollständig miteinander vereinbaren.

Drei naheliegende Lösungen – und warum keine davon perfekt ist

In Gesprächen mit Agenturen tauchen meistens dieselben drei Vorschläge auf.

Der erste lautet: „Dann entwickeln wir die fehlende Funktion eben selbst.“

Technisch ist das oft problemlos möglich. Langfristig übernimmt man damit allerdings Verantwortung für eine individuelle Erweiterung, die künftig gepflegt, getestet und bei späteren Upgrades erneut berücksichtigt werden muss.

Aus einer fehlenden Funktion wird eigenes Produktverhalten.

Der zweite Vorschlag lautet: „Dann muss der Kunde akzeptieren, dass diese Funktion nicht mehr existiert.“

Auch diese Sichtweise lässt sich technisch begründen. Schließlich entwickelt sich Software weiter.

Aus Sicht der Anwender fühlt sich diese Antwort jedoch selten zufriedenstellend an. Der eigentliche Auftrag lautete schließlich nicht, Geschäftsprozesse zu verändern, sondern eine bestehende Plattform zu modernisieren.

Der dritte Vorschlag besteht darin, einfach bei der alten Extension-Version zu bleiben. Das verschiebt das Problem allerdings lediglich in die Zukunft. Eine nicht mehr gepflegte Extension wird durch zusätzliche Jahre selten einfacher zu migrieren. Im Gegenteil: Die technische Schuld wächst weiter.

Interessanterweise erscheint jede dieser Lösungen auf den ersten Blick plausibel. Und trotzdem überzeugt uns keine davon als allgemeine Regel.

Unsere erste Frage lautet deshalb nicht: „Wie lösen wir das?“ Wir stellen zunächst eine andere Frage.

Welche Aufgabe erfüllt diese Funktion eigentlich?

Das klingt selbstverständlich. Ist es aber erstaunlich selten.

Nach vielen Jahren produktiver Nutzung existieren in fast jeder Enterprise-Plattform Funktionen, die historisch gewachsen sind. Manche werden täglich verwendet. Andere wurden seit Jahren nicht mehr angefasst.

Deshalb beginnen wir solche Diskussionen grundsätzlich nicht mit der Technik, sondern mit dem eigentlichen Anwendungsfall.

• Wird diese Funktion heute tatsächlich noch benötigt?
• Hat sich der zugrunde liegende Geschäftsprozess verändert?
• Gibt es in der aktuellen Extension inzwischen einen anderen Weg, dasselbe Ziel zu erreichen?
• Oder wurde lediglich die Benutzeroberfläche verändert?

Erst wenn diese Fragen beantwortet sind, sprechen wir über technische Lösungen.

Warum wir fast immer auf die aktuelle Extension-Version setzen

Eine Entscheidung treffen wir allerdings sehr bewusst. Wenn eine Extension aktiv gepflegt wird, verwenden wir grundsätzlich die aktuelle unterstützte Version.

Nicht, weil neue Versionen automatisch besser wären, sondern weil wir glauben, dass ein Upgrade nicht nur das heutige Projekt lösen sollte. Es soll die Plattform für die kommenden Jahre wartbar machen.

Eine aktiv gepflegte Extension entwickelt sich gemeinsam mit TYPO3 weiter.

• Sie erhält Sicherheitsupdates.
• Neue PHP-Versionen werden unterstützt.
• Fehler werden behoben.
• Neue Anforderungen fließen ein.

Wer sich bewusst gegen diese Entwicklung entscheidet, löst häufig ein kurzfristiges Problem und schafft gleichzeitig ein deutlich größeres für das nächste Upgrade.

Wann individueller Code trotzdem sinnvoll ist

Natürlich gibt es Situationen, in denen eine fehlende Funktion geschäftskritisch ist. Dann stellt sich die Frage, ob individueller Code entstehen sollte.

Unsere Antwort lautet hier weder grundsätzlich Ja noch grundsätzlich Nein. Wir betrachten individuellen Code nicht als Niederlage. Aber auch nicht als Standardlösung.

Wenn wir eine Funktion selbst entwickeln, dann bewusst. Nicht, weil sie zufällig in einer neuen Extension-Version fehlt, sondern weil wir gemeinsam mit der Agentur und dem Kunden entschieden haben, dass diese Funktion einen langfristigen geschäftlichen Wert besitzt.

Das ist ein entscheidender Unterschied. Denn damit wird individueller Code zu einer bewussten Investition – und nicht zu einer spontanen Reaktion auf ein Upgrade.

Es gibt noch einen zweiten Fall

Nicht jede Extension entwickelt sich weiter. Gerade in älteren TYPO3-Projekten begegnen wir immer wieder Erweiterungen, deren Entwicklung seit Jahren eingestellt wurde.

Hier stellt sich eine völlig andere Frage. Nicht: „Welche aktuelle Version verwenden wir?“ Sondern: „Gibt es überhaupt noch eine Zukunft für diese Extension?“

Wenn keine realistische Nachfolge existiert und die Funktion unverzichtbar bleibt, modernisieren wir solche Extensions häufig selbst. Dabei geht es allerdings nicht darum, den ursprünglichen Maintainer zu ersetzen. Es geht darum, eine bestehende Geschäftsfunktion langfristig zu erhalten.

Auch diese Entscheidung treffen wir bewusst. Nicht automatisch.

Gute Upgrades bestehen aus guten Entscheidungen

Vielleicht ist genau das die wichtigste Erkenntnis aus vielen Enterprise-Upgrades.

Die schwierigsten Aufgaben bestehen selten darin, eine API zu ersetzen oder eine Datenbankmigration durchzuführen. Sie bestehen darin, technische Möglichkeiten mit wirtschaftlichen und fachlichen Anforderungen in Einklang zu bringen.

Ein Upgrade ist deshalb aus unserer Sicht nie ausschließlich ein technisches Projekt. Es ist immer auch eine Reihe von Produktentscheidungen.

• Welche Funktionen sollen bleiben?
• Welche dürfen sich verändern?
• Welche Investitionen sind langfristig sinnvoll?
• Welche technische Schuld lohnt sich noch – und welche nicht mehr?

Werkzeuge können diese Fragen nicht beantworten. Checklisten ebenfalls nicht.

Sie benötigen Erfahrung. Und häufig auch den Mut, zu akzeptieren, dass es in manchen Situationen keine perfekte Lösung gibt.

Was wir aus diesen Projekten gelernt haben

Nach vielen TYPO3-Upgrades glauben wir heute weniger an allgemeingültige Regeln als noch vor einigen Jahren. Wir glauben dafür stärker an gute Entscheidungsprinzipien.

• Aktiv gepflegte Software sollte möglichst aktuell bleiben.
• Geschäftskritische Funktionen verdienen eine bewusste Bewertung.
• Individueller Code sollte eine strategische Entscheidung sein und keine spontane Reaktion.

Und vor allem sollte jede technische Entscheidung den Zeitraum berücksichtigen, der nach dem Upgrade beginnt.

Denn der eigentliche Erfolg eines Enterprise-Upgrades zeigt sich selten am Tag des Go-lives. Er zeigt sich in den Jahren danach, wenn die Plattform weiterhin wartbar bleibt und zukünftige Veränderungen nicht unnötig erschwert.