TYPO3 13.4 LTS auf 14.3 LTS upgraden: Der technische Migrationsleitfaden

Aufrufe

50 Aufrufe

Stand: 12. August 2026
Aktuelle TYPO3-13-Version: 13.4.34 LTS
Aktuelle TYPO3-14-Version: 14.3.6 LTS
Upgrade-Pfad: TYPO3 13.4 LTS → TYPO3 14.3 LTS
Schwerpunkt: Composer-basierte Installationen

Ein Major-Upgrade in TYPO3 ist selten schwierig, weil sich nur eine Versionsnummer ändert. Schwierig wird es dort, wo über Jahre eigene Extensions, Sitepackage-Code, TypoScript, Scheduler-Tasks oder externe Schnittstellen gewachsen sind. Genau deshalb sollte der Wechsel von TYPO3 13.4 LTS auf TYPO3 14.3 LTS nicht wie ein gewöhnliches Paketupdate behandelt werden.

TYPO3 14.3 ist aktuell die stabile LTS-Linie. Die derzeitige Version 14.3.6 wurde am 11. August 2026 veröffentlicht. TYPO3 13.4.34 ist gleichzeitig die aktuelle 13-LTS-Version und ebenfalls seit dem 11. August 2026 verfügbar. TYPO3 13 erhält kostenlose Security Updates bis Ende Dezember 2027; TYPO3 14 erhält kostenlose Bugfixes bis Dezember 2027 und Security Updates bis Ende Juni 2029. Die aktuellen Versionen und Supportzeiträume veröffentlicht TYPO3 unter get.typo3.org.

Für bestehende TYPO3-13-Projekte besteht damit kein akuter Zwang, innerhalb weniger Tage zu migrieren. Es gibt aber einen guten Grund, jetzt sauber zu planen: Wer Extensions, PHP, Composer-Abhängigkeiten und eigenes Sitepackage frühzeitig prüft, kann den Major-Wechsel kontrolliert vorbereiten, anstatt später unter Zeitdruck technische Altlasten zu beseitigen.

Einen allgemeinen Überblick zu Entwicklung, Update, Migration und laufender Betreuung finden Sie auf unserer Seite zur TYPO3 Agentur.

Der wichtigste Grundsatz: nicht mit composer update anfangen

Der problematischste Upgrade-Ablauf sieht in vielen Projekten ungefähr so aus: Versions-Constraints ändern, composer update ausführen und anschließend herausfinden, warum das System nicht mehr startet.

Technisch sauberer ist die umgekehrte Reihenfolge. Zuerst wird die bestehende Installation aufgeräumt und vermessen. Danach wird die Zielversion vorbereitet.

Ein belastbarer Ablauf sieht beispielsweise so aus:

TYPO3 13.4 aktualisieren → PHP und Infrastruktur prüfen → Upgrade Wizards ausführen → Deprecations analysieren → Extensions bewerten → Staging aufbauen → TYPO3 14.3 installieren → Datenbank migrieren → Custom Code anpassen → testen → deployen → überwachen

Der Vorteil ist banal, aber entscheidend: Fehler bleiben zuordenbar. Wenn PHP, Core, Extensions, Sitepackage und Deployment gleichzeitig verändert werden, ist ein einzelner Fehler später unnötig schwer einzugrenzen.

Die offizielle TYPO3-Dokumentation empfiehlt für Major-Upgrades ausdrücklich eine lokale oder separate Umgebung und warnt davor, die Composer-Schritte erstmals auf Produktion auszuführen. Der aktuelle Leitfaden dazu ist unter Upgrading to a major release using Composer dokumentiert.

Wie wir solche Projekte technisch strukturieren, beschreiben wir außerdem unter TYPO3 Update & Upgrade.

Zuerst TYPO3 13.4 auf den aktuellen Patchlevel bringen

Vor einem Major-Wechsel sollte die bestehende Installation nicht auf irgendeinem älteren 13.4-Patchstand verbleiben. Zum Zeitpunkt dieses Beitrags ist TYPO3 13.4.34 aktuell. Das Release vom 11. August 2026 kombiniert Bugfixes mit einem Security Update.

