Von TYPO3 zu Drupal: Migration ohne Datenverlust

Von Alex Schell

Drupal 7 Min. Lesezeit

„Ohne Datenverlust“ ist eine Formulierung, die in Angeboten steht und selten definiert wird. Bevor wir über Vorgehen sprechen, gehört sie präzisiert — denn bei einer Migration gehen zwangsläufig Dinge verloren, und der Unterschied zwischen einem guten und einem schlechten Projekt liegt darin, ob es die geplanten Dinge sind.

Was wirklich vollständig erhalten bleiben muss, sind vier Sachen: die Inhalte selbst, ihre Verknüpfungen untereinander, ihre Adressen im Netz und ihre Zugehörigkeit zu Struktur und Sprache. Was regelmäßig nicht erhalten bleibt und auch nicht erhalten bleiben sollte: die technische Umsetzung der Inhaltselemente, gewachsene Sonderlösungen und der Teil des Inhalts, den seit Jahren niemand aufgerufen hat.

Eine Migration ist deshalb nie eine reine Übertragung. Sie ist eine Übertragung mit Inventur.

Warum TYPO3 zu Drupal ein besonderer Fall ist

Beide Systeme sind ausgewachsene Enterprise-CMS, beide laufen in PHP, beide können, was das andere kann. Der Unterschied liegt im Datenmodell, und genau dort entsteht die Arbeit.

TYPO3 denkt in Seiten, die Inhaltselemente in Spalten tragen. Eine Seite ist ein Behälter, und was darin liegt, ist eine geordnete Folge von Elementen. Drupal denkt in Inhaltsentitäten mit typisierten Feldern: Ein Inhaltstyp „Referenz“ hat ein Feld für den Kunden, eines für die Branche, eines für Kennzahlen.

Das ist keine Geschmacksfrage, sondern ein struktureller Vorteil in der weiteren Nutzung: Was in Feldern liegt, ist filterbar, auswertbar, in anderen Sprachen wiederverwendbar und lässt sich später anders darstellen, ohne den Inhalt anzufassen. Was als freier Text in einer Spalte liegt, ist nur Text.

Die Konsequenz für das Projekt: Der aufwendigste Schritt ist nicht das Übertragen. Es ist die Entscheidung, welches Feld welcher Inhalt wird. Diese Entscheidung ist inhaltlich, nicht technisch — und sie braucht die Redaktion, nicht nur die Entwicklung.

Die Reihenfolge, die funktioniert

Schritt 1: Inventur, bevor irgendetwas gebaut wird

Vollständige Liste aller Seiten mit vier Angaben: Adresse, letzte Änderung, Aufrufe der letzten zwölf Monate, verantwortliche Person. Die Aufrufzahlen kommen aus der Webanalyse, die Liste aus dem System oder einem Crawl.

Diese Tabelle ist unspektakulär und der wichtigste Schritt des Projekts. In fast jeder gewachsenen TYPO3-Installation sind zwischen dreißig und sechzig Prozent der Seiten Altlast: veraltete Kampagnen, doppelte Fassungen, Seiten ohne Aufrufe, Entwürfe, die nie fertig wurden.

Diese Seiten mitzumigrieren kostet dreifach — im Übertragen, im Prüfen und danach in der Pflege. Sortiere jede Seite in eine von vier Klassen: übernehmen wie sie ist, übernehmen und überarbeiten, zusammenfassen mit einer anderen, oder abschalten mit Weiterleitung.

Wichtig ist die vierte Klasse: abschalten mit Weiterleitung, nicht einfach abschalten. Alles, was Aufrufe oder eingehende Verlinkungen hat, braucht ein Ziel — auch wenn der Inhalt verschwindet.

Schritt 2: Das Inhaltsmodell aus den echten Inhalten ableiten

Der typische Fehler: Man baut die Inhaltstypen, die man aus anderen Projekten kennt, und presst die Inhalte hinein. Das führt zu Feldern, die niemand füllt, und zu Inhalten, die in einem Freitextfeld landen, weil das passende Feld fehlt.

