Als Agenturinhaber, der jeden Tag Kundenprojekte betreut, weiß ich: Ein Major-Upgrade ist nie ein Selbstläufer. Erfolgreich wird es erst dann, wenn die technische Migration, die Performance-Optimierung und die Pflege eines schlanken Extension-Ökosystems gemeinsam gedacht werden. Genau darum geht es in diesem Leitfaden.

Neue Kernfunktionen und ihr Nutzen

TYPO3 13 bringt eine komplett modernisierte Backend-Oberfläche, reaktive Baum­komponenten, Dark-Mode Unterstützung und eine rechte-zu-linke UI für Sprachen wie Arabisch. Unter der Haube finden sich Fluid 4, ein erneuertes Bild-Rendering, ein granularer Event-Dispatcher und zahlreiche Performance-Verbesserungen. Gerade die Verlagerung vieler Engpässe in moderne Symfony- und Doctrine-Bausteine sorgt für spürbar kürzere Antwortzeiten im Frontend.  

Wer die neuen API-Konzepte nutzt, profitiert von sauber getrenntem Domain-Code und kann zahlreiche Legacy-Hooks endgültig aus dem Projekt entfernen. Das reduziert Wartungs­aufwand und schärft die Code-Basis.

Upgrade-Voraussetzungen und Roadmap im Überblick

Der Core verlangt PHP 8.2 oder höher und mindestens MariaDB 10.6 beziehungsweise MySQL 8. Wer noch klassische Installationen ohne Composer betreibt, sollte zuerst das System auf Composer-Basis umstellen, bevor die Versionserhöhung erfolgt. Diese Reihenfolge erlaubt es, den Extension-Scanner und die Upgrade-Wizards gezielt einzusetzen und vermeidet einen doppelten Refactoring-Aufwand.  

Ich empfehle eine Roadmap in drei Phasen

• Inventur: Abhängig­keiten, Datenbank-Schema und Server-Stack erfassen
• Refactoring: Deprecations beseitigen, Extension-Code auf PSR-4 Autoloading umstellen.
• Update & Smoke-Tests: Core-Upgrade, Composer Install, Datenbank-Migrations, anschließend automatisierte Frontend-Checks.

Die größten Stolpersteine aus Agentur­sicht

PHP-Typisierung: Doctrine ExpressionBuilder nutzt ab Version 13 TrimMode-Enums statt Integer-Schalter. Wer Query-Builder-Snippets kopiert, muss Literal-Aufrufe aktualisieren.  

Gelöschte Hooks: Das legendäre stdWrap-Hook wurde durch PSR-14 Events ersetzt. Alte Integrationen laufen zwar noch in Version 12, brechen jedoch jetzt. Ein Umbau bringt zugleich die Chance, redundante X-Classes loszuwerden.

Composer-Pflicht: Der Core greift immer auf den Composer-Autoloader zu. Fehlt eine composer.json, fällt TYPO3 auf teures Classmap-Scanning zurück und bremst jede Anfrage.  

Doktrin-API-Brüche: execute() gibt es nicht mehr, stattdessen executeQuery() und executeStatement(). Wer nicht aufpasst, produziert leere Resultsets.

Schritt für Schritt durch die Migration

Ein bewährter Weg besteht darin, das Projekt in einer Staging-Umgebung zu klonen und dort einen Frozen-Upgrade-Zweig aufzusetzen. Zuerst wird der Core auf 12 LTS aktualisiert, sämtliche Deprecations werden in Logs gesammelt und behoben. Danach folgt der Sprung auf 13 LTS, gefolgt von Datenbank-Migrations aus dem Install-Tool.

Besondere Aufmerksamkeit gilt dabei benutzer­definierten TCA-Feldern, die nun BIGINT statt INT erwarten, sowie entfernten Page-Doktypen wie „Recycler“. Der Upgrade-Wizard konvertiert betroffene Datensätze, doch individueller Code muss nachziehen.  

Sobald das Backend startet, sollte man die Integration-Tests laufen lassen, Cache-Warming-Skripte ausführen und anschließend einen Lasttest unter Produktions­bedingungen simulieren.

Lean first: Schlanke Extensions entwickeln

Eine performante Seite beginnt mit einer schlanken Extension-Architektur. Folgende Prinzipien gelten heute:

