Viele Redaktionen können sich eine Arbeit ohne Contentmanagement-System (CMS) heute nicht mehr vorstellen. Aber immer noch gibt es viele Redaktionen, die gerne ein CMS einführen möchten. Manche wünschen sich auch ein leistungsfähigeres System als ihr altes; eines das z. B. Workflows unterstützt oder besser mit anderen Datenspeichern im Unternehmen zusammenarbeitet. Was auch immer die konkrete Aufgabe ist, die Frage nach der Migration bleibt: „Wie bekomme ich meine bestehenden Inhalte in das neue System?“
Mal so nebenbei?
Manche nehmen das Thema Migration auf die leichte Schulter und planen diese Aufgabe nebenbei und nach und nach zu erledigen. Anderen wird von Systemherstellern suggeriert, dass die Aufgabe ganz einfach wäre, weil „ja die Bestandsdaten schon in XML vorliegen“. Wir migrieren seit über zwanzig Jahren in teilweise hochkomplexen Projekten für unsere Kunden Dokumentbestände und wir wissen: Nebenbei klappt das nicht und ganz einfach ist das – so pauschal – auch nicht.
Was bedeutet denn „nebenbei migrieren“ wirklich? Sie pflegen eventuell auf Jahre hinaus parallel zwei Systeme. Das funktioniert nur, wenn Sie jetzt schon Zeitressourcen freihaben oder zusätzlich Leute eingestellt werden, die das zweite CMS betreuen. Auch mit dem einfachen Umwandeln von XML ist das so eine Sache, denn XML ist nicht gleich XML. Normalerweise sind die verschiedenen XML-Dateien nicht strukturkonform und lassen sich nicht einfach ineinander überführen. Außerdem lässt sich in den Dokumenten nicht unbedingt erkennen, welche Automatismen das vorherige Redaktionswerkzeug bereitgestellt hat. Last, but not least: Die Wege, XML zu missbrauchen, sind fast unbegrenzt. In vielen XML-Dokumenten entdeckt man Strukturen und Mechanismen, die nicht wirklich logisch und vor allem nicht gut zu migrieren sind.
Phasenmodell für Migrationsprojekte
Um ein bisschen Ordnung in das Thema Bestandsdatenmigration zu bringen und Ihnen die Entscheidung zu erleichtern, wie sie dabei vorgehen wollen, möchten wir Ihnen hier einmal unser Phasenmodell für Migrationsprojekte vorstellen. Dabei gehen wir von sechs Abschnitten aus, in die ein Migrationsprojekt sich aufgliedert:
- Datenstrukturen in Quelle und Ziel verstehen
z. B. Inhaltsobjekte, Strukturobjekte, Metadaten, Taxonomien, Variablen - Automatismen in der Quelle verstehen
z. B. generierte Inhalte wie Verzeichnisse, Variantenmanagement, Layout-Automatismen - Übernahmeplan erstellen
d. h. Mapping zwischen allen Elementen der Quell- und Zieldokumente, Plan redaktioneller Vor- und Nacharbeiten, QS-Plan - Migrationsskripte erstellen und Pretest
inklusive von automatisierten Prüfmechanismen für Korrektheit und Vollständigkeit - Komplettimport
d. h. einmaliger Import aller relevanten Quelldokumente inklusive redaktioneller Vor- und Nacharbeiten - Qualitätssicherung und Tests
anhand des QS-Plans aus 3.
Mit so einem Migrationsplan wird die Komplexität bei der Bestandsdatenübernahme auch wirklich leichter bewältigbar. Dennoch bleibt die Komplexität der Aufgabe an sich aber bestehen. Einerseits soll die Migration ja schnell und unaufwändig vor sich gehen, anderseits muss das Ergebnis aber auch höchsten Qualitätsansprüchen gerecht werden. Schon ein falsch konvertiertes Sonderzeichen kann da ein Haftungsrisiko auslösen (z. B. wenn in den Technischen Daten ein „µ“ im Ausgangstext als „m“ im Zieltext übernommen wird). Dieser Komplexitätsfalle können Sie kaum entgehen, denn bei dem bestehenden Redaktionswerkzeug zu bleiben, ist im Normalfall auch keine Alternative.
Es lohnt sich also die Komplexität der Migration eines CMS nicht zu unterschätzen und ausreichend Zeit und Budget für die Bestandsdatenübernahme vorzusehen. Nur so kommt man auf den richtigen Pfad, damit die alten Dokumente auch im neuen System funktionieren.
Lesen Sie auch unseren Use Case „ContentMigration — schnell produktiv im neuen System”!
Jetzt herunterladen!