Der erste Schritt lautet deshalb: das bestehende 13.4-System innerhalb der eigenen Major-Linie aktualisieren, Caches und Datenbank prüfen und anschließend noch einmal vollständig testen.

Das hat einen praktischen Grund. Ein Fehler, der bereits auf einem veralteten 13.4-Patchlevel vorhanden ist, sollte nicht erst im TYPO3-14-Projekt untersucht werden. Je sauberer der Ausgangszustand, desto leichter lässt sich später zwischen Altproblem und echtem Breaking Change unterscheiden.

Die Release Notes zu 13.4.34 finden Sie unter TYPO3 13.4.34 Release Notes.

Systemanforderungen und PHP-Version prüfen

TYPO3 13.4 und 14.3 haben aktuell eine komfortable Überschneidung bei den Plattformanforderungen. Beide unterstützen PHP 8.2 bis 8.5. Für TYPO3 14 gelten außerdem unter anderem folgende Mindeststände:

Komponente	TYPO3 14
PHP	8.2, 8.3, 8.4, 8.5
MySQL	8.0.17+
MariaDB	10.4.3+
PostgreSQL	10.0+
SQLite	3.8.3+
Browser	moderne Browser

Vor Beginn lohnt sich eine kleine technische Bestandsaufnahme:

php -v
composer --version
mysql --version

Im Projekt selbst sind diese beiden Checks ebenfalls sinnvoll:

composer validate
composer outdated --direct

Nicht nur die Versionsnummern zählen. Prüfen Sie auch benötigte PHP-Extensions, Memory Limits, Datenbanktreiber, Image Processing, Webserver-Konfiguration und die PHP-Version, die tatsächlich im Web-Kontext läuft.

TYPO3 empfiehlt bei einem Major-Upgrade, zunächst die PHP-Version auf den höchsten Stand zu bringen, den die bestehende TYPO3-Version unterstützt. Danach wird das Projekt unter dieser PHP-Version getestet. Erst anschließend wird TYPO3 aktualisiert, während PHP zunächst unverändert bleibt. So lassen sich PHP-bedingte Probleme und TYPO3-bedingte Änderungen wesentlich sauberer trennen.

Staging braucht mehr als nur den Code

Ein Staging-System ist nur dann hilfreich, wenn es die relevanten Eigenschaften der Produktion abbildet.

Für ein realistisches Upgrade gehören dazu typischerweise:

composer.json und composer.lock
das eigene Sitepackage
private und Drittanbieter-Extensions
config/ beziehungsweise die Site Configuration
TypoScript und Routing
relevante Dateien aus fileadmin/
eine möglichst aktuelle Datenbankkopie
Scheduler-Konfiguration
notwendige Environment-Variablen
relevante externe Integrationen

Gerade die Datenbank ist wichtig. Viele Probleme entstehen nicht im Core, sondern in historisch gewachsenen Datensätzen, FlexForms, Scheduler-Einträgen oder Extension-Tabellen, die über mehrere Major-Versionen hinweg migriert wurden.

Produktive Secrets und API-Schlüssel sollten natürlich nicht unkontrolliert in eine Entwicklungsumgebung kopiert werden. Eine gute Staging-Umgebung ist produktionsnah, aber nicht sorglos dupliziert.

Backup heißt auch: Restore beherrschen

Vor dem Upgrade benötigen Sie mindestens ein wiederherstellbares Dateisystem beziehungsweise Release-Artefakt und ein Datenbankbackup.

Ein MySQL-Dump kann beispielsweise so erstellt werden:

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  database_name > typo3-before-v14.sql

Wichtiger als der Dump selbst ist die Frage, ob der Rückweg klar ist. Vor dem Livegang sollte deshalb beantwortet sein:

Wie wird das vorherige Release wieder aktiviert?
Wie wird die Datenbank zurückgespielt?
Wie lange dauert der Restore?
Was passiert mit Uploads während des Deployments?
Gibt es während des Wartungsfensters Schreibzugriffe?
Welche Upgrade Wizards verändern Daten dauerhaft?