Besser: Zwanzig repräsentative Seiten aus der Inventur nehmen — die häufigsten Typen, die kompliziertesten Fälle — und daran das Modell entwickeln. Welche Inhaltstypen gibt es wirklich? Welche Felder trägt jeder? Was bleibt gestalteter Fließtext, was wird strukturiertes Feld?

Diese Abstimmung dauert ein bis zwei Workshops. Wer sie überspringt, zahlt sie später als Nacharbeit an jeder migrierten Seite.

Schritt 3: Migration als wiederholbares Programm, nicht als Handarbeit

Das ist der Punkt, an dem sich Projekte am deutlichsten unterscheiden. Drupal bringt für Migrationen eine eigene Programmierschnittstelle mit, und ihr entscheidender Vorteil ist nicht Geschwindigkeit, sondern Wiederholbarkeit.

Eine geschriebene Migration liest die TYPO3-Datenbank, bildet die Felder ab und schreibt die Drupal-Inhalte. Sie lässt sich beliebig oft laufen lassen, korrigieren und erneut laufen lassen. Sie führt Buch darüber, welcher Quelldatensatz zu welchem Zieldatensatz wurde — was Aktualisierungen statt Dubletten ermöglicht.

Der praktische Gewinn zeigt sich am Ende: Du kannst am Tag vor dem Umschalten die Inhalte noch einmal frisch übernehmen. Bei Handarbeit brauchst du dafür einen Redaktionsstopp über Wochen. Mit einer wiederholbaren Migration reicht ein Stopp von wenigen Stunden.

Bei Bildern und Dokumenten gilt dasselbe Prinzip, mit zwei Zusatzpunkten: Dateien wollen als echte Medienobjekte übernommen werden, nicht als Verweise ins alte Verzeichnis — sonst bleibt die alte Installation für immer als Bildserver in Betrieb. Und Alternativtexte gehören mitgenommen, wo sie existieren. Sie neu zu erfassen ist eine der teuersten Nacharbeiten, die man sich einkaufen kann.

Schritt 4: Die Adressen — der Schritt, an dem Projekte wirklich scheitern

Inhaltsverlust ist selten. Sichtbarkeitsverlust ist häufig, und er ist teurer.

TYPO3-Adressen unterscheiden sich strukturell von dem, was Drupal vergibt. Jede alte Adresse braucht deshalb eine dauerhafte Weiterleitung auf ihr neues Ziel. „Jede“ heißt: alle, auch die alten Seiten-Adressen mit Parametern, auch die Adressen der Sprachvarianten, auch die von abgeschalteten Seiten.

Das Vorgehen, das sich bewährt hat: Die alte Website vollständig crawlen und dazu die Adressen aus der Search Console und der Webanalyse der letzten zwölf Monate ziehen — auch solche, die im Crawl nicht auftauchen, weil sie nirgends verlinkt sind, aber Zulauf haben. Aus dieser Liste eine Zuordnungstabelle bauen, jeder alten Adresse ein neues Ziel geben, und diese Tabelle in Drupals Weiterleitungsverwaltung importieren.

Zwei Regeln dazu. Erstens: dauerhafte Weiterleitungen, keine temporären. Zweitens: kein Sammelziel. Alles pauschal auf die Startseite zu leiten wird von Suchmaschinen wie eine Fehlerseite behandelt und vernichtet den Wert der alten Adresse. Wenn es kein passendes Einzelziel gibt, ist die Übersichtsseite der Kategorie richtig — nicht die Startseite.

Diese Tabelle ist der Grund, warum ein Relaunch Rankings behält oder verliert. Sie ist mühsam, sie ist nicht sichtbar, und sie ist der Posten, an dem man am wenigsten sparen sollte.

Schritt 5: Prüfen mit Zahlen, nicht mit Stichproben

Vor dem Umschalten drei Vergleiche, jeweils als Zahl:

  • Mengenabgleich. So viele Seiten wie geplant, so viele Bilder, so viele Sprachvarianten? Abweichungen erklären, nicht wegdiskutieren.
  • Weiterleitungstest. Alle Adressen der Zuordnungstabelle automatisiert aufrufen. Erwartet wird bei jeder eine dauerhafte Weiterleitung, die in einem Schritt auf eine erreichbare Seite führt. Keine Ketten, keine Fehlerseiten.
  • Vollständigkeitsprüfung der Inhalte. Bei den wichtigsten hundert Seiten automatisiert vergleichen: Ist die Textmenge vergleichbar? Fehlen Bilder? Fehlen Links? So findest du abgeschnittene Inhalte, die eine Stichprobe übersieht.

