Warum TYPO3-Projekte überhaupt zur Ablösung kommen
TYPO3 ist selten das Problem an sich. Meistens war es vor Jahren eine solide Wahl, und das System ist seitdem gewachsen, ohne dass jemand es konsequent gepflegt hat. Extensions wurden von verschiedenen Dienstleistern über die Jahre nachgerüstet, teils ohne Dokumentation, teils gegeneinander inkompatibel bei größeren Versionssprüngen. Irgendwann bleibt ein Update aus, weil niemand mehr genau weiß, welche Extension davon betroffen wäre, und ab dem Punkt läuft das System auf einer Version, für die kaum noch aktiv Support existiert.
Der zweite häufige Fall ist ein starres Datenmodell. TYPO3s Seitenbaum und Content-Elemente sind für klassische Redaktionsseiten gebaut. Sobald ein Projekt zusätzlich eine Anwendung braucht, etwa einen Konfigurator, ein Kundenportal oder Inhalte, die auch außerhalb der eigenen Website ausgespielt werden sollen, stößt dieses Modell an seine Grenzen. Nicht, weil TYPO3 das grundsätzlich nicht könnte, sondern weil es dafür nicht entworfen wurde und jede Erweiterung in diese Richtung zusätzliche Extensions und zusätzliche Komplexität bedeutet.
Der dritte Grund ist der Personenwechsel. Wenn die Person, die das TYPO3-Setup ursprünglich aufgebaut hat, das Unternehmen oder die Agentur verlässt, bleibt oft ein System zurück, das niemand mehr vollständig versteht. Genau in dieser Situation entsteht das eigentliche Risiko einer Ablösung.
Was ein Redaktions-Blackout ist und wie er entsteht
Ein Redaktions-Blackout ist der Zeitraum, in dem die Redaktion nicht mehr veröffentlichen kann, weil das alte System schon abgeschaltet, das neue aber noch nicht redaktionsfähig ist. Das ist der Fall, den fast alle Systemvergleiche zwischen TYPO3-Alternativen übergehen, weil sie nur die Zielsysteme gegenüberstellen und den Weg dorthin ausblenden. Für die Redaktion selbst ist genau dieser Weg die eigentliche Frage.
Ein Blackout entsteht fast immer durch dieselbe Reihenfolge: Das Projekt plant einen einzigen Umschalttermin, an dem TYPO3 abgeschaltet und das neue System live geschaltet wird. Bis zu diesem Termin arbeitet die Redaktion normal in TYPO3 weiter, das neue System wird parallel dazu von der Entwicklung gebaut, aber niemand aus der Redaktion arbeitet vorher darin. Am Stichtag selbst muss dann alles gleichzeitig funktionieren: die Datenmigration, die neue Struktur, die Rechte der einzelnen Redakteure, die Vorschau, der Freigabeprozess. Wenn an diesem Tag etwas nicht passt, kann die Redaktion tagelang nicht veröffentlichen, weil das alte System schon weg und das neue System noch nicht eingespielt ist.
Der Weg, der dieses Risiko vermeidet, ist derselbe wie bei jeder Ablösung eines gewachsenen Systems: Alt- und Neusystem laufen parallel, bis das neue System denselben Stand zeigt wie das alte, und die Redaktion arbeitet im neuen System, bevor TYPO3 abgeschaltet wird, nicht erst danach.
Inhalte und Struktur migrieren
Der erste Schritt ist eine ehrliche Bestandsaufnahme dessen, was in TYPO3 tatsächlich vorhanden ist, nicht nur, was in der Dokumentation steht. Content-Elemente, Seitenbaum-Struktur und die tatsächlich genutzten Extensions werden einzeln durchgegangen. Ein Teil davon bildet reine Inhaltsstruktur ab, etwa Textblöcke, Bildergalerien oder Teaser, und lässt sich direkt in ein neues Content-Modell überführen. Ein anderer Teil kapselt Geschäftslogik, zum Beispiel eine Formularverarbeitung mit eigener Zustellungslogik oder eine Extension, die Daten aus einem angebundenen System zieht. Diese Teile werden nicht als Plugin nachgebaut, sondern als regulärer Anwendungscode im neuen System, versioniert und getestet wie der Rest der Anwendung.
Danach wird der bestehende Inhalt tatsächlich übernommen, nicht neu abgetippt. Die Inhalte werden aus TYPO3 exportiert und im neuen Content-Modell abgebildet, sodass jede Seite, jeder Text und jedes Bild seinen Platz im neuen System hat, bevor irgendetwas umgeschaltet wird. Erst wenn beide Systeme dieselben Inhalte zeigen, folgt der nächste Schritt.
URLs und SEO erhalten
Ein Systemwechsel muss keine Rankings kosten, aber genau hier passieren die häufigsten Fehler. TYPO3-URLs folgen oft einem eigenen Schema, abhängig davon, wie der Seitenbaum und die Routing-Konfiguration über die Jahre gewachsen sind. Wenn diese URLs sich beim Wechsel ändern, ohne dass jede alte Adresse auf die passende neue weiterleitet, verliert die Seite die Signale, die sich über Jahre aufgebaut haben, und Suchmaschinen müssen die Seite praktisch neu bewerten.
Deshalb steht die URL-Struktur vor der Migration fest, nicht danach. Jede bestehende URL bekommt eine dauerhafte Weiterleitung auf ihre neue Entsprechung, Meta-Titel und Beschreibungen werden inhaltlich übernommen statt neu erfunden, und die interne Verlinkung wird so nachgebaut, dass sie im neuen System dieselbe Struktur abbildet wie vorher. Wo möglich bleibt die URL selbst identisch, wo sich das Schema ändern muss, etwa weil das alte TYPO3-Routing technische Eigenheiten enthielt, die im neuen System keinen Sinn mehr ergeben, übernimmt eine Weiterleitungstabelle die Zuordnung dauerhaft.
Redaktion einarbeiten
Ein neues System ist erst dann fertig, wenn die Redaktion darin genauso sicher arbeitet wie vorher in TYPO3, nicht wenn der letzte Datensatz migriert ist. Deshalb bekommt die Redaktion Zugang zum neuen System, sobald es den migrierten Bestand zeigt, parallel zum weiterlaufenden TYPO3-Betrieb. In dieser Phase geht es nicht um Live-Veröffentlichungen, sondern darum, dass jeder Redakteur den neuen Bearbeitungsprozess einmal am echten Inhalt durchspielt, bevor er darauf angewiesen ist.
Der Umstieg von TYPO3s Seitenbaum-Denken auf ein moderneres Content-Modell mit Blöcken ist für die Redaktion oft der größere Unterschied als jede technische Änderung darunter. Das braucht eine kurze, gezielte Einweisung statt eines Handbuchs, das niemand liest, und die Möglichkeit, in den ersten Wochen nach der Umstellung tatsächlich Rückfragen zu stellen. Erst wenn dieser Punkt erreicht ist, wird TYPO3 abgeschaltet, nicht am ursprünglich geplanten Stichtag.
Welche Systeme in Frage kommen
Die meisten Vergleiche zu TYPO3-Alternativen stellen andere klassische CMS gegenüber, etwa Neos, Pimcore oder Contao. Das sind reale Optionen, wenn eine Redaktion im gewohnten Seiten- und Baukasten-Denken bleiben will und der Umstieg vor allem den technischen Unterbau modernisieren soll.
Eine ehrliche zusätzliche Option, die in diesen Vergleichen meist fehlt, ist ein modernes, TypeScript-basiertes System wie Payload CMS. Der Unterschied ist nicht in erster Linie das Redaktionserlebnis, sondern die Architektur dahinter: Payload ist kein CMS mit angeflanschter Anwendungslogik, sondern ein Anwendungsframework, das die Redaktion gleich mitbringt. Für Projekte, die neben reinen Inhaltsseiten auch eigene Anwendungslogik brauchen, zum Beispiel ein Kundenportal, individuelle Formulare mit eigener Verarbeitung oder Inhalte, die auch außerhalb der eigenen Website ausgespielt werden, lässt sich das direkt im selben System und im selben Deploy umsetzen, statt eine Extension dafür zu bauen oder anzupassen.
Genauso wichtig ist die ehrliche Gegenrichtung: Wenn TYPO3 bei euch aktuell gehalten wird, euer Team die vorhandenen Extensions versteht und pflegt und das Datenmodell zu den Anforderungen passt, ist ein Wechsel oft nicht der richtige Schritt. Ein Systemwechsel lohnt sich dort, wo Updates ausgesetzt wurden, das Wissen über die Extensions im Team verloren gegangen ist oder das Seitenbaum-Modell für die aktuellen Anforderungen zu starr geworden ist, nicht als Wechsel um des Wechsels willen.
Was am Ende zählt
Ein Systemwechsel ist erst dann erfolgreich, wenn drei Dinge gleichzeitig stimmen: Die Redaktion kann ab dem ersten Tag im neuen System genauso veröffentlichen wie vorher, jede alte URL führt zuverlässig zu ihrer neuen Entsprechung, und kein Inhalt geht auf dem Weg verloren. Das lässt sich nicht an einem einzigen Stichtag erreichen, sondern nur, indem Alt- und Neusystem so lange parallel laufen, bis das neue System diesen Beweis tatsächlich erbracht hat.