Ein Code-Rollback ist nach einer Datenmigration nicht automatisch ein vollständiger Rollback. Wer diesen Unterschied erst im Fehlerfall bemerkt, hat bereits zu spät geplant.

Upgrade Wizards und Reference Index noch unter TYPO3 13 prüfen

Vor dem Core-Wechsel sollten offene Upgrade Wizards des bestehenden Systems abgearbeitet werden.

vendor/bin/typo3 upgrade:list

Alle aktuell fälligen Wizards können anschließend ausgeführt werden:

vendor/bin/typo3 upgrade:run

Ein einzelner Wizard lässt sich gezielt starten:

vendor/bin/typo3 upgrade:run wizardIdentifier

Auch der Reference Index gehört zur Vorbereitung:

vendor/bin/typo3 referenceindex:update

Die offizielle Dokumentation weist darauf hin, dass Upgrade Wizards vor jedem Major-Upgrade geprüft und nach dem Upgrade erneut kontrolliert werden sollten. Drittanbieter-Extensions können eigene Wizards mitbringen. Details finden Sie im TYPO3-Modul System > Upgrade.

Deprecations sind der eigentliche Frühwarnindikator

Eine Website, die unter TYPO3 13 noch funktioniert, ist nicht automatisch bereit für TYPO3 14.

Die interessantere Frage lautet: Welche APIs verwendet eigener Code, die in TYPO3 14 entfernt wurden?

Dafür sollten mehrere Quellen kombiniert werden:

Extension Scanner
Deprecation Logs
TYPO3 Core Changelog
Composer-Abhängigkeiten
statische Analyse
manuelles Review
funktionale Tests

Der Extension Scanner ist hilfreich, aber nicht allwissend. Dynamische Methodenaufrufe, Laufzeitdaten in Fluid oder sehr generische Methodennamen lassen sich nicht zuverlässig statisch erkennen.

Deshalb lohnt es sich, das TYPO3 14 Core Changelog nicht erst nach dem ersten Fehler zu öffnen, sondern bereits während der Vorbereitung.

Extensions zuerst auf Kompatibilität prüfen

In realen TYPO3-Projekten blockiert selten der Core selbst das Upgrade. Häufiger ist es eine Extension mit einem zu engen Constraint oder eine private Erweiterung, die seit Jahren nicht mehr angefasst wurde.

Prüfen Sie deshalb nicht nur TER-Pakete, sondern auch:

Composer-Packages
private Extensions
das Sitepackage
Formular-Erweiterungen
News- und Suchlösungen
SEO-Extensions
Authentifizierung
Scheduler Tasks
API-Connectoren
individuelle Backend-Module

Ein schneller Composer-Check ist:

composer why-not typo3/cms-core ^14.3

Wenn eine Erweiterung noch typo3/cms-core ^13 verlangt, ist die nächste Frage nicht sofort „Wie erzwinge ich Composer?“, sondern: Gibt es eine TYPO3-14-Version? Welche Breaking Changes bringt sie mit? Wird das Package noch gepflegt? Gibt es eine Alternative?

TYPO3 empfiehlt, Drittanbieter-Extensions zunächst auf die höchste Version zu aktualisieren, die noch mit der bestehenden TYPO3-Version kompatibel ist. So lässt sich besser erkennen, ob ein Problem von der Extension selbst oder vom Core-Wechsel stammt.

Wenn eigener Erweiterungscode angepasst werden muss, finden Sie unter TYPO3 Extension Entwicklung weitere Informationen. Ergänzend behandelt unser Beitrag TYPO3 Extension entwickeln lassen die Frage, wann individuelle Erweiterungen sinnvoll sind.

Composer-Upgrade: gezielt statt blind

Ist die Installation vorbereitet, können die TYPO3-Pakete auf die 14.3-Linie gesetzt werden.

Die TYPO3-Dokumentation zeigt beispielsweise:

composer require typo3/cms-backend:^14.3

In einem echten Projekt müssen jedoch alle installierten TYPO3-Core-Pakete konsistent aktualisiert werden. Dafür empfiehlt TYPO3 den Composer Helper, weil die Paketliste je nach Installation unterschiedlich ist.

