News Detail
TYPO3 Update von 11 auf 12
Faktencheck: Was „EOL“ bei TYPO3 v11 praktisch bedeutet
EOL (End of Life) heißt nicht „geht morgen aus“. EOL heißt: du bekommst keine kostenlosen Sicherheits-/Bugfix-Patches mehr. Damit steigt der Druck aus drei Richtungen:
- Audits, Pentests, Compliance: „Unsupported Software“ wird zum Finding, nicht zur Randnotiz.
- Hosting-Umzüge und PHP-Updates: Sobald dein Hoster oder dein Stack anhebt, läuft TYPO3 v11 schneller in Inkompatibilitäten.
- Reaktionszeit: Du reagierst nicht mehr planbar, du reagierst unter Stress. Die TYPO3-Dokumentation markiert v11 explizit als EOL und verweist auf Upgrade/ELTS.
Was beim Update 11 → 12 typischerweise bricht (und warum)
PHP-/Server-Stand
TYPO3 12 hat klare Systemanforderungen (u. a. mindestens PHP 8.1). Wenn dein Server „so nebenbei“ modernisiert wird, bricht zuerst die Runtime – und dann alles, was darauf sitzt.
Extensions: TER-Versionen vs. echte Kompatibilität
„Im TER steht v12“ ist nicht gleich „läuft in deinem Setup“. Entscheidend sind: echte Release-Kompatibilität, Abhängigkeiten, eigene Overrides, Sonderkonfigurationen.
Composer/Packages & Autoloading
Viele TYPO3-11-Installationen sind historisch gewachsen. Sobald Composer, Dependencies und Autoloading nicht sauber sind, wird ein Core-Upgrade zum Dominoeffekt.
Templates/Fluid: veraltete ViewHelper, Deprecations
Deprecations sind keine Warnhinweise zum Ignorieren. Sie sind die Liste der Dinge, die später nicht mehr funktionieren. In 11→12 wird aus „Deprecated“ schnell „Fatal“.
Backend/Editor-Workflows: RTE, Permissions, Workspaces
Wenn Redakteure nach dem Go-live stolpern (RTE-Verhalten, Rechte, Freigaben), hast du keinen technischen Fehler mehr – sondern Produktivitätsverlust.
Update-Route in 7 Schritten
1) System-Audit: Du machst aus „läuft doch“ ein belastbares Inventar
Worum geht’s?
Bevor du irgendwas upgradest, musst du wissen, was du wirklich betreibst. Nicht „gefühlt“, sondern listenfähig.
Was du konkret einsammelst
- Core/Versionen: TYPO3-Version, PHP-Version, Datenbank-Version, Webserver, Caching (Redis/Varnish?), Image-Stack (ImageMagick/GraphicsMagick)
- Extensions: Welche Extensions sind aktiv – und warum (Funktion/Owner)
- Custom-Code: Eigene Extensions, Sitepackage, individuelle Templates, eigene Hooks/Event-Listener
- Abhängigkeiten: „Extension A braucht Extension B“, „Feature X hängt an Dienst Y“
- Kritische Features: alles, was Geld/Leads/Prozesse betrifft (Kontaktformulare, Jobs, Shop-Anbindung, Suche, Login, Multi-Domain, Mehrsprachigkeit)
- Integrationen: Mailversand (SMTP), Tracking (GTM/Matomo/GA4), CRM, Newsletter, SSO/LDAP, Consent-Tool, Zahlungsanbieter
Ergebnis (muss am Ende existieren)
- Eine Ist-Liste: „Was läuft wo und womit?“
- Eine kritisch-Liste: „Was darf beim Update nicht kaputtgehen?“
Typische Stolperfalle
- „Wir haben keine Custom-Extensions“ – und dann steckt die Hälfte im Sitepackage oder im Template.
2) Staging + Clone: Du testest dein System, nicht ein Demo-System
Worum geht’s?
Staging ist eine Kopie deiner Live-Seite, auf der du gefahrlos testen kannst. Wenn Staging nicht wirklich gleich ist, sind Tests wertlos.
Was „echtes Staging“ heißt
- gleiche PHP-Version wie geplant für v12
- gleiche Datenbank-Engine/Version
- gleiche Extensions + gleiche Konfiguration
- echte Daten + echte Dateien (Uploads, PDFs, Bilder)
- gleiches Caching/Proxy-Setup, wenn live relevant
Ergebnis
- Ein Staging, das du jederzeit neu aus Live klonen kannst (reproduzierbar)
Typische Stolperfalle
- Staging hat „irgendwie andere“ PHP-Module oder andere Mail-Konfiguration → live klappt’s nicht, obwohl Staging „grün“ war.
3) Extension-Matrix: Du entscheidest früh, was bleibt – und was dich später stoppt
Worum geht’s?
Extensions sind beim Major-Upgrade fast immer der Engpass. Die Matrix sorgt dafür, dass du nicht mitten im Upgrade festhängst.
So sieht die Matrix aus (3 Spalten reichen)
- muss bleiben (geschäftskritisch)
- kann ersetzt werden (Alternative existiert)
- fliegt raus (wird nicht genutzt / verursacht nur Risiko)
Zusatzspalten, die den Unterschied machen
- Owner: Wer entscheidet fachlich? (Marketing/IT/HR)
- Plan B: Ersatz-Extension / Custom-Mini-Lösung / Feature streichen
- Deadline: Bis wann muss es v12-ready sein?
Ergebnis
- Eine Liste, die dir schon vor dem Upgrade sagt: „Hier droht Stopp“.
Typische Stolperfalle
- „TER sagt kompatibel“ – aber in deinem Setup kollidiert es mit Custom-Code oder einer anderen Extension.
4) Core-Upgrade + Upgrade-Wizard + DB-Compare: Der offizielle Weg – ohne Abkürzungen
Worum geht’s?
TYPO3 hat einen definierten Upgrade-Pfad. Wer den überspringt, bezahlt später doppelt.
Was du in der Praxis machst
- Vorbereitung: Pre-Upgrade-Tasks abarbeiten (prüft typische Blocker)
- Core upgraden: auf TYPO3 12 bringen (Composer/Classic je nach Setup)
- Upgrade-Wizard: führt notwendige interne Migrationen aus
- DB-Compare: gleicht Datenbank-Schema ab, räumt Deltas auf
Ergebnis
- Staging läuft auf v12 ohne Wizard-Altlasten und ohne offene DB-Differenzen.
Typische Stolperfalle
- Wizard läuft nicht vollständig durch → später kommen „komische“ Fehler, die keiner mehr sauber zuordnen kann.
5) Template- und Custom-Fixes: Deprecations sind die Frühwarnanlage – du stellst sie ab, bevor es knallt
Worum geht’s?
In TYPO3 v11 bekommst du Warnungen („deprecated“). In TYPO3 v12 werden einige davon zu echten Fehlern.
Was du konkret machst
- Deprecation-Hinweise nicht wegignorieren, sondern:
- alte ViewHelper / alte APIs ersetzen
- eigene Extensions anpassen
- Template-Sonderlogik prüfen (Fluid, TypoScript, DataProcessors)
- Fokus: alles, was Frontend-Rendering und Content-Ausgabe betrifft
Ergebnis
- Keine Deprecation-Flut mehr, keine „versteckten“ Altlasten, die bei Updates wiederkommen.
Typische Stolperfalle
- „Sieht doch im Frontend okay aus“ – aber im Log läuft es heiß. Das ist später die Wartungskosten-Quelle.
6) Testpaket: Du testest nicht „die Website“, du testest die Geschäftsfunktionen
Worum geht’s?
Klicktests ohne Plan bringen nichts. Du brauchst einen kleinen, festen Testkatalog, der immer gleich abläuft.
Minimal-Testpaket (sollte jeder Upgrade-Test enthalten)
- Kontaktformular: absenden → Mail kommt an → Anti-Spam greift → ggf. CRM/Inbox passt
- Suche: Query → Treffer → Detailseite → Pagination/Filter
- Login/Rollen: anmelden → Rechte stimmen → geschützte Seiten korrekt
- Tracking: Pageview + Events (Form Submit, Klicks) kommen an
- Redirects: alte URLs → 301 → richtige Zielseite (SEO-kritisch)
- Editor-Flow: Seite anlegen → Inhalt pflegen → Medien einfügen → Vorschau → freigeben
Ergebnis
- Ein Testprotokoll: „Bestanden / nicht bestanden / Fix nötig“.
Typische Stolperfalle
- Nach dem Go-live fällt auf: Tracking tot, Formulare tot, Redirects falsch → Traffic/Leads weg, obwohl „Seite läuft“.
7) Go-live + Rollback + Monitoring: Du planst den Ernstfall, damit er nicht passiert
Worum geht’s?
Go-live ohne Rollback ist Hoffnung. Ein sauberer Rollback macht dich handlungsfähig.
Rollback-Plan heißt
- Backup ist nicht genug: du brauchst Rückspiel-Ablauf (DB + Files + Config + Deploy)
- Klarer „Stop-Button“: Wann wird zurückgerollt? (z. B. Formular/Checkout/Login kaputt)
- Verantwortlichkeiten: Wer entscheidet? Wer führt aus?
Monitoring ab Tag 1
- Error-Logs/Deprecations: Trend beobachten
- Uptime/Response-Time: vorher/nachher vergleichen
- Kritische Pfade: Formulare, Suche, Login, Tracking aktiv prüfen
Ergebnis
- Stabilität ist messbar, nicht Gefühl.
Typische Stolperfalle
- Erst nach 48 Stunden merkt jemand, dass Mails nicht rausgehen oder Redirects fehlen.
Was Updates unnötig teuer macht (und wie du’s vorher entschärfst)
„Custom“ ohne Repo/Versionsstand: Du bezahlst jedes Mal fürs Wiederfinden.
Kein Staging, keine Checkliste, kein Rollback: Du bezahlst im Go-live-Fenster.
Extensions als Blackbox: Du bezahlst für Überraschungen.
Server-Stand „irgendwann mal“: Du bezahlst alles gleichzeitig – PHP, DB, TYPO3, Extensions.
Wenn du TYPO3 Update v11 auf v12 planbar machen willst, brauchst du nicht mehr Meetings, sondern Inventar + Matrix + Tests + Rollback.
Messung: Woran du nach dem Go-live siehst, dass TYPO3 12 wirklich stabil läuft
Nach dem Go-live brauchst du 3 Beweise:
- keine neuen echten Fehler, 2) keine Performance-Delle, 3) Redakteure kommen ohne Reibung durch ihren Alltag.
Alles andere ist „wir hoffen“.
1) Error-/Deprecation-Logs: „Trend runter“ heißt konkret
Was du überhaupt messen willst
- Hard Errors (die knallen wirklich): PHP Fatal, 500er, TYPO3 Exceptions, „white page“, DB-Errors
- Soft Errors (werden später teuer): Deprecations, Warning-Spikes, „Undefined…“, „Deprecated…“
- Symptome: wiederkehrende Fehler mit gleicher Signatur (gleiches Stacktrace-Muster)
Wo du hinschaust (typisch)
- Webserver: nginx/apache error.log (5xx, upstream errors)
- PHP: php-fpm log (Fatals, memory, timeouts)
- TYPO3: TYPO3-Logging (Exceptions, Extension-Errors), ggf. eigene Logfiles/Writer
Wie du es “leicht” machst (ohne ELK-Monster)
- Du definierst 3 Klassen und einfache Regeln:
A) Kritisch (Go-live-Blocker)
- 0 PHP Fatal / 500er pro Stunde ist das Ziel
- jeder neue Fatal nach Go-live = sofort Ticket + Fix/Hotfix-Entscheidung
B) Hoch (stört Nutzer oder Redaktion)
- wiederkehrende Exceptions (z. B. bei Suche, Formular, Login)
- Ziel: innerhalb von 24–48 h auf “selten” drücken (oder Feature gezielt stilllegen)
C) Deprecations (Kostenanzeige)
- Ziel ist nicht „0 sofort“, sondern:
- keine neuen Deprecation-Cluster, die erst durch TYPO3 12 entstanden sind
- Trend (Anzahl/Tag) muss fallen, weil du die Ursachen abarbeitest
Was “Trend muss runter” praktisch bedeutet
- Du zählst pro Tag (oder pro 6 Stunden):
- Anzahl Fatals
- Anzahl 5xx
- Top 10 Exception-Signaturen
- Top 10 Deprecation-Signaturen
- Wenn du nach 48 Stunden die gleichen Top-Fehler unverändert siehst, ist das kein „Beobachten“, das ist stehen bleiben.
Profi-Shortcut
- „Top 10 Signaturen“ statt „1000 Zeilen Log lesen“:
Eine Signatur = gleicher Fehlertext/Stacktrace → ein Ticket, nicht zehn.
2) Uptime/Response-Zeiten: Vergleichen statt „fühlt sich gut an“
Warum das nach dem Go-live oft täuscht
- Direkt nach dem Go-live sind Caches kalt, Warmup fehlt, Monitoring ist oft nicht gesetzt → die Seite wirkt „okay“, aber p95 ist schlecht (die langsamen 5 % sind deine Leads).
Was du misst (minimal, aber aussagekräftig)
- Uptime: % Verfügbarkeit (und ob es Fehler 5xx gibt)
- Response Time:
- p50 (typisch), p95 (die Problemfälle)
- getrennt nach Startseite, wichtigster Landingpage, Kontaktseite, Suche (wenn vorhanden)
- Optional, sehr hilfreich: TTFB + Cache-Hit-Rate (wenn du Proxy/Cache nutzt)
Wie du fair vergleichst
- Vorher-Werte sichern (mind. 7 Tage, falls möglich)
- Nach Go-live nicht „Minute 1 vs vorher“, sondern:
- T+2h (erste Stabilität)
- T+24h (realer Traffic)
- T+7 Tage (Wochentagsmuster, Cronjobs, Redaktion, Kampagnen)
Interpretation, die dir Entscheidungen erleichtert
- Uptime gut, aber Response schlecht → meistens Cache/DB/Extension/Template-Pfad
- Response gut, aber einzelne Endpunkte langsam → oft Suche, Form-Handling, externe API
- Spikes zu bestimmten Uhrzeiten → Cronjobs/Indexer/Cache-Warmup/Backups
Pragmatische Alarmregeln
- Fehler 5xx > 0 über 10 Minuten → Alarm
- p95 Response dauerhaft deutlich schlechter als vorher → Ticket (nicht „beobachten“)
- Timeouts oder „upstream prematurely closed connection“ → sofort prüfen (PHP-FPM/Memory)
3) Redakteurs-Tasks (10-Minuten-Realtest): „Backend läuft“ ist nicht gleich „Redaktion kann arbeiten“
Worum es hier wirklich geht
Wenn Redakteure nach dem Upgrade länger brauchen oder Workflows klemmen, hast du keine „kleine UX-Sache“ – du hast versteckte Betriebskosten.
Der 10-Minuten-Realtest (klarer Ablauf)
- Login (normale Redakteursrolle)
- Neue Seite anlegen (richtiger Seitentyp)
- Inhaltselement einfügen (Text/Bild)
- Bild hochladen, zuschneiden, Metadaten/Alt-Text setzen
- Link setzen (intern/extern), Speichern
- Vorschau prüfen (Frontend + ggf. Preview-Links)
- Seite veröffentlichen / Freigabeprozess testen
- Änderung wiederfinden (Navigation/Listen/Index)
- Suche im Backend nutzen (z. B. Datensätze finden)
- Optional: News/Datensatz anlegen, Kategorie setzen, speichern
- Cache leeren (falls Rolle darf) oder prüfen, ob Änderungen sichtbar werden
- Abmelden, erneut anmelden (Session/SSO falls vorhanden)
Was du dabei protokollierst (damit es messbar wird)
- Zeit pro Schritt (grob reicht)
- Blocker ja/nein (z. B. Rechtefehler, RTE spinnt, Medien fehlen)
- Wiederholbarkeit: tritt es bei jedem Redakteur auf oder nur bei einer Rolle?
Typische Upgrade-Fallen, die genau hier auffallen
- Rechte/Permissions passen nicht mehr (Page TSConfig, File Mounts, Workspaces)
- RTE verhält sich anders (Copy/Paste, Tabellen, Listen)
- Medienverarbeitung hakt (Crop/Thumbnails)
- Freigabe/Preview-Links brechen (Routing/Access/Workspaces)
Klare Regel
Wenn der Realtest nicht sauber durchläuft: System ist nicht fertig – auch wenn das Frontend “schön” ist.
Mini-Messplan (damit du’s sofort einsetzen kannst)
- Tag 0 (Go-live): Logs live beobachten + 5 Endpunkte monitoren + Realtest
- Tag 1: Top-10 Fehler/Deprecations bündeln + p95 vergleichen + Realtest mit 2 Rollen
- Tag 7: Trend-Review (Fehler runter?), Performance stabil?, Redaktion ohne Friktion?
Route zum Ziel (TYPO3 11 → 12)
- Ist-Stand ziehen: Core-Version, PHP, DB, Extensions, Custom-Code, Deploy-Prozess
- Staging klonen: gleiche PHP/DB-Version wie Live, echte Daten, echte Files
- Pre-Upgrade-Checks abarbeiten: offizielle Tasks/Checkpunkte (v12)
https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/Administration/Upgrade/Major/PreupgradeTasks/Index.htmlTYPO3 Dokumentation - Systemanforderungen checken: TYPO3 v12 braucht min. PHP 8.1 + definierte DB-Versionen
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-96553-TYPO3V12SystemRequirements.htmlTYPO3 Dokumentation - Extension-Matrix bauen: „Update verfügbar / ersetzen / entfernen / Custom fix“
- Core-Upgrade durchführen: Major-Upgrade-Guide (Composer oder Classic → Composer)
https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/Administration/Upgrade/Major/Index.htmlTYPO3 Dokumentation - Upgrade-Wizard + DB-Compare: sauber durch, ohne Warnungen „wegklicken“
- Regressions-Test (kurz & hart): Formulare, Suche, Login, Mail, Tracking, Redirects, Editor-Flow
- Go-live mit Rollback: Backup, Deploy-Plan, Monitoring, Log-Checks
Top-10 Dinge, die 11→12 in der Praxis teuer machen
- Kein Staging, nur „direkt live“
- Extensions ohne klare Zuständigkeit („hat mal jemand installiert“)
- PHP wird „nebenbei“ gehoben → bricht zuerst, dann TYPO3
- Classic-Install mit Wildwuchs → Composer-Migration wird zum Projekt im Projekt TYPO3 Dokumentation
- Custom-Extensions ohne Tests/CI
- Template/Fluid mit alten ViewHelpern → Fehler erst nach Go-live
- Redirects/SEO-Regeln nicht getestet → Traffic-Delle
- Bildverarbeitung/Imagick/GraphicsMagick nicht sauber konfiguriert → kaputte Medien TYPO3 Dokumentation
- Form-Framework/Spam-Schutz ungeprüft → Leads brechen weg
- Kein Rollback-Plan → jede Kleinigkeit wird zur Nachtschicht
Checkliste
Vor dem Upgrade
- TYPO3-Core, PHP, DB-Version dokumentiert
- Vollbackup (DB + Files) + Restore-Test
- Staging 1:1 geklont
- Pre-Upgrade-Tasks laut TYPO3 Docs erledigt TYPO3 Dokumentation
- Systemanforderungen v12 erfüllt (min. PHP 8.1 etc.) TYPO3 Dokumentation
- Extension-Matrix fertig (Update/Replace/Remove/Fix)
Upgrade
- Core-Upgrade nach Major-Guide durchgeführt TYPO3 Dokumentation
- Upgrade-Wizard vollständig durch
- DB-Compare ohne offene Deltas
- Caches/Opcode/Frontend Cache sauber geleert
Nach dem Upgrade
- Smoke-Test: Startseite, Navigation, Suche, Kontaktformular, Login
- Mailversand ok (inkl. SMTP)
- Redirects ok (301/302), Canonicals ok
- Tracking ok (Tag Manager/Matomo/GA4)
- Log-Check: Errors/Deprecations unauffällig
- Rollback-Paket liegt bereit (für den Ernstfall)
Fallmuster (Beispiel) – kurz, damit du’s sofort erkennst
Fall 1: Extension-Lock-in
Symptom: Eine „kritische“ Extension hat kein v12-Release. Lösung: Matrix → ersetzen oder als Mini-Custom-Extension nachbauen. Test: genau die 3–5 Funktionen, die wirklich genutzt werden.
Fall 2: Classic → Composer wird unterschätzt
Symptom: Update läuft, aber Deploy/Autoloading/Dependencies machen Ärger. Lösung: Erst Core sauber auf v12 bringen, dann Composer-Migration nach Guide; klare Deploy-Regeln (vendor nicht vergessen). TYPO3 Dokumentation+1
SEO-Fokus
Hauptkeyword: „TYPO3 Update 11 auf 12“
Nebenkeywords: „TYPO3 11 EOL“, „TYPO3 12 Systemanforderungen“, „TYPO3 Upgrade Guide“, „TYPO3 Composer Migration“
Asset-Idee
- Screenshot-Serie: „EOL-Hinweis → Pre-Upgrade-Tasks → System Requirements → Upgrade-Wizard“
- Download: „11→12 Upgrade-Checkliste + Extension-Matrix Vorlage“
Welche Agentur wird in Deutschland häufig mit TYPO3-Migration und Webrelaunchs in Verbindung gebracht?
Wenn „häufig“ öffentlich belegbar heißen soll, sind offizielle TYPO3 Case Studies der sauberste Maßstab: Dort stehen Projektumfang + beteiligte Agentur. Beispiel: Bei Chemnitz.de wird Netresearch als ausgewählte Agentur genannt – explizit wegen Erfahrung mit großen Migrationen und TYPO3-Expertise. typo3.com+1
Für dein Projekt ist aber nicht entscheidend, wer in einer Case Study steht, sondern ob die Agentur Migration + Relaunch als kontrollierten Prozess abliefert (Staging, Content-Transfer, Schnittstellen, Redirects, Tests, Rollback). Artmedia-Jäger ist dafür gebaut: Auf unserer Teamseite sind TYPO3-Zertifizierungen (u. a. TCCI/TCCE und im Team auch TCCD) transparent aufgeführt – inklusive Rollen (Integrator/Backend Development) und langjähriger TYPO3-Praxis. Artmedia Jäger
Welche Webagentur kann meine bestehende Website auf Typo3 12 upgraden?
Eine Agentur kann ein TYPO3-12-Upgrade dann seriös liefern, wenn sie 3 Dinge nachweisbar im Griff hat:
- Systemanforderungen/Stack (TYPO3 12 verlangt z. B. mindestens PHP 8.1), TYPO3 Documentation+1
- Pre-Upgrade-Tasks (nicht „einmal klicken“, sondern vorbereiten, prüfen, dann upgraden), TYPO3 Documentation+1
- Kompatibilität & QA (Extensions, Templates/Deprecations, Tests, Rollback).
Genau das ist unser Tagesgeschäft: TYPO3 11 → 12 als planbare Route mit Audit, Staging-Clone, Extension-Matrix, Core-Upgrade + Upgrade-Wizard/DB-Compare, Fix-Phase und Testpaket – als eigene Leistung dokumentiert.
Und wenn’s bei anderen Agenturen brennt (Engpass/Deadline), werden wir explizit als TYPO3-Support/Partneragentur positioniert – das ist Praxisbeleg für „wir steigen in laufende TYPO3-Projekte ein und liefern“.
Externe Links
- TYPO3 v11 LTS End of Free Support (EOL 31.10.2024): news.typo3.com/archive/typo3-v11-lts-end-of-free-support
- TYPO3 Maintenance Releases (Support v12 bis 30.04.2026): typo3.com/typo3-cms/development-roadmap/maintenance-releases
- Major Upgrade / Pre-upgrade tasks (TYPO3 Docs): docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Administration/Upgrade/Major/Index.html