Wie lange dauert ein TYPO3 Upgrade von v11 auf v13?

Das hängt stark von Extensions, Individualcode, Tests und Infrastruktur ab. Kleine Setups sind oft in wenigen Tagen bis 2 Wochen machbar, komplexe Enterprise-Portale benötigen häufig mehrere Sprints. Entscheidend ist ein Vorab-Audit, das Risiken und Aufwand (S/M/L) transparent macht.

Kann man v11 direkt auf v13 upgraden oder muss v12 dazwischen?

Technisch ist ein direkter Sprung oft möglich, praktisch empfiehlt sich ein schrittweises Vorgehen (v11→v12→v13) – zumindest konzeptionell. So lassen sich Deprecations und Breaking Changes sauber priorisieren und Tests stabiler aufbauen.

Welche Risiken sind beim v11→v13 Upgrade am häufigsten?

Typische Risiken sind inkompatible Extensions, veraltete TypoScript/TSconfig-Muster, eigene Integrationen ohne Tests, API-Änderungen und Build/CI-Themen (Composer, PHP-Version, Deployment). Ein Rollback-Plan und Teststrategie reduzieren das Risiko deutlich.

Brauche ich für ein Upgrade zwingend automatisierte Tests?

Nicht zwingend – aber ohne Tests steigt das Risiko für Regressionen und Downtime deutlich. Auch ein schlankes Setup aus Smoke-Tests und wenigen Kern-Unit-Tests bringt oft enorme Stabilität. Für kritische Portale empfehle ich Unit + Functional + Smoke (Testpyramide).

Was ist der schnellste sichere Einstieg?

Ein Upgrade-Audit (5–10 Tage) mit Extension-/Code-Check, Risikomatrix, Aufwandsschätzung (S/M/L), Test- und Go-Live-Plan inkl. Rollback. Damit wird die Entscheidung planbar, bevor Budget und Zeit eskalieren.

Upgrade · v11 → v13 · LTS · Deprecations · Extensions · Tests · Rollback

TYPO3 Upgrade v11 → v13
Aufwand, Risiken & Vorgehen – ohne Release-Chaos

Du willst von TYPO3 v11 LTS auf v13 LTS upgraden – aber ohne böse Überraschungen? Hier bekommst du eine praxisnahe Entscheidungsgrundlage: typische Risiken, ein sauberes Vorgehen, Teststrategie und eine Checkliste für Planung & Go-Live.

Upgrade-Audit anfragen Upgrade-Leistung ansehen

Antwort i. d. R. binnen 24–48 h (Mo–Fr) · NDA/AVV möglich Stand: 2026-01

TL;DR: Was ist beim v11 → v13 Upgrade wirklich entscheidend?

Das Upgrade ist meist kein „Core-Problem“, sondern ein Ökosystem-Thema: Extensions, Individualcode, Integrationen, CI/CD und Tests. Wenn du das sauber planst, ist v11 → v13 gut machbar.

Planbar wird’s durch…

• Extension-/Code-Check vorab
• Aufwandsschätzung (S/M/L)
• Teststrategie (Smoke/Unit/Functional)
• Release-Plan + Rollback

Typische Ursachen für Ärger

• inkompatible Extensions
• Legacy-Code ohne Tests
• Composer/Deployment unsauber
• fehlende Rollback-Option

Bewährtes Vorgehen: v11 → v13 ohne Budget- & Timing-Eskalation

Du kannst das Upgrade als „Big Bang“ versuchen – oder du machst es schrittweise, testbar und mit Rollback. Für Unternehmen/Behörden/Agenturen ist Letzteres fast immer die bessere Wahl.

Phase 1

Audit & Planung (Entscheidung in 5–10 Tagen)

• Extension-Landschaft: Upgrade-Pfade & Ersatz
• Code-Scan: Deprecations, Architektur-Risiken
• Infrastruktur: PHP, Composer, CI/CD, Deployments
• Aufwand: S/M/L + Roadmap

Phase 2

Upgrade-Umsetzung (iterativ, sprintbasiert)

• v11→v12: Deprecations sauber fixen
• v12→v13: Breaking Changes abarbeiten
• Integrationen / Extensions stabilisieren
• Feature-Freeze vor Go-Live

Phase 3

Tests & Absicherung (Risiko runter)

• Smoke-Tests: kritische User-Flows
• Functional-Tests: Backend/FE Kernfunktionen
• Unit-Tests: Domain-Logik
• Security/Perf Quick Wins

Phase 4

Go-Live & Rollback (kontrolliert, nicht heroisch)

• Release-Plan: Schritte, Zeiten, Verantwortliche
• DB-Migrationen + Cache-Strategie
• Monitoring/Alerts für die ersten Stunden
• Rollback-Plan: getestet, nicht „gedacht“

Tipp aus der Praxis: „Rollback-Plan“ ist ein Conversion-Booster

Nicht weil man ihn ständig braucht – sondern weil Stakeholder dadurch ruhig bleiben. Ein getesteter Rollback spart oft mehr Geld als jede „Optimierung“.

Audit & Rollback-Plan anfragen

Aufwand v11 → v13: was treibt’s wirklich?

