TYPO3 ablösen: was der Wechsel wirklich kostet
Die teuren Posten einer Migration sind nicht die Texte. Es sind das Datenmodell, die Übersetzungen, die Rechte und die URLs, an denen eure Sichtbarkeit hängt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Vergleich wird meistens zwischen ungleichen Zahlen geführt
Die Frage kommt selten aus dem Nichts. Sie kommt, wenn der kostenlose Support für die eingesetzte Version endet und plötzlich ein Angebot auf dem Tisch liegt, das größer ist als das Budget für die ganze Website im letzten Jahr. In dieser Situation wirkt jedes andere System erst einmal günstiger, und genau darauf sind viele Angebote auch aufgebaut.
Der Denkfehler steckt in der Vergleichsbasis. Auf der einen Seite steht ein Upgrade-Angebot, das den vorhandenen Funktionsumfang eins zu eins fortschreibt, inklusive aller Sonderlösungen, die über Jahre dazugekommen sind. Auf der anderen Seite steht ein Neubau-Angebot für eine Website, die es so noch nicht gibt, und dessen Umfang die Nacharbeit an Inhalten, Übersetzungen und Weiterleitungen typischerweise nicht enthält.
Wer diesen Vergleich falsch anstellt, zahlt zweimal. Erst für den Wechsel, dann für die Monate danach, in denen die Redaktion in einem System arbeitet, das ihre Abläufe nicht kennt, in denen übersetzte Seiten neu verknüpft werden und in denen die Sichtbarkeit einbricht, weil bei den Weiterleitungen jemand die Hälfte der alten URLs übersehen hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der direkte Vergleich
Upgraden und bleiben
auf die aktuelle unterstützte Fassung heben und die Installation weiterbetreiben
System wechseln
die Inhalte in ein einfacheres System übernehmen und dort neu aufbauen
Frontend entkoppeln
TYPO3 als Inhaltsquelle behalten und die Ausgabe neu bauen
| Entscheidungsfrage | Upgraden und bleiben | System wechseln | Frontend entkoppeln |
|---|---|---|---|
| Was passiert mit dem Datenmodell aus Inhaltselementen und Spalten? | Stärke Es bleibt, wie es ist. Anzupassen sind eigene Templates und Erweiterungen, aber Struktur, Elementarten und Zuordnungen bleiben unangetastet. | Schwäche Elemente in festen Spalten haben in einem freien Editor keine Entsprechung. Für jede Art braucht es eine Regel, und für eigene Elemente meist Handarbeit. | Stärke Die Inhalte bleiben, wo sie sind, samt Struktur und Redaktionsoberfläche. Neu gebaut wird nur die Ausgabe. |
| Was passiert mit Übersetzungen und Sprachbeziehungen? | Stärke Nichts. Die Verbindung zwischen Original und Übersetzung und die Fallback-Regeln der Sites bleiben so bestehen, wie die Redaktion sie kennt. | Schwäche Kennt das Zielsystem keine Übersetzungsbeziehung, entstehen aus verbundenen Seiten unabhängige Einzelseiten. Was danach auseinanderläuft, merkt niemand mehr. | Kommt darauf an Die Beziehungen bleiben in der Datenhaltung erhalten, müssen aber im neuen Frontend samt Sprachwahl und Fallback korrekt abgebildet werden. |
| Was wird aus Redaktionsrechten und Freigabewegen? | Stärke Gruppen, Zuschnitte des Seitenbaums und Freigaben laufen weiter. Auch das Wissen der Redaktion bleibt vollständig nutzbar. | Schwäche Feine Zuschnitte und echte Freigaben lassen sich in kleineren Systemen oft nur mit Erweiterungen abbilden, und die Redaktion lernt alles neu. | Stärke Das Backend bleibt unverändert, die Redaktion arbeitet weiter wie bisher, samt bestehender Rechte und Abläufe. |
| Was passiert mit URLs, Weiterleitungen und Sichtbarkeit? | Stärke Die Adressen bleiben identisch, damit auch alles, was daran hängt: Rankings, gesetzte Links von außen, gedruckte Kurzadressen und Lesezeichen. | Kommt darauf an Beherrschbar, aber nur mit vollständiger Adressliste und sauberen Weiterleitungen. Genau hier gehen in der Praxis die meisten Projekte baden. | Kommt darauf an Die Adressen lassen sich beibehalten, sofern die Routenlogik im neuen Frontend die bestehende Struktur nachbildet. Das ist Aufwand, aber kalkulierbar. |
| Wie planbar sind Aufwand und Termin? | Stärke Der Umfang lässt sich vorher ermitteln, weil sich der Aufwand an der Zahl der eigenen Erweiterungen und Templates festmacht und nicht an Geschmacksfragen. | Schwäche Ein Neubau zieht Gestaltungs- und Inhaltsdiskussionen an, die nichts mit dem System zu tun haben. Termine verschieben sich selten aus technischen Gründen. | Kommt darauf an Technisch gut abgrenzbar, verlangt aber Entwicklungskapazität für ein eigenes Frontend, die dauerhaft verfügbar bleiben muss. |
| Wie sieht der Betrieb in drei Jahren aus? | Kommt darauf an Der nächste Sprung kommt wieder, dafür bekannt und budgetierbar. Wer eigene Erweiterungen schlank hält, macht ihn beim nächsten Mal günstiger. | Kommt darauf an Laufende Updates sind kleiner, die Pflege verlagert sich auf die eingesetzten Erweiterungen. Ohne feste Zuständigkeit wird daraus ein stilles Risiko. | Kommt darauf an Zwei Teile wollen gepflegt werden, Inhaltssystem und Frontend. Das lohnt sich, wenn die Inhalte ohnehin an mehreren Stellen gebraucht werden. |
Was passiert mit dem Datenmodell aus Inhaltselementen und Spalten?
Es bleibt, wie es ist. Anzupassen sind eigene Templates und Erweiterungen, aber Struktur, Elementarten und Zuordnungen bleiben unangetastet.
Elemente in festen Spalten haben in einem freien Editor keine Entsprechung. Für jede Art braucht es eine Regel, und für eigene Elemente meist Handarbeit.
Die Inhalte bleiben, wo sie sind, samt Struktur und Redaktionsoberfläche. Neu gebaut wird nur die Ausgabe.
Was passiert mit Übersetzungen und Sprachbeziehungen?
Nichts. Die Verbindung zwischen Original und Übersetzung und die Fallback-Regeln der Sites bleiben so bestehen, wie die Redaktion sie kennt.
Kennt das Zielsystem keine Übersetzungsbeziehung, entstehen aus verbundenen Seiten unabhängige Einzelseiten. Was danach auseinanderläuft, merkt niemand mehr.
Die Beziehungen bleiben in der Datenhaltung erhalten, müssen aber im neuen Frontend samt Sprachwahl und Fallback korrekt abgebildet werden.
Was wird aus Redaktionsrechten und Freigabewegen?
Gruppen, Zuschnitte des Seitenbaums und Freigaben laufen weiter. Auch das Wissen der Redaktion bleibt vollständig nutzbar.
Feine Zuschnitte und echte Freigaben lassen sich in kleineren Systemen oft nur mit Erweiterungen abbilden, und die Redaktion lernt alles neu.
Das Backend bleibt unverändert, die Redaktion arbeitet weiter wie bisher, samt bestehender Rechte und Abläufe.
Was passiert mit URLs, Weiterleitungen und Sichtbarkeit?
Die Adressen bleiben identisch, damit auch alles, was daran hängt: Rankings, gesetzte Links von außen, gedruckte Kurzadressen und Lesezeichen.
Beherrschbar, aber nur mit vollständiger Adressliste und sauberen Weiterleitungen. Genau hier gehen in der Praxis die meisten Projekte baden.
Die Adressen lassen sich beibehalten, sofern die Routenlogik im neuen Frontend die bestehende Struktur nachbildet. Das ist Aufwand, aber kalkulierbar.
Wie planbar sind Aufwand und Termin?
Der Umfang lässt sich vorher ermitteln, weil sich der Aufwand an der Zahl der eigenen Erweiterungen und Templates festmacht und nicht an Geschmacksfragen.
Ein Neubau zieht Gestaltungs- und Inhaltsdiskussionen an, die nichts mit dem System zu tun haben. Termine verschieben sich selten aus technischen Gründen.
Technisch gut abgrenzbar, verlangt aber Entwicklungskapazität für ein eigenes Frontend, die dauerhaft verfügbar bleiben muss.
Wie sieht der Betrieb in drei Jahren aus?
Der nächste Sprung kommt wieder, dafür bekannt und budgetierbar. Wer eigene Erweiterungen schlank hält, macht ihn beim nächsten Mal günstiger.
Laufende Updates sind kleiner, die Pflege verlagert sich auf die eingesetzten Erweiterungen. Ohne feste Zuständigkeit wird daraus ein stilles Risiko.
Zwei Teile wollen gepflegt werden, Inhaltssystem und Frontend. Das lohnt sich, wenn die Inhalte ohnehin an mehreren Stellen gebraucht werden.
Was passt wann
- Wenn die Installation im Kern gesund ist und die Redaktion mit ihr arbeitet
- upgrade und investier das gesparte Geld darin, Sonderlösungen abzubauen.
- Wenn eure Installation ein Sonderbau ist, den niemand mehr betreuen kann
- wechsle das System, denn ein Upgrade wäre in diesem Fall ohnehin ein Neubau.
- Wenn die Inhalte künftig auch in App, Shop oder zweitem Auftritt gebraucht werden
- entkopple das Frontend und behalte die Inhaltsbasis, statt beides gleichzeitig neu zu bauen.
Fünf Posten, die in keinem Migrationsangebot stehen
- 01 Jede eigene Elementart braucht eine eigene Regel für die Übernahme.
- 02 Verbindungen zwischen Original und Übersetzung überleben den Umzug selten.
- 03 Gewachsene Rechte und Freigabewege müssen im Zielsystem nachgebaut werden.
- 04 Alte Adressen brauchen Weiterleitungen, sonst geht Sichtbarkeit verloren.
- 05 Die Redaktion arbeitet monatelang langsamer, bis das neue System sitzt.
Was du danach belastbar gegenüberstellen kannst
Die folgenden Posten entscheiden über die tatsächlichen Kosten, und sie stehen in keinem der beiden Angebote. Wenn du sie vorher kennst, führst du die Diskussion über die richtigen Zahlen.
Das Datenmodell bewerten
Du weißt, dass Inhaltselemente in festen Spalten sich nicht automatisch in einen freien Block-Editor übertragen lassen und dass jede Elementart eine eigene Übersetzungsregel braucht.
Übersetzungen als eigenen Posten führen
Du erkennst, dass die Verbindung zwischen Original und Übersetzung beim Wechsel verloren geht, wenn das Zielsystem sie nicht kennt, und was das für die weitere Pflege bedeutet.
Rechte und Abläufe aufnehmen
Du erfasst gewachsene Benutzergruppen, Zuschnitte des Seitenbaums und Freigabewege, bevor jemand sie im Zielsystem nachbaut oder feststellt, dass das nicht geht.
URLs und Weiterleitungen sichern
Du gehst mit einer vollständigen Liste der bestehenden Adressen in das Projekt und behandelst die Weiterleitungen als Teil des Umzugs, nicht als Nacharbeit.
Den dritten Weg mitdenken
Du prüfst, ob ein neues Frontend auf der bestehenden Inhaltsbasis die Anforderungen erfüllt, bevor die Diskussion auf zwei Möglichkeiten verkürzt wird.
Die Ausstiegsgründe ehrlich prüfen
Du benennst die Fälle, in denen der Wechsel die richtige Entscheidung ist, statt eine bestehende Installation aus Gewohnheit zu verteidigen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Das Datenmodell ist der teuerste Posten, nicht die Texte
Beim Umzug denken alle zuerst an Inhalte, und Texte sind tatsächlich das kleinste Problem. Teuer wird die Struktur darunter. Eine TYPO3-Seite besteht aus einzelnen Inhaltselementen, die einer Spalte des Backend-Layouts zugeordnet sind und je nach Art eigene Felder haben. Ein freier Block-Editor kennt diese Zuordnung nicht. Für jede Elementart muss deshalb festgelegt werden, in welchen Block sie überführt wird, was mit ihren Zusatzfeldern passiert und wie das Ergebnis aussehen soll.
Für die Standardelemente lässt sich die Übernahme weitgehend automatisieren, weil ihre Felder in beiden Systemen dieselbe Bedeutung haben, und die üblichen Zielsysteme bringen dafür Importwege über ihre Schnittstelle mit. Der Aufwand steckt in dem, was über die Jahre dazugekommen ist: eigene Elementarten für Teaser, Referenzen, Ansprechpartner oder Downloadlisten, jeweils mit eigenen Feldern und eigener Darstellung. Jede davon ist ein kleines Migrationsprojekt für sich, und ihre Zahl ist der beste verfügbare Schätzwert für den Gesamtaufwand. Lass dir diese Zahl deshalb vor jedem Angebot nennen und nicht die Zahl der Seiten.
Der zweite unterschätzte Punkt ist die Dateiverwaltung. In TYPO3 ist eine Datei ein eigener Datensatz mit Metadaten, auf den mehrere Inhalte verweisen können. Beim Wechsel entstehen daraus meist wieder einzelne Anhänge, und Bildunterschriften, Alternativtexte und Urheberangaben, die zentral an der Datei hingen, sind entweder verloren oder liegen anschließend vervielfacht in den Inhalten.
Was an den alten Adressen hängt
Jede bestehende URL trägt Sichtbarkeit, die über Jahre entstanden ist. Dazu kommen Links von außen, Verweise in PDF-Dokumenten, Kurzadressen aus Anzeigen und die Lesezeichen von Stammkunden. Beim Wechsel ändert sich die Adressstruktur fast immer, weil das neue System andere Regeln für Pfade mitbringt. Wer das erst nach dem Livegang bemerkt, sieht den Einbruch in den Zugriffszahlen, bevor er die Ursache kennt.
Handwerklich ist die Lösung unspektakulär: vor dem Umzug eine vollständige Liste aller erreichbaren Adressen ziehen, jede davon einer neuen Zieladresse zuordnen und die Weiterleitungen mit dem Livegang scharf schalten, nicht danach. Unangenehm wird es dort, wo eine alte Seite kein Gegenstück mehr hat. Diese Fälle müssen einzeln entschieden werden, und sie sind der Grund, warum diese Aufgabe niemals nebenbei erledigt werden kann.
TYPO3 verwaltet solche Weiterleitungen mit der Systemerweiterung redirects. Ändert jemand den Adressbestandteil einer Seite, legt das System auf Wunsch selbst eine Weiterleitung von der alten auf die neue Adresse an, sofern diese Automatik in der Konfiguration aktiv ist. Genau dieser gewachsene Bestand ist beim Wechsel mitzunehmen, denn dort stecken oft Jahre an Umbenennungen. Wer nur den aktuellen Seitenbaum abbildet, verliert alles, was über diese Kette noch erreichbar war. Und weil die Automatik weder rückwirkend greift noch Adressen aus Erweiterungen erfasst, gehört neben dem Auszug aus dieser Tabelle immer ein eigener Durchlauf über die tatsächlich aufgerufenen Adressen aus dem Serverprotokoll.
Was für das Upgrade spricht
Ein Upgrade ist einmalig teuer und dafür in seinem Umfang bestimmbar. Der Aufwand hängt an drei Größen, die sich vorher zählen lassen: der Zahl der eingesetzten Fremderweiterungen, der Menge an eigenem Code und dem Alter der Templates. Was nicht daran hängt, sind Geschmacksfragen, und deshalb laufen Upgrades seltener aus dem Ruder als Neubauten.
Der zweite Vorteil ist das, was gar nicht angefasst wird. Die Redaktion arbeitet weiter wie bisher, Schnittstellen zu anderen Systemen bleiben bestehen, Rechte und Freigaben laufen unverändert, und die Adressen ändern sich nicht. Diese vier Punkte sind in einem Migrationsprojekt die aufwendigsten, und im Upgrade tauchen sie schlicht nicht auf.
Ein Upgrade ist außerdem der bessere Zeitpunkt zum Aufräumen. Jede Erweiterung, die dabei ersatzlos entfällt, macht auch den nächsten Sprung billiger. Wer die Gelegenheit nutzt, um eigene Elemente zusammenzufassen und ungenutzte Funktionen abzuschalten, senkt damit dauerhaft die Kosten und nicht nur die dieses einen Projekts.
Wann der Ausstieg die richtige Entscheidung ist
Es gibt Fälle, in denen ein Upgrade Geld in eine Konstruktion steckt, die niemand mehr tragen will. Der erste ist der Sonderbau: eine Installation, deren tragende Teile aus eigenem Code bestehen, den die ursprüngliche Agentur geschrieben hat, die es nicht mehr gibt. Wenn ein Upgrade in der Praxis bedeutet, diese Teile neu zu schreiben, dann vergleichst du nicht mehr Upgrade gegen Neubau, sondern zwei Neubauten, und dann darf das Zielsystem auch ein anderes sein.
Der zweite Fall ist die geschrumpfte Anforderung. Manche Installationen stammen aus einer Zeit mit mehreren Standorten, drei Sprachen und einer großen Redaktion. Wenn davon eine einsprachige Website mit zwei Redakteuren übrig ist, bezahlst du Struktur, die niemand mehr nutzt. Ein kleineres System ist dann nicht der Rückschritt, sondern die passende Größe.
Der dritte Fall ist die Betreuung. Wenn niemand im Haus TYPO3 kann, kein Dienstleister die Installation übernehmen will und das Wissen an einer einzigen Person hängt, ist das ein Risiko, das keine Funktionsliste aufwiegt. Und schließlich der vierte: Wenn der Auftritt ohnehin komplett neu gedacht wird, Struktur und Texte also neu entstehen, fällt der größte Vorteil des Bleibens weg, denn dann wird nichts übernommen, was zu übernehmen wäre.
Der dritte Weg, der selten angeboten wird
Zwischen Bleiben und Gehen liegt die Möglichkeit, TYPO3 als Inhaltsquelle zu behalten und nur die Ausgabe neu zu bauen. Die Redaktion arbeitet weiter in der gewohnten Oberfläche, Rechte und Übersetzungen bleiben erhalten, und das Frontend entsteht als eigenständige Anwendung, die sich die Inhalte über eine Schnittstelle holt. Das lohnt sich vor allem dann, wenn dieselben Inhalte an mehreren Stellen gebraucht werden, etwa zusätzlich in einer App oder in einem Shop.
Ehrlich dazu gehört, dass TYPO3 dafür keine fertige Inhalts-Schnittstelle mitbringt. Sie kommt über eine Erweiterung oder über eigenen Code, und beides will gepflegt werden. Dazu kommt der Punkt, den Redaktionen zuerst vermissen: Die Vorschau einer noch nicht veröffentlichten Seite ist in einem entkoppelten Aufbau kein Selbstläufer mehr, sondern muss eigens gebaut werden.
Als Startpunkt für ein neues Projekt ist dieser Weg selten der einfachste. Für eine gewachsene Installation, deren Inhalte in Ordnung sind und deren Frontend veraltet ist, ist er oft der günstigste, weil genau der Teil erneuert wird, der stört, und der Rest unangetastet bleibt.
Dazu passende Kurse
Die teuerste Abhängigkeit in dieser Entscheidung ist fehlendes eigenes Wissen, dagegen hilft TYPO3-Know-how im eigenen Haus .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Sehr kompetente und freundliche Trainerin. Die Inhalte wurden gut strukturiert und anhand von anschaulichen Beispielen vermittelt.
Häufige Fragen
Lassen sich die Inhalte automatisch übernehmen?
Verlieren wir bei einem Wechsel unsere Google-Rankings?
Ist der bezahlte Verlängerungssupport eine Lösung oder nur Aufschub?
Wie schätzen wir den Upgrade-Aufwand ab, bevor wir Angebote einholen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem TYPO3-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die beste Ausgangslage ist eine Installation, die ihr selbst versteht
Wer weiß, wie Erweiterungen, Templates und Konfiguration zusammenhängen, kann Angebote beurteilen statt sie nur zu vergleichen, und dieses Wissen vermitteln die TYPO3-Kurse bei cmt.