Schritt 6: Umschalten mit Rückweg

Ablauf am Umschalttag: Redaktionsstopp, letzter Migrationslauf, Weiterleitungen importieren, Sitemap erzeugen, DNS umstellen, Prüflauf. Die Wartezeit im Namenssystem verkürzt man, indem man die Gültigkeitsdauer der Einträge Tage vorher senkt.

Der Rückweg gehört dazu: Die alte Installation bleibt einige Wochen erreichbar, aber nicht öffentlich indexierbar. Nicht, weil man ein Scheitern erwartet, sondern weil in Woche zwei zuverlässig jemand einen Inhalt sucht, der in der Inventur als entbehrlich eingestuft wurde.

Schritt 7: Vier Wochen Nachlauf

Nach dem Umschalten wöchentlich die Fehlerseiten-Protokolle ansehen. Jede häufig aufgerufene Fehlerseite ist eine Adresse, die in der Zuordnungstabelle fehlte — und jede lässt sich in Minuten nachtragen. Diese vier Wochen sind der billigste Teil der Sichtbarkeitssicherung und werden am häufigsten weggelassen, weil das Projekt „fertig“ ist.

Was den Zeitplan sprengt

Drei Dinge, in dieser Häufigkeit:

Gewachsene Sonderlösungen. Erweiterungen, die vor Jahren jemand angepasst hat, deren Funktion niemand mehr vollständig beschreiben kann. Sie gehören früh benannt, denn für jede ist einzeln zu entscheiden: nachbauen, ersetzen oder streichen. Wird das spät entdeckt, wird es teuer.

Mehrsprachigkeit. Beide Systeme lösen Übersetzung unterschiedlich. Wenn eine Sprachvariante gepflegt ist und eine seit drei Jahren nicht, gehört diese Entscheidung vor die Migration — nicht mitten hinein.

Inhaltsqualität. Der häufigste Grund, warum Migrationen länger dauern als geplant, ist nicht Technik. Es ist der Moment, in dem beim Blick auf die Inventur klar wird, dass ein Drittel der Inhalte überarbeitet werden müsste. Diese Arbeit ist richtig und sinnvoll — aber sie ist ein eigenes Projekt mit eigener Kapazität, kein Nebenprodukt der Migration.

Woran du ein belastbares Angebot erkennst

Wenn du gerade Angebote vergleichst, sind das die Punkte, an denen sich Erfahrung zeigt:

  • Enthält es eine Inventurphase vor dem Festpreis für die Umsetzung? Wer ohne Inventur einen Festpreis nennt, hat entweder großzügig aufgeschlagen oder wird nachfordern.
  • Steht die Weiterleitungstabelle als eigener Posten drin — mit einer Zahl, wie viele Adressen erwartet werden?
  • Ist die Migration als wiederholbares Programm geplant oder als Handarbeit? Frag konkret nach, ob am Tag vor dem Umschalten noch einmal übernommen werden kann.
  • Gibt es einen Nachlauf nach dem Umschalten, und wie lang?
  • Wird ein Inhaltsmodell-Workshop mit deiner Redaktion vorgesehen?

Wir haben Migrationen in dieser Größenordnung mehrfach begleitet — unter anderem für die Ruhr-Universität Bochum, wo zwei Drupal-Instanzen bei minimaler Beeinträchtigung für Redaktion und Nutzer im Zeit- und Budgetrahmen migriert wurden. Der Grund, warum solche Projekte ruhig verlaufen, ist selten technische Brillanz. Es ist die Inventur am Anfang und die Weiterleitungstabelle am Ende.

Wenn du vor dieser Entscheidung stehst: In der kostenlosen Potenzialanalyse sehen wir uns deine Installation an und sagen dir, was ein Wechsel realistisch kostet — und ob er sich für dich lohnt. Manchmal ist die ehrliche Antwort, dass eine Aktualisierung des Bestehenden der bessere Weg ist.

Zurück zu Wissen & Ressourcen