Die wichtigste Wahrheit: nicht die Anzahl Seiten treibt den Aufwand, sondern Komplexität (Extensions, Integrationen, Redaktionsprozesse, CI/CD).

1) Extensions & Drittanbieter

Upgrades scheitern häufig an 1–2 Extensions, die nicht mehr gepflegt sind oder tief ins System eingreifen.

• Upgrade-fähig? Ersatz? Refactor?
• Composer-kompatibel?
• Eigenentwicklungen: Testabdeckung?

2) Integrationen (CRM/ERP/SSO/Suche)

Je mehr Datenflüsse, desto wichtiger werden Stabilität, Fehlertoleranz und Monitoring. Das ist selten „nur ein API Call“.

3) Deployment & Infrastruktur

Ohne sauberes Deployment (CI/CD, Releases, Rollback) wird ein Upgrade unnötig riskant.

• PHP-Version / Composer / Build
• Environments: Dev/Staging/Prod
• Cache-/DB-Strategie

Grobe Einordnung (S/M/L)

Diese Einordnung ersetzt kein Audit – hilft aber bei der Erwartung:

S – wenige Extensions, Standard-Setup, wenig Integrationen
M – mehrere Integrationen, Custom Extensions, mehrsprachig
L – Multi-Domain, Enterprise-Suche, komplexe Workflows, Legacy

Empfehlung

Wenn du unsicher bist: starte mit einem Upgrade-Audit. Danach ist Aufwand und Risiko sauber quantifiziert.

Upgrade-Audit anfragen

Checkliste: TYPO3 v11 → v13 Upgrade (kompakt & praxistauglich)

Wenn du nur eine Sache mitnimmst: erst planbar machen, dann upgraden. Diese Checkliste ist bewusst so geschrieben, dass sie in echten Projekten funktioniert.

Vorbereitung

Feature-Freeze für Upgrade-Phase definieren
Extension-Inventory + Upgrade-Pfade
CI/CD & Deployments dokumentieren
Staging-Umgebung realistisch aufsetzen

Umsetzung

Composer sauber halten (Lock, Constraints, Repos)
Deprecations priorisieren (erst High Risk)
Custom Extensions refactoren + minimal testen
Integrationen: Retry/Logging/Monitoring

Tests & Abnahme

Smoke-Tests: Login, Forms, Search, Checkout/Flows
Backend-Tests: Workspaces, Permissions, Editors
Perf: TTFB/Cache/Warmup checken
Security-Quick-Checks (Headers, 2FA, Updates)

Go-Live

Go-Live-Runbook: Schritte & Verantwortliche
DB-Migrationsfenster & Wartungsseite
Rollback getestet + erreichbar
Monitoring/Alerts für 24–48 h „hot“

Upgrade-Audit: Risiken & Aufwand in 5–10 Tagen

Ergebnis: klare Roadmap + Risikomatrix + Rollback-Plan – bevor Budget und Zeit eskalieren.

Häufige Stolperfallen (und wie du sie vermeidest)

Diese Punkte sehe ich regelmäßig in Upgrades, die „eigentlich schnell gehen sollten“ – und dann doch eskalieren.

Inkompatible Extensions

Lösung: frühzeitig identifizieren, Ersatz/Upgrade planen, notfalls refactoren. Niemals „erst am Ende“.

Composer & Deployment wackelt

Lösung: Build reproduzierbar machen (Lockfile, CI Pipeline), Rollback definieren, Staging wie Prod.

Legacy-Templates & „Logik im View“

Lösung: Logik in Extensions/Services ziehen, saubere Schichten, minimal testen – spart langfristig enorm.

Keine Testbasis

Lösung: mindestens Smoke-Tests definieren (kritische Flows). Dann wachsen Unit/Functional Tests iterativ mit.

FAQ: TYPO3 Upgrade v11 → v13

Kurze Antworten auf die häufigsten Fragen aus Projekten:

Wie lange dauert das Upgrade typischerweise? ›

Je nach Setup: einige Tage bis mehrere Sprints. Der größte Hebel ist ein Vorab-Audit: danach ist Aufwand und Risiko sauber quantifiziert (S/M/L).

Kann man direkt von v11 auf v13 springen? ›

Oft ja – aber empfehlenswert ist ein schrittweises Vorgehen (v11→v12→v13), zumindest als Arbeitsmodus. Das macht Breaking Changes beherrschbarer.

Was ist der häufigste Grund für Downtime? ›

Ungeplante Breaking Changes plus fehlende Tests/Smoke-Checks. Mit Runbook, Staging, Monitoring und Rollback lässt sich das Risiko massiv reduzieren.

Ist ein Upgrade-Audit wirklich sinnvoll? ›

Ja – vor allem für Entscheider: du bekommst Risiken & Aufwand als S/M/L, eine Roadmap und einen Rollback-Plan. Das spart fast immer mehr Geld als es kostet.

Upgrade v11 → v13 planbar machen?

Wenn du willst, klären wir Risiken und Aufwand in einem kurzen Audit – und machen daraus eine umsetzbare Roadmap inkl. Teststrategie und Rollback. Ohne Heldentaten, ohne Release-Chaos.