Ein verkürztes Beispiel könnte so aussehen:

composer require \
  typo3/cms-core:^14.3 \
  typo3/cms-backend:^14.3 \
  typo3/cms-frontend:^14.3 \
  typo3/cms-extbase:^14.3 \
  typo3/cms-fluid:^14.3 \
  typo3/cms-seo:^14.3 \
  --update-with-all-dependencies

Diese Liste ist bewusst nur ein Beispiel. Sie sollte nicht ungeprüft kopiert werden.

Wenn Composer scheitert, analysieren Sie zuerst die Dependency-Kette:

composer why-not typo3/cms-core ^14.3
composer why vendor/package

composer.lock zu löschen, ist keine sinnvolle erste Reaktion auf einen normalen Versionskonflikt. Die offizielle Dokumentation erwähnt einen Neuaufbau von vendor/ und gegebenenfalls composer.lock nur für bestimmte hartnäckige Strukturprobleme. Das sollte bewusst und versioniert erfolgen, nicht als Reflex.

Fluid 5: kleine Typfehler werden plötzlich sichtbar

TYPO3 14 verwendet Fluid 5. Für viele Projekte ist das einer der Bereiche, in denen sich echte Laufzeitprobleme zeigen.

Fluid 5 validiert ViewHelper-Argumente strenger, behandelt null bei tag-basierten ViewHelpers anders und verlangt saubere Return Types in Custom ViewHelpers.

Ein älterer ViewHelper kann beispielsweise noch so aussehen:

public function initializeArguments()
{
    // ...
}

Unter Fluid 5 muss initializeArguments() einen void Return Type besitzen:

public function initializeArguments(): void
{
    // ...
}

Auch bei Templates lohnt sich genaueres Hinsehen. Ein Aufruf wie:

<f:link.page pageUid="{settings.detailPage}">
    Details
</f:link.page>

kann unter TYPO3 13 lange unauffällig geblieben sein, obwohl {settings.detailPage} in bestimmten Fällen einen unerwarteten Datentyp oder null liefert.

Die eigentliche Herausforderung liegt also nicht nur in Syntaxänderungen. Einige Fehler hängen von realen Laufzeitwerten ab und lassen sich deshalb nicht vollständig automatisch erkennen.

TYPO3 14 bringt dafür immerhin ein hilfreiches Werkzeug mit:

vendor/bin/typo3 fluid:analyze

Die Details zu den Änderungen sind im offiziellen Changelog unter Strict Types in Fluid ViewHelpers dokumentiert.

Extbase: PHP Attributes statt alter Annotations

Ältere Custom Extensions können noch klassische Extbase-Annotations verwenden.

Vorher:

use TYPO3\CMS\Extbase\Annotation as Extbase;

/**
 * @Extbase\Validate("NotEmpty")
 */
protected string $title = '';

Unter TYPO3 14 wird auf native PHP Attributes umgestellt:

use TYPO3\CMS\Extbase\Attribute as Extbase;

#[Extbase\Validate(['validator' => 'NotEmpty'])]
protected string $title = '';

Betroffen sind unter anderem Validate, Cascade und Lazy. Normale PHPDoc-Angaben wie @var oder @return bleiben davon unberührt.

Eine einfache Codesuche nach:

TYPO3\CMS\Extbase\Annotation

findet viele Kandidaten schnell.

Die Änderung und die vorgesehenen Migrationspfade beschreibt TYPO3 unter Removed support for annotations in Extbase.

TypoScript: getTSFE() endgültig entfernen

Ein typischer Legacy-Fall ist:

[getTSFE() && getTSFE().id == 42]

In TYPO3 14 wurde getTSFE() aus TypoScript Conditions entfernt. Die aktuelle Variante für die Page-ID lautet beispielsweise:

[request?.getPageArguments()?.getPageId() == 42]

Das Problem ist weniger spektakulär als ein Fatal Error und genau deshalb gefährlich: Eine Condition kann einfach nicht mehr greifen. Dann fehlt plötzlich ein Template, eine CSS-Datei oder eine Plugin-Konfiguration.

Eine projektweite Suche nach:

