TYPO3 12 auf 13 ohne Big Bang: Major-Upgrade in Arbeitspaketen

Christopher Zechendorf

15.06.2026

Share:

Wie wir VINUM von TYPO3 12 auf 13 gehoben haben – nicht im Big-Bang, sondern in einzeln deploybaren, dual-kompatiblen Arbeitspaketen mit minimalem Risiko.

Major-Upgrade ohne Stillstand: TYPO3 12 auf 13 in Arbeitspaketen

Ein großes, über Jahre gewachsenes TYPO3-Projekt auf eine neue Hauptversion zu heben, ist für jeden Betreiber ein heikles Vorhaben. Je mehr Eigenentwicklung, Schnittstellen und Inhalte zusammenkommen, desto größer ist die Versuchung, den Versionssprung in einem einzigen, riskanten Rundumschlag zu erledigen – wochenlang an einem Zweig zu arbeiten, alles auf einmal umzustellen und dann zu hoffen, dass beim Go-live nichts bricht.

Am Beispiel der internationalen Weinplattform VINUM zeigen wir, dass es anders geht. Wir haben die TYPO3-12-Installation Schritt für Schritt auf Version 13 vorbereitet – in klar geschnittenen Arbeitspaketen, die einzeln und „dual-kompatibel” (gleichzeitig lauffähig auf 12 und 13) in Produktion gehen konnten. Der eigentliche Versionswechsel schrumpft dadurch auf einen letzten, kleinen Handgriff.

Die Herausforderung

Ein Major-Upgrade von TYPO3 12 auf 13 bringt eine ganze Reihe von Brüchen mit sich, die quer durch die gesamte Anwendung reichen:

• Fatale API-Entfernungen: Funktionen, die beim Hochfahren der Seite aufgerufen werden, gibt es in Version 13 schlicht nicht mehr – die Seite würde gar nicht erst starten.
• Neue Datenbank-Schicht: Mit Doctrine DBAL 4 ändern sich Abfrage- und Ergebnis-Schnittstellen tiefgreifend, verteilt über mehr als hundert Stellen im Code.
• Modernisierte Konfiguration: Die Feld- und Formulardefinitionen (TCA und FlexForm) sowie das Template-System (Fluid) verlangen aktualisierte Syntax.
• Drittanbieter-Erweiterungen: Such-Engine, Frontend-Registrierung und weitere Module mussten auf 13-fähige Stände gehoben oder ersetzt werden.
• Das Risiko: All das gleichzeitig umzustellen, hätte einen wochenlangen Feature-Freeze und einen einzigen, kaum testbaren großen Sprung bedeutet.

Unser Ziel war ein Upgrade ohne wochenlangen Stillstand, ohne Big-Bang und mit einem jederzeit reversiblen Pfad zurück.

Unsere Lösung

Der zentrale Gedanke: Rund 90 Prozent der notwendigen Änderungen lassen sich so schreiben, dass sie auf TYPO3 12 und 13 identisch funktionieren. Genau diese Änderungen haben wir vorgezogen und einzeln auf die noch unter Version 12 laufende Produktivseite ausgeliefert. So wird jede Auslieferung zu ihrem eigenen Regressionstest – und der finale Versionswechsel besteht am Ende nur noch aus dem, was sich wirklich nicht dual-kompatibel umsetzen lässt.

1. Zerlegung in Arbeitspakete

Statt eines Mammut-Branches haben wir das Upgrade in rund ein Dutzend Arbeitspakete zerschnitten – jedes ein eigenständiger, fachlich abgeschlossener Schritt, der für sich entwickelt, geprüft und live geschaltet wurde:

• Grundlagen und Plan: eine belastbare Bestandsaufnahme aller Brüche und ein verbindlicher Migrationsplan als Fortschritts-Tracker.
• Fatale Alt-APIs zuerst: alle Aufrufe entfernen, die Version 13 beim Start sofort abstürzen lassen würden – noch unter 12 sauber umgestellt.
• Datenbank-Schicht: die hundertfach genutzten Abfrage- und Ergebnis-Aufrufe auf die neuen Doctrine-DBAL-4-Schnittstellen umgestellt, jeweils sorgfältig zwischen lesenden und schreibenden Zugriffen unterschieden.
• Konfiguration modernisiert: über 70 Felddefinitionen sowie die FlexForm-Formulare auf die aktuelle, versionssichere Syntax gebracht.
• Templates und TypoScript: veraltete Schreibweisen im Template- und Konfigurationssystem bereinigt und totgelegten Code entfernt.
• Abhängigkeiten gehoben: eigene Pakete und Drittanbieter-Erweiterungen für beide Versionen freigegeben und vorab aktualisiert.

Jedes Paket trug die Auflage, die Testabdeckung der berührten Stellen mitzuziehen – Lücken wurden im Paket geschlossen, nicht ins Backlog verschoben.

2. Das Prinzip „dual-kompatibel”