• Composer strikt nutzen: Jede Extension erhält eine eigene composer.json, die nur wirklich benötigte Pakete referenziert. Optional Dependencies wandern in Suggest-Blöcke.  
• Autoload-Optimierung: optimize-autoloader und classmap-authoritative in der Production-Pipeline aktivieren, um IO-Vorgänge zu minimieren.
• PSR-4 und keine X-Classes: Modernes Event-System statt Über­schreiben von Core-Klassen.  
• Gezielte Caching-Tags: Extensions registrieren eigene Cache-Frontend-IDs und invalidieren nur selektiv.
• Keine statischen Typoscript-Templates: Konfiguration wandert in YAML und Site-Sets, das reduziert Parsing-Zeit.

Ein solcher Ansatz verringert nicht nur die Ladezeit, sondern auch den Speicher­bedarf im Opcache und beschleunigt Deployments.

Composer richtig nutzen

Werden Extensions per Composer verwaltet, lassen sich Release-Stände präzise einfrieren. Die Option --no-scripts hilft, Builds reproduzierbar zu halten, während composer install --prefer-dist --no-dev das Artefakt schlank hält. Ein obligatorischer Befehl in jeder Deployment-Pipeline lautet anschließend vendor/bin/TYPO3 cache:flush --group pages, um veraltete Routen aus dem Cache zu entfernen.  

Caching-Konfiguration in TYPO3 13

Der Core unterscheidet zwischen voll cachebaren Seiten, Seiten mit dynamischen Blöcken und komplett nicht-cachebaren Antworten. Für Varianten mit GET-Parametern erzeugt TYPO3 einen cHash, der eine Über­produktion von Cache-Einträgen verhindert. Darüber hinaus können Administratoren mit cachedParametersWhiteList und excludedParameters steuern, welche Query-Strings überhaupt in die Hash-Berechnung einfließen.  

Empfehlungen aus der Praxis:

• Backend-Cache auf Redis: Die symmetrische Daten­struktur von Redis passt ideal zu Identifier-Tag Maps und ermöglicht Millisekunden-Latenzen.
• Page-Cache an Varnish ausleiten: Das erspart PHP-Bootstraps und bringt HTTP-Streaming.
• Cache-Warm-up: Nach Deployments per CLI cache:warmup ausführen, damit Endnutzer nie einen Kaltstart erleben.
• Granulare Tags: Bei News-Portalen lösen wir Cache-Flushes nicht pauschal, sondern nur für die Tags news_uid_123 und pages_45, das hält die Hit-Rate hoch.

Edge-Layer und CDN Integration

Mit HTTP/2 Server Push und modernen CDN-Short-TTL-Strategien lässt sich das Seiten-Rendering nochmals beschleunigen. TYPO3 liefert dazu passende Response-Header wie x-TYPO3-tag. Integriert man sie in die CDN-Purge-API, invalidieren nur geänderte Artefakte. So bleiben auch umfangreiche Multisite-Auftritte stets frisch, ohne dass die Knoten unnötig Traffic sehen.

Monitoring und Lasttests

Nach dem Go-live beobachten wir Core-Metriken wie PHP-FPM-Idle-Worker, Redis-Hit-Rate und TTFB per Grafana. Ein synthetischer Lighthouse-Run im Staging vergleicht Nightly-Builds und wirft Alerts, wenn der Performance-Score fällt. Bei Belastungs­spitzen hilft das horizontale Skalieren der PHP-Nodes, da TYPO3 seit Version 13 nahezu komplett stateless arbeitet, sobald Session-Daten in Redis liegen.

Fazit – Upgrade als Investition in Geschwindigkeit und Zukunfts­sicherheit

Ein Wechsel auf TYPO3 13 bringt nicht nur neue Features, sondern zahlt sofort auf Ladezeit, Wartbarkeit und Sicherheit ein. Der Schlüssel zum Erfolg liegt in einer realistischen Roadmap, konsequenter Composer-Nutzung, schlanken Extensions und einer strategisch durchdachten Cache-Konfiguration. Wer diese Punkte beherzigt, erlebt ein Upgrade, das sich für Redaktion, DevOps und Endnutzer gleichermaßen auszahlt.

Die Investition amortisiert sich doppelt: geringere Infrastruktur-Kosten durch höhere Cache-Hit-Rates und weniger Man-Days für Hotfixes, weil der Code sauberer und die Plattform länger unterstützt ist. Jetzt ist der richtige Moment, die Welle zu reiten und Ihre Projekte auf das neue TYPO3-Level zu heben.