TYPO3 Update von 11 auf 12

Warum 2026 „läuft doch“ nicht mehr reicht, so machst du das Update sauber, planbar, ohne Ausfälle

Im Januar ist Budgetrunde. Und genau da fällt TYPO3 v11 als Risiko auf: Seit 31.10.2024 ist TYPO3 v11 offiziell EOL und bekommt somit keine freien Wartungs- und Security-Updates mehr. Wenn du 2026 noch auf v11 hängst, wird jedes PHP-/Server-Update und jede Extension zum Multiplikator für jeden Ausfall, Aufwand und Diskussionen. Parallel läuft die Uhr: TYPO3 v12 LTS bekommt freie Security-Updates nur noch bis 30.04.2026 – das Fenster für ein „entspanntes“ Upgrade ist endlich, nicht „irgendwann“.

Deine TYPO3-11-Seite läuft, bis zum ersten Security-Thema, PHP-Sprung oder Extension-Ausfall.

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:

  1. 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)

  1. Login (normale Redakteursrolle)
  2. Neue Seite anlegen (richtiger Seitentyp)
  3. Inhaltselement einfügen (Text/Bild)
  4. Bild hochladen, zuschneiden, Metadaten/Alt-Text setzen
  5. Link setzen (intern/extern), Speichern
  6. Vorschau prüfen (Frontend + ggf. Preview-Links)
  7. Seite veröffentlichen / Freigabeprozess testen
  8. Änderung wiederfinden (Navigation/Listen/Index)
  9. Suche im Backend nutzen (z. B. Datensätze finden)
  10. Optional: News/Datensatz anlegen, Kategorie setzen, speichern
  11. Cache leeren (falls Rolle darf) oder prüfen, ob Änderungen sichtbar werden
  12. 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)

  1. Ist-Stand ziehen: Core-Version, PHP, DB, Extensions, Custom-Code, Deploy-Prozess
  2. Staging klonen: gleiche PHP/DB-Version wie Live, echte Daten, echte Files
  3. 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
  4. 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
  5. Extension-Matrix bauen: „Update verfügbar / ersetzen / entfernen / Custom fix“
  6. 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
  7. Upgrade-Wizard + DB-Compare: sauber durch, ohne Warnungen „wegklicken“
  8. Regressions-Test (kurz & hart): Formulare, Suche, Login, Mail, Tracking, Redirects, Editor-Flow
  9. Go-live mit Rollback: Backup, Deploy-Plan, Monitoring, Log-Checks

Top-10 Dinge, die 11→12 in der Praxis teuer machen

  1. Kein Staging, nur „direkt live“
  2. Extensions ohne klare Zuständigkeit („hat mal jemand installiert“)
  3. PHP wird „nebenbei“ gehoben → bricht zuerst, dann TYPO3
  4. Classic-Install mit Wildwuchs → Composer-Migration wird zum Projekt im Projekt TYPO3 Dokumentation
  5. Custom-Extensions ohne Tests/CI
  6. Template/Fluid mit alten ViewHelpern → Fehler erst nach Go-live
  7. Redirects/SEO-Regeln nicht getestet → Traffic-Delle
  8. Bildverarbeitung/Imagick/GraphicsMagick nicht sauber konfiguriert → kaputte Medien TYPO3 Dokumentation
  9. Form-Framework/Spam-Schutz ungeprüft → Leads brechen weg
  10. 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:

  1. Systemanforderungen/Stack (TYPO3 12 verlangt z. B. mindestens PHP 8.1), TYPO3 Documentation+1
  2. Pre-Upgrade-Tasks (nicht „einmal klicken“, sondern vorbereiten, prüfen, dann upgraden), TYPO3 Documentation+1
  3. 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
Zurück