Jeder einzelne Schritt musste drei Bedingungen erfüllen: heute auf Version 12 laufen, später auf 13 laufen, und nach dem Zusammenführen die komplette Testsuite grün halten. Dadurch ging jede Änderung sofort regulär in Produktion – über denselben Entwicklungs-, Prüf- und Freigabe-Prozess wie jede andere Anpassung auch. Die Live-Seite unter Version 12 hat die Dual-Kompatibilität bei jedem Deployment aufs Neue bestätigt: Produktion als kontinuierliches Testlabor, statt eines einzigen Stichtags, an dem sich alles entscheidet.

Der angenehme Nebeneffekt: Das Tagesgeschäft lief ungebremst weiter. Es gab keinen wochenlangen Feature-Freeze, und jeder Schritt war für sich genommen klein genug, um ihn bei Bedarf einzeln zurückzunehmen.

3. Aufräumen mit messbarem Mehrwert

Eine gründliche Modernisierung deckt zwangsläufig Altlasten auf – und genau hier zahlte sich die Sorgfalt aus. Bei der Umstellung der Datenbank-Schicht fanden wir mehrere Hintergrund-Routinen, die seit Längerem unbemerkt ins Leere liefen und ihre Aufgabe gar nicht mehr erledigten. Bei der Bereinigung der Felddefinitionen stießen wir auf eine versteckte Fehlkonfiguration, die bei jedem Laden der Backend-Oberfläche ungewollt Code ausführte. Beides wurde im Zuge des Upgrades korrigiert und mit Tests abgesichert. Aus „nur” einer Migration wurde so handfeste Qualitäts- und Sicherheitsverbesserung.

4. Pre-Flight-Audits als Go/No-Go-Checkliste

Vor dem eigentlichen Versionswechsel haben wir die heiklen Bereiche gezielt auditiert – die Frontend-Registrierung, die Anbindung der Such-Engine Apache Solr, die mehrsprachige Konfiguration und der Bestand aller eingesetzten Plugins. Jeder Bereich bekam ein klares Votum: läuft unverändert, läuft mit definierten Anpassungen, oder blockiert. Dieses Vorgehen brachte die letzten echten Stolperfallen ans Licht – etwa einen Such-Controller, der beim Versionswechsel abgestürzt wäre, und der erst in der zweiten Prüfrunde vollständig erfasst wurde. Am Ende stand eine belastbare Go-Entscheidung ohne offene Blocker, statt eines Bauchgefühls.

5. Ein Migrationszwang als Produktgewinn

Ein veraltetes Formular-Modul musste ohnehin weichen. Statt die betroffenen Formulare einfach nachzubauen, haben wir genauer hingeschaut: Die noch aktiven Registrierungsformulare für Weingüter fütterten einen doppelten manuellen Arbeitsablauf auf Kundenseite. Wir haben sie durch ein natives Registrierungs-Plugin ersetzt, das die Daten direkt strukturiert erfasst, gegen Spam absichert und die nachgelagerten Schritte automatisch verzahnt. Aus einer reinen Upgrade-Pflicht wurde so ein spürbarer Effizienzgewinn im Tagesgeschäft.

Das Ergebnis

Sämtliche vorbereitenden Arbeitspakete sind umgesetzt, geprüft und längst auf der Produktivseite live – weiterhin unter TYPO3 12, aber vollständig dual-kompatibel und bei jedem Deployment aufs Neue bestätigt. Der finale Versionswechsel ist dadurch von einem riskanten Großereignis auf einen kleinen, gut vorbereiteten Schritt geschrumpft: im Wesentlichen die Aktualisierung der Abhängigkeiten, die Umstellung der Such-Infrastruktur und der Durchlauf der Upgrade-Assistenten – abgesichert durch eine Staging-Probe und eine Datensicherung unmittelbar davor.

Dieser Ansatz ist übertragbar. Denselben Bauplan – Bestandsaufnahme, dual-kompatible Arbeitspakete, Produktion als Testlabor, Pre-Flight-Audit vor dem Flip – nutzen wir auch für andere komplexe TYPO3-Installationen. Major-Upgrades verlieren damit ihren Schrecken: kein Stillstand, kein Big-Bang und jederzeit ein Weg zurück.

Fazit

Ein Versionssprung auf eine neue TYPO3-Hauptversion muss kein Wagnis sein. Wer die Brüche früh inventarisiert, in dual-kompatible Einzelschritte zerlegt und konsequent gegen die laufende Produktion testet, hält das Regressions- und Stillstandsrisiko durchgehend niedrig – und gewinnt nebenbei Gelegenheit, echte Altlasten zu beseitigen.

Steht bei Ihnen ein TYPO3-Upgrade an, oder betreiben Sie eine gewachsene Installation, die modernisiert werden sollte? Sprechen Sie mit uns – wir planen den Weg auf die nächste Version so, dass Ihr Betrieb dabei nie stillsteht.