ContentMigration – schnell produktiv im neuen System

ContentMigration – alte Daten ins neue Redaktionssystem

Nicht alle Tage wechselt man seine Redaktionsumgebung. Und wenn man es tut, dann verbindet man damit Hoffnungen auf bequemeres Arbeiten, Effizienz und Zuverlässigkeit. Allzu schnell übersieht man dabei die Frage, wie eigentlich die bestehenden Dokumente und Daten in das neue System gelangen sollen. Wir haben bei doctima in zwanzig Jahren über hundert – teils extrem komplexe – Migrationsprojekte durchgeführt. Mit diesem UseCase möchten wir Ihnen einige wichtige Punkte bei der Migration zeigen, die Ihnen den Weg in die neue Systemumgebung erleichtern.

Use Case „ContentMigration“ als PDF herunterladen

Problemstellungen

Migration ist ja eine der Aufgaben, die man sich am liebsten sparen würde, denn die Prozessanfor derungen sind alles andere als einfach. Die bestehenden Daten sollen möglichst schnell in das neue System gelangen. Gleichzeitig soll der Aufwand dafür möglichst gering sein; idealerweise funktioniert auch alles automatisch.

Der Content soll fehlerfrei und ohne Verluste transferiert werden. Gleichzeitig sind oft strukturelle Anpassungen an die neuen Gegebenheiten im Zielsystem notwendig oder wünschenswert. Nachvoll ziehbarkeit ist eine weitere wichtige Anforderung, schließlich will man ja wissen, welche Inhalte wann und von wem auf welchem Weg umgewandelt wurden.

Und dann will man das alles noch umsetzen, ohne das laufende Geschäft zu stören. Es lohnt sich also, ContentMigration gezielt zu planen und strukturiert anzugehen.

Zwei Szenarien

XML ist doch kein Problem

XML hat den Anspruch, strukturierte Daten leicht in andere strukturierte Formate umwandeln zu können. Mit BestandsContent auf XMLBasis sollte man als Redakteur also auf der sicheren Seite sein. Und im Prinzip ist das auch richtig. Allerdings nur, wenn zuvor niemand „kreativ“ gearbeitet hat. Denn sobald jemand versucht mit XML zu layouten, beginnen die Probleme bei der Konvertierung. Mit XML layouten, das heißt: Ich versuche ein bestimmtes Aussehen im Endtext zu erreichen und verwende dazu XMLKonstrukte, die eigentlich für anderes gedacht sind. Dann werden Tabellen mit nur einer Zelle erzeugt, weil man dann Text mit einem grauen Hintergrund erhält. Oder Bilder werden als Elemente in ÜberschriftenTags eingefügt, weil das die einzige Art ist, wie man Bilder ohne Bild beschriftung erzeugen kann. Solch unliebsame Überraschungen erlebt man leider immer wieder, auch bei Standards wie DITA.

Nach-und-Nach-Migration

Warum sollte man denn eigentlich den ganzen Content in das neue System überführen? Man kann doch genauso gut die Bestandsdokumente Schritt für Schritt auf das neue System umstellen. Der Gedanke ist auf jeden Fall eine Überlegung wert. Allerdings kann es sein, dass der bestehende Con tent aus strukturellen Gründen dafür wenig geeignet ist, zum Beispiel weil er stark vernetzt ist oder Contentmodule häufig wiederverwendet werden.

ContentMigration –

schnell produktiv im neuen System

Nach und nach zu migrieren bedeutet auch nicht, dass der Gesamtaufwand für die Migration sinkt – eher umgekehrt. Wenn also die Personal und Zeitsituation im Moment eine Komplettmigration nicht erlaubt, sollte man sich sehr genau überlegen, wie viel Zeit neben dem regulären Betrieb für die Migration und die Zusatzaufwände durch die Pflege von zwei Systemen wirklich bleiben werden. Sonst kann es zu dem Effekt kommen, den wir von doctima schon mehrfach in Unternehmen erlebt haben: Das neue System ist bereits seit ein, zwei Jahren implementiert, aber es ist immer noch nicht produktiv, weil keine Zeit bleibt, die Altdaten dorthin zu übertragen.

Was Sie bei Ihrer Migration beachten sollten

Wie plant man also am besten sein Migrationsprojekt? Zunächst einmal: Glauben Sie nicht, dass die Migration Teil der Systemeinführung ist. Nur in den wenigsten Fällen übernehmen die Software anbieter auch die Migration des Contents.

Und: Planen Sie Zeit ein. Ein typisches Migrationsprojekt mit 10.000 Seiten DIN A4 braucht im Minimal fall mindestens drei Monate; aber auch ein Jahr Projektdauer ist nicht ungewöhnlich. Das hängt nicht zuletzt davon ab, wie individuell Ihr Content gestaltet ist und welche Nachbearbeitungsschritte ablau fen, die aus dem Content nicht sofort ersichtlich sind.

Auf der Basis dieser Zeitschätzung sollten sie entsprechende Personalkapazitäten und ein Projekt budget vorsehen. Vergessen Sie dabei nicht, auch Zeit für redaktionelle Entscheidungsprozesse (neu zu schaffende Standards etc.) und für die Qualitätssicherung des migrierten Contents einzuplanen.

Sehen Sie sich zu Beginn des Projekts den Bestandscontent genau an und analysieren Sie, wel cher Anteil automatisiert migriert werden kann. Auch der Zeitaufwand für diese Analyse wird oft unterschätzt, der Anteil der automatisierbaren Contentbestandteile hingegen meist überschätzt. Nur selten lässt sich der Idealfall erreichen, dass 90% des Contents automatisierbar sind. Gelegentlich müssen Sie sich auch mit nur 50 % zufriedengeben. Es lohnt sich deshalb, einen Dienstleister mit der Sichtung des Contents zu beauftragen. Er kann die Contentqualität und Eignung für die automati sierte Migration zuverlässiger einschätzen und weiß, wie er das meiste aus dem Content herausholt.

Und ein letzter Rat: Geben Sie der Migration die Aufmerksamkeit, die sie verdient, denn erst wenn die Migration wirklich abgeschlossen ist, kann das neue Redaktionssystem sein Potenzial entfalten.