Dass ein TYPO3 Upgrade kein Standard-Task ist, der sich mal eben nebenbei erledigt, war uns bewusst. Dass es aber so viele Baustellen gleichzeitig aufmacht — von ContentBlocks über eigene Extensions bis zur Deployment-Pipeline — haben wir in diesem Umfang erst im Prozess wirklich verstanden. In diesem Beitrag zeigen wir, wie wir als TYPO3 Agentur aus Stuttgart ein produktives Kundenprojekt auf Mittwald-Hosting direkt von TYPO3 v11 LTS auf v13 gehoben haben, warum wir den Sprung über zwei Major-Versionen bewusst in einem Rutsch gegangen sind und wo sich der Großteil der Arbeit tatsächlich versteckt hat.
Warum direkt von v11 auf v13 — und nicht schrittweise
Die naheliegende Option wäre gewesen: erst v12, dann v13. Sicherer, planbarer, beherrschbarer. Wir haben uns dagegen entschieden — aus einem einfachen Grund. Wer zweimal durch den gleichen Anpassungsprozess geht, zahlt auch zweimal: zwei Mal Extension-Analyse, zwei Mal Datenbankmigrationen, zwei Mal Deployment-Pipeline anpassen, zwei Mal Staging, zwei Mal Kundenkommunikation. Der Aufwand summiert sich, der Nutzen bleibt der gleiche.
Wenn die Zielversion ohnehin v13 ist, spricht wenig dafür, auf halber Strecke eine Zwischenversion zu stabilisieren, die man im nächsten Schritt wieder anfasst. Der direkte Weg war in diesem Fall der effizientere — auch wenn er in der Vorbereitung mehr Sorgfalt verlangt hat.
Was das Projekt besonders gemacht hat: Multisite mit gemeinsamen Sitepackages
Das Projekt läuft nicht als einfache Einzelseite, sondern als Multisite-Setup: mehrere TYPO3-Instanzen teilen sich dieselben Sitepackages. Das bedeutet, dass Änderungen an Templates, TypoScript oder ContentBlock-Definitionen sofort alle Seiten betreffen — ein Fehler wirkt sich nicht lokal aus, sondern systemweit.
Diese Abhängigkeit zwingt zu einem anderen Vorgehen als bei einem isolierten Einzelprojekt. Jede Anpassung musste so entwickelt werden, dass sie für alle Seiten gleichzeitig funktioniert. Regressionstests konnten nicht seitenweise abgehakt werden, sondern mussten jede der betroffenen Instanzen einschließen. Das hat den Testaufwand nicht verdoppelt, aber spürbar erhöht.
Vorbereitung: Was wirklich vor dem ersten Composer-Befehl passiert
Bevor irgendetwas am Code angefasst wurde, stand eine strukturierte Analyse. Der TYPO3 Upgrade Wizard hat einen ersten Überblick über Kompatibilitätsprobleme der installierten Extensions gegeben. Composer-Abhängigkeiten wurden dokumentiert: Was wird in v13 durch Core-Funktionen abgelöst, was bleibt als Drittanbieter-Extension erhalten, was fliegt komplett raus?
TYPO3 v13 setzt PHP 8.2 oder höher voraus — auch das war ein Prüfpunkt, der frühzeitig geklärt sein musste. Für das Hosting auf Mittwald bedeutete das einen koordinierten Wechsel der PHP-Version, der mit dem Upgrade-Zeitplan abgestimmt werden musste.
Die Backup-Strategie war mehrstufig: Datenbankdump, Filesystem-Backup, lokale DDEV-Snapshots und die Recovery-Points auf Mittwald als letztes Sicherheitsnetz. Nicht als bürokratische Vorsichtsmaßnahme, sondern weil wir wussten, dass wir unterwegs auf unerwartete Zustände stoßen würden.
Halten Sie Ihre Systeme regelmäßig aktuell?
Regelmäßige Updates sichern Stabilität, Sicherheit und Performance – wie konsequent ist Ihr Vorgehen?
Extensions: Was bleibt, was geht, was komplett neu gedacht wird
Bei einem Sprung über zwei Major-Versionen ist die Extension-Landschaft das erste, was kritisch wird. Viele Extensions haben zwischen v11 und v13 grundlegende Änderungen an ihrer API und Struktur durchgemacht. Einige wurden zwischenzeitlich aufgegeben, andere durch Core-Features ersetzt.
Die ehrlichste Frage, die man sich bei jeder Extension stellen muss: Ist dieses Paket noch zukunftsfähig, oder schleppen wir es nur mit, weil wir es schon immer hatten? Wer diese Entscheidung erst dann trifft, wenn die Extension den Upgrade-Prozess blockiert, zahlt teurer als jemand, der frühzeitig auf Alternativen wechselt.
Neben den Drittanbieter-Extensions enthielt das Projekt eigene Extensions — gewachsener Code, der über Jahre im v11-Kontext funktioniert hatte. Der Sprung auf v13 hat hier Code-Refactoring verlangt: veraltete API-Aufrufe, nicht mehr unterstützte Klassen, geänderte Hook-Strukturen. Dieser Teil des Projekts war kein großer Einzelblock, aber eine kontinuierliche Begleitarbeit, die sich durch den gesamten Upgrade-Prozess gezogen hat. Deprecation-Notices erkennen, verstehen, was dahintersteckt, und sauber ersetzen — das lässt sich nicht automatisieren, nur beschleunigen.
ContentBlocks: Der größte Brocken im ganzen Projekt
Wer ContentBlocks kennt, weiß, dass sie in v11 noch als standalone Package über Friends-of-TYPO3 liefen. In v13 sind ContentBlocks nativ im Core — und zwar mit einer komplett anderen Struktur. Die EditorInterface.yaml hat das bisherige Format abgelöst, die internen Mechanismen haben sich grundlegend geändert.
Das bedeutet: keine Migration, kein Cherry-Pick, kein automatisches Skript. Alles musste manuell neu geschrieben werden. Jeder ContentBlock, jede Feldkonfiguration, jede Abhängigkeit — von Grund auf nach dem neuen Schema.
Die Folgewirkungen reichten bis auf Datenbankebene. CTypes mussten überarbeitet werden, FAL-Referenzen in sys_file und sys_file_reference mussten angepasst und auf Konsistenz geprüft werden. Hier hat sich der Großteil der zusätzlichen Arbeitszeit versteckt. Der initiale Schätzaufwand war — rückblickend betrachtet — zu optimistisch. Das ist keine Kritik am Vorgehen, sondern eine ehrliche Einschätzung: ContentBlocks über Versionen zu migrieren ist eine eigene Disziplin.
Datenbankmigrationen: Wie wir ohne Live-Risiko vorgegangen sind
Das Vorgehen bei der Datenbankmigration war bewusst konservativ. Ausgangspunkt war immer ein aktueller Dump aus dem Live-System, importiert in eine lokale DDEV-Umgebung. Dort wurden alle strukturellen Anpassungen entwickelt und getestet: CType-Umbenennungen, neue Feldstrukturen, FAL-Konsistenz-Checks — iterativ, bis der Zustand lokal sauber und stabil war.
Die angepasste Datenbank wurde anschließend als neue, separate Datenbank auf Mittwald importiert. Sowohl Beta- als auch Live-Umgebung wurden auf diese neue Datenbank umgestellt. Die entscheidende Konsequenz: Die originale Live-Datenbank blieb bis zum finalen Switch unangetastet. Rollback wäre jederzeit möglich gewesen.
Wer große Dumps mit PHPMyAdmin importieren will, stößt schnell an File-Size-Limits. Der CLI-Import ist die zuverlässigere Alternative — bei Mittwald mit dem expliziten -h DATENBANKHOST-Parameter, da die Datenbank auf einem separaten Host läuft.
FAL-Konsistenz ist kein Detail
Ein Punkt, der unterschätzt werden kann: Dateien zu übertragen reicht nicht. Die Datenbankrecords in sys_file und sys_file_reference müssen synchron mit den tatsächlichen Dateien sein — sonst brechen Bildanzeigen im Frontend, ohne dass es auf den ersten Blick einen offensichtlichen Grund gibt. FAL-Konsistenz-Checks sind kein optionaler Schritt.
Bootstrap 4 auf 5: Der parallele Frontend-Umbau
Parallel zum TYPO3-Upgrade haben wir den Sprung von Bootstrap 4 auf Bootstrap 5 gemacht. Beides gleichzeitig anzugehen ist kein Selbstläufer — aber wer ohnehin alle Templates anfasst, hat selten einen besseren Zeitpunkt.
Bootstrap 5 hat die jQuery-Abhängigkeit entfernt und die Datenattribute geändert: aus data-* wurde data-bs-*. Das klingt nach einem kleinen Find-and-Replace, ist aber bei individuell aufgebauten ContentBlocks und ContentElements eine akribische Einzelarbeit. Der Sticky Header und das Navbar-Verhalten funktionierten nach dem Wechsel nicht mehr korrekt und mussten durch eigene CSS- und JavaScript-Logik ersetzt werden.
Ein visueller Regressionsvergleich — alter Look gegen neuen Look — war hier kein Luxus, sondern notwendig. Der Kunde soll keine ungewollten Designänderungen bemerken. Was sich technisch ändert, muss visuell stabil bleiben.
Deployment-Pipeline: Auch das musste mit
Deployer 7 hat gegenüber der Vorgängerversion neue Konventionen eingeführt: geänderte Host-Methoden, neue Recipe- und Import-Strukturen, ersetzte deprecated Tasks. Der GitHub Actions Workflow musste angepasst werden — unter anderem der explizite Aufruf php vendor/bin/dep statt der bisherigen deployphp/action.
Ein lokales Composer-Package, das im Projekt als Sonderfall existiert, wurde über shared_dirs und einen Pre-Deployment-Rsync-Schritt gelöst. Kein großes Problem, aber einer der vielen kleinen Punkte, die sich erst im Live-Test zeigen — und die man vorher nicht vollständig antizipieren kann.
Was wir beim nächsten Mal früher angehen würden
ContentBlocks zuerst. Wer den Aufwand für die manuelle Migration unterschätzt, verliert Zeit an der Stelle, wo der Druck am größten ist. Beim nächsten Projekt dieser Art würden wir ContentBlocks als erstes isoliert durcharbeiten — noch bevor andere Upgrade-Schritte beginnen.
Die Beta-Phase würde länger eingeplant werden. Nicht weil das Vorgehen nicht funktioniert hat, sondern weil mehr Zeit auf Beta weniger Überraschungen auf Live bedeutet. Das Multisite-Setup verstärkt diesen Punkt: Wer mehrere Instanzen absichern muss, braucht mehr Testzeit, nicht weniger.
Eigene Extensions früher auf Deprecations prüfen. Ein Durchlauf mit dem TYPO3 Extension Scanner zu Beginn des Projekts hätte geholfen, den Refactoring-Aufwand realistischer einzuschätzen.
Ist Ihre TYPO3 Website aktuell?
Sie betreiben eine TYPO3-Website und möchten wissen, was ein Update auf Version 13 konkret für Ihre Installation bedeutet?
Wir arbeiten seit über 15 Jahren mit TYPO3 und unterstützen Sie dabei, Ihr System technisch und redaktionell zukunftssicher aufzustellen – individuell, sicher und auf Augenhöhe.
Fazit: Schaffbar — wenn die Vorbereitung stimmt
Ein direkter Sprung von TYPO3 v11 auf v13 in einem produktiven Multisite-Projekt mit eigenen Extensions und ContentBlocks ist kein Spaziergang. Aber er ist machbar — wenn die Datenbankstrategie solide ist, die Testumgebung sauber aufgesetzt wurde und man bereit ist, Entscheidungen im Prozess zu treffen, die vorher nicht vollständig planbar waren.
Was dieses Projekt von einem theoretischen Upgrade-Guide unterscheidet: Es ist passiert, in einem echten Kundenkontext, mit echten Abhängigkeiten und echtem Zeitdruck. Die wichtigste Erkenntnis ist vielleicht, dass der Mut zum Direktsprung sich ausgezahlt hat — nicht trotz der Komplexität, sondern weil wir sie von Anfang an ernst genommen haben.
Wer ein ähnliches Upgrade vor sich hat und nicht das gesamte Risiko intern tragen möchte, kann solche Projekte auch als Teil unseres Webentwickler-Abos angehen — planbar, budgetiert und ohne einmaligen Großauftrag.
Das könnte Sie auch interessieren:
TYPO3 v13 LTS – Jetzt upgraden oder warten?