getTSFE(

gehört deshalb in jedes Upgrade-Review. Die offizielle Änderung ist unter TypoScript condition function getTSFE() removed beschrieben.

Alte Asset-Komprimierung gehört aus dem Sitepackage

TYPO3 14 entfernt die frühere Core-Funktionalität zum Zusammenführen und Vorab-Komprimieren von CSS und JavaScript.

Alte Konfigurationen wie:

config.compressCss = 1
config.compressJs = 1
config.concatenateCss = 1
config.concatenateJs = 1

sollten daher nicht weitergeführt werden.

Wer weiterhin Bundling oder Minifizierung benötigt, sollte das in eine moderne Build-Pipeline verlagern, etwa mit Vite oder Webpack. HTTP-Kompression gehört auf Webserver-, Proxy- oder CDN-Ebene.

TYPO3 erläutert die Hintergründe unter Removed frontend asset concatenation and compression.

Eigener Mail-Code: MailMessage->send() funktioniert nicht mehr

Custom Extensions mit eigenem Mailversand verdienen einen manuellen Check.

Code wie:

$message = new MailMessage();
$message->subject('Test');
$message->send();

ist unter TYPO3 14 nicht mehr gültig. MailMessage::send() und MailMessage::isSent() wurden entfernt. Der Versand erfolgt über MailerInterface.

Beispiel:

use TYPO3\CMS\Core\Mail\MailMessage;
use TYPO3\CMS\Core\Mail\MailerInterface;

final readonly class MailService
{
    public function __construct(
        private MailerInterface $mailer
    ) {
    }

    public function send(): void
    {
        $message = new MailMessage();
        $message->subject('Test');

        $this->mailer->send($message);
    }
}

Der Extension Scanner erkennt diesen Fall nicht zuverlässig, weil send() als Methodenname zu generisch ist. Genau deshalb sollten Kontaktformulare, Notifications, Scheduler Tasks, Imports, CLI Commands und eigene Workflows separat geprüft werden.

Details: MailMessage->send() removed.

Scheduler Tasks haben in TYPO3 14 einen eigenen Migrationsschritt

TYPO3 14 ändert das Speicherformat bestehender Scheduler Tasks. Wenn typo3/cms-scheduler installiert ist, muss der dafür vorgesehene Upgrade Wizard ausgeführt werden.

Wichtig ist ein Sonderfall: Bleibt der Wizard nach der Ausführung sichtbar, konnten möglicherweise einzelne Tasks nicht sauber migriert werden. In diesem Fall sollte tx_scheduler_task auf Einträge mit leerem tasktype geprüft werden; solche Tasks müssen gegebenenfalls manuell neu angelegt werden.

Nach der Migration reicht es nicht, nur im Backend nachzusehen, ob der Task noch existiert. Testen Sie auch:

Aktivstatus
nächste Ausführungszeit
Command
Dependencies
Environment-Variablen
Logging
tatsächliche Ausführung

Hilfreiche Befehle sind:

vendor/bin/typo3 scheduler:list
vendor/bin/typo3 scheduler:execute
vendor/bin/typo3 scheduler:run

Die TYPO3-14-spezifischen Hinweise finden Sie unter TYPO3 14: Upgrading the major version.

Datenbankschema: ergänzen zuerst, löschen später

Nach dem Composer-Upgrade muss das tatsächliche Datenbankschema mit den Definitionen aus Core und Extensions abgeglichen werden.

Im Backend steht dafür System > Maintenance > Analyze Database Structure zur Verfügung. Auf der CLI kann TYPO3 fehlende Tabellen und Spalten mit:

vendor/bin/typo3 extension:setup

einrichten.

Beim Löschen ist Zurückhaltung sinnvoll. TYPO3 weist ausdrücklich darauf hin, dass als obsolet erkannte Felder oder Tabellen noch von Upgrade Wizards beziehungsweise Drittanbieter-Extensions benötigt werden können.

Die Reihenfolge sollte deshalb sein:

Datenbank sichern.
Fehlende Tabellen und Felder ergänzen.
Upgrade Wizards ausführen.
Anwendung testen.
Obsolete Strukturen erneut prüfen.
Erst danach löschen.

Die offizielle Dokumentation dazu finden Sie unter Database compare during update and installation.

Nach dem Core-Wechsel erneut Upgrade Wizards ausführen

Sobald TYPO3 14 sauber bootet, beginnt die Prüfung erneut:

vendor/bin/typo3 upgrade:list
vendor/bin/typo3 upgrade:run
vendor/bin/typo3 referenceindex:update
vendor/bin/typo3 cache:flush

Wichtig ist, die ausgeführten Wizards zu dokumentieren. Bei produktiven Systemen sollte nachvollziehbar bleiben, welche Datenmigration wann durchgeführt wurde.

Das Sitepackage ist in vielen Projekten die eigentliche Upgrade-Arbeit

Bei einem individuell entwickelten TYPO3-Projekt steckt der meiste Aufwand häufig im eigenen Sitepackage und nicht im Core.

Unter PHP sollten Sie insbesondere Controller, Repositories, DataProcessors, Event Listener, ViewHelpers, Middleware, Services, Scheduler Tasks, CLI Commands, alte Hooks und PSR-14 Events prüfen.

In der Konfiguration sind TCA, TypoScript, Page TSconfig, Site Sets, Routing, Services.yaml und config/sites/ typische Kandidaten.

Im Frontend gehören Fluid Templates, Partials, Layouts, Custom Content Elements, Formulare, responsive Bilder, JavaScript, CSS/SCSS und die Asset-Pipeline auf die Testliste.

Das klingt umfangreich, ist aber wesentlich effizienter als ein unsystematisches „durchklicken“, nachdem der Core bereits aktualisiert wurde.

Funktionale Tests müssen reale Nutzung abbilden

Ein erfolgreiches Backend-Login ist noch kein erfolgreiches Upgrade.

Prüfen Sie im Frontend mindestens:

Homepage
Standard-Inhaltsseiten
Landingpages
News-Liste und Detailseiten
Suche
Formulare
404-Seite
Sprachversionen
geschützte Bereiche

Bei Content Elements sind insbesondere Text, Text & Media, Bilder, Cropping, Downloads, interne und externe Links sowie eigene Content Elements relevant.

Im Backend sollten Page Module, Filelist, RTE, Content Editing, Benutzerrechte, Workspaces, Scheduler und eigene Backend-Module getestet werden.

Der entscheidende Punkt: Verwenden Sie reale Inhalte. Viele Fluid- oder Datenprobleme treten erst mit bestimmten Datensätzen auf.

Externe Integrationen separat behandeln

CRM, ERP, PIM, Newsletter, SSO, OAuth, LDAP, REST APIs, Payment, Consent Management, externe Suche, Importe und Exporte gehören nicht einfach in einen allgemeinen Smoke-Test.

Testen Sie für geschäftskritische Integrationen auch Fehlerfälle:

Timeout
HTTP 4xx
HTTP 5xx
ungültige Daten
Authentifizierungsfehler
Rate Limits
fehlende Environment-Variablen

Gerade Integrationen können nach einem Core-Upgrade scheinbar unauffällig bleiben, bis der erste nächtliche Import oder der erste echte Nutzerprozess scheitert.

SEO-Regressionen vor und nach dem Upgrade vergleichen

Auch ein Upgrade ohne Relaunch kann SEO-relevante Änderungen verursachen. Ein verändertes Template, eine neue Extension-Version oder eine nicht mehr greifende TypoScript Condition reicht aus, um Canonicals, Meta-Daten oder strukturierte Daten zu verändern.

Deshalb sollte vor dem Upgrade ein Crawl wichtiger URLs gespeichert und nach dem Upgrade wiederholt werden.

Vergleichen Sie mindestens:

Prüfwert	Vorher	Nachher
HTTP Status	200	200
SEO Title	korrekt	korrekt
Canonical	korrekt	korrekt
Robots	index	index
H1	vorhanden	vorhanden
Hreflang	korrekt	korrekt
XML Sitemap	korrekt	korrekt
Structured Data	vorhanden	vorhanden

Zusätzlich sollten Redirects, Slugs, interne Links und Open-Graph-Daten geprüft werden.

Diese Art von Vorher-Nachher-Test entdeckt stille Regressionen, die im Browser kaum auffallen, aber für Suchmaschinen relevant sind.

Wann ein Upgrade besser als Migration geplant wird

Nicht jede TYPO3-13-Installation sollte technisch unverändert bis TYPO3 14 weitergetragen werden.

Eine TYPO3 Migration kann wirtschaftlicher sein, wenn das Sitepackage grundlegend veraltet ist, zentrale Extensions nicht mehr gepflegt werden, das Content-Modell ohnehin neu aufgebaut werden soll oder Hosting und Deployment komplett modernisiert werden.

Dass TYPO3 13 noch unterstützt wird, schafft dafür einen guten Entscheidungszeitraum. Sie müssen nicht hektisch migrieren, sollten aber auch nicht warten, bis Supportfristen und technische Altlasten gleichzeitig Druck erzeugen.

Unser Beitrag TYPO3 Update planen behandelt die strategische Abgrenzung zwischen Update, Migration und Relaunch ausführlicher.

Deployment reproduzierbar halten

Ein Major-Upgrade sollte auf Produktion nicht mit einem spontanen composer update beginnen.

Ein sauberer Deployment-Prozess sieht eher so aus:

Git Release → CI Build → Composer Install → Frontend Build → Staging → Freigabe → Produktion → Datenbankmigration → Upgrade Wizards → Cache → Health Checks

Auf Produktion wird derselbe composer.lock verwendet, der zuvor getestet wurde.

Typischerweise:

composer install --no-dev --optimize-autoloader

statt:

composer update

Die getesteten Dependencies bleiben damit reproduzierbar. TYPO3 beschreibt CI/CD für Projekte auch in der offiziellen Dokumentation zu Automatic deployment for TYPO3 Projects.

Rollback ist Teil des Deployments, nicht Plan B

Vor dem Go-live muss klar sein, wie ein fehlgeschlagenes Release zurückgenommen wird.

Dazu können gehören:

vorheriges Git Release
vorheriger composer.lock
vorheriger Vendor-Build
Frontend Assets
Datenbank-Snapshot
Datei-Snapshot
Uploads
Environment-Konfiguration

Besonders kritisch ist die Datenbank. Wenn Upgrade Wizards bereits Daten transformiert haben, kann es unzureichend sein, nur den alten Code wieder zu aktivieren.

Rollback bedeutet deshalb immer: Code und Daten gemeinsam betrachten.

Nach dem Livegang beginnt die Beobachtungsphase

Nach dem Deployment sollten TYPO3 Logs, PHP- und Webserver-Fehler, Scheduler, Mailversand, Formulare, APIs, 404-Entwicklung, Antwortzeiten, Cache-Verhalten, Suche und Login-Prozesse beobachtet werden.

Bei wichtigen Systemen lohnt es sich, dieses Monitoring nicht nur für den Upgrade-Tag einzurichten, sondern als festen Bestandteil des Betriebs zu etablieren.

Weitere Informationen dazu finden Sie unter TYPO3 Support & Wartung.

Kompakte Checkliste für TYPO3 13.4 → 14.3

Vor dem Upgrade

TYPO3 13.4 auf aktuellen Patchlevel gebracht
PHP- und Datenbankversion geprüft
Composer validiert
Backup und Restore getestet
Staging mit realistischen Daten aufgebaut
Upgrade Wizards unter TYPO3 13 geprüft
Reference Index aktualisiert
Deprecations und Extension Scanner ausgewertet
Drittanbieter- und private Extensions geprüft
Sitepackage analysiert
Scheduler Tasks inventarisiert
externe Integrationen dokumentiert
SEO-Baseline erstellt
Rollback vorbereitet

Während des Upgrades

TYPO3-Pakete auf ^14.3 aktualisiert
Composer-Konflikte nachvollziehbar gelöst
TYPO3 14 erfolgreich gebootet
Datenbankschema ergänzt
Upgrade Wizards ausgeführt
Scheduler migriert
Fluid 5 geprüft
Extbase Annotations migriert
TypoScript angepasst
Mail-Code geprüft