Seit einiger Zeit bietet Communardo einen Migrationsservice an, mit dem Daten aus vorhandenen Altsystemen nach Confluence migriert werden können. Dabei kommt das Produkt Content Import Plugin (CIP) zum Einsatz. Dieses Plugin ist als Testversion frei verfügbar und kann über das Atlassian Plugin Exchange herunter geladen werden. Über einen Online Shop ist zudem der Erwerb einer Volllizenz möglich. Somit können Kunden, die den Migrationsservice nicht in Anspruch nehmen möchten, selbst Migrationen durchführen.
Dieser Artikel beschreibt einige unserer bisherigen Erfahrung bei der Durchführung solcher Migrationen. Er richtet sich sowohl an Kunden, die eine solche Migration selbst durchführen möchten, als auch an Kunden, die unseren Migrationsservice nutzen möchten.
Vorgehen bei einer Migration
Migrationen mit dem CIP werden grundsätzlich zweistufig durchgeführt: Zunächst werden die Daten des Quellsystems in ein XML-Transportformat exportiert. Dieses wird anschließend mit dem CIP in das Confluence Zielsystem importiert.
Das Transportformat bildet dabei sämtliche Inhaltstypen (Bereiche, Seiten, Blogposts, Dateianhänge) samt Metadaten (Autor, Erstell- und Änderungsdatum) ab. Auch die Seitenhierarchie und interne Verlinkungen werden unterstützt.
Erwartungshaltung des Kunden vs. Machbarkeit
Unsere bisherigen Erfahrungen zeigen, dass von der Kundenseite häufig sehr hohe Erwartungen an die Migration gestellt werden. Diese beziehen sich meist auf die Punkte
- inhaltliche Vollständigkeit
- gleiches Aussehen
- Funktionalität bleibt erhalten.
Die inhaltliche Vollständigkeit kann mithilfe des Transportformats sichergestellt werden. Sämtliche Seiten und deren Inhalte können davon abgebildet und folglich nach Confluence migriert werden.
Allerdings ist es nicht möglich, die Darstellung der Informationen und eventuelle Funktionalität (JavaScript) verlustfrei zu migrieren. Die folgende Grafik verdeutlicht das prinzipielle Problem dahinter:
Die Kreise stellen den Darstellungs- und Funktionsumfang verschiedener Auszeichnungsformate dar. HTML bietet dabei den größten Funktions- und Variationsumfang. Mit Confluence Wiki-Code lassen sich viele Artefakte von HTML formulieren, wobei es auch zusätzliche Funktionalitäten gibt (z.B. Makros), die mit HTML nicht direkt umsetzbar sind. Ähnlich verhält es sich auch mit MediaWiki-Code.
Anhand dieses Diagramms wird klar, dass man Inhalte, die in einem MediaWiki vorliegen nicht verlustfrei nach Confluence migrieren kann, da MediaWiki Konzepte kennt, die nicht auf Confluence abbildbar sind (z.B. zusammengefasste Tabellenzellen). Ebenso lassen sich nicht sämtliche in HTML formulierbaren Inhalte nach Confluence migrieren (z.B. Definitionslisten).
In manchen Fällen können bei der Migration alternative Auszeichnungen gefunden werden, die eine ähnliche Darstellung ermöglichen. Beispielsweise könnten Definitionslisten in verschachtelte Listen umgewandelt werden. Für verschachtelte Tabellen hingegen gibt es derzeit keine Möglichkeit einer Abbildung in Confluence.
Ein weiteres Problem ist die Darstellung bestimmter Elemente. So kann eine Überschrift, die aus MediaWiki heraus migriert wird im Confluence vollkommen anders aussehen. Der Inhalt wurde dabei vollständig migriert, allerdings unterscheidet sich die Darstellung in beiden Systemen. Formatierungsanweisungen, die beispielsweise mit CSS im Quellsystem hinterlegt sind, können nicht migriert werden. Nur über die Entwicklung eines Confluence Theme Plugins ist es möglich, die Darstellung der Inhalte anzupassen.
Beispiele für Migrationsprobleme
Im Folgenden werden einige Probleme aufgelistet, die in den bisherigen Migrationsprojekten eine Rolle gespielt haben. Daran lässt sich recht gut erkennen, was eine Migration leisten kann, und wo die Grenzen der technischen Machbarkeit liegen.
Layouttabellen
Vor einigen Jahren war die Benutzung von Layouttabellen als Gestaltungsmittel von Webseiten vollkommen normal. Dies sind Tabellen, die keine sichtbaren Ränder aufweisen. So war es dem Autor einer Webseite leicht möglich, Inhaltselemente nebeneinander oder in einem definierten Raster anzuordnen. Auf diese Weise konnte beispielsweise die Seitennavigation neben die Inhaltsspalte gesetzt werden.
Da Confluence das Konzept von randlosen Tabellen nicht kennt, ist es nicht möglich derartige Layouttabellen ohne Darstellungsunterschiede zu migrieren. Die fehlende Unterstützung für verschachtelte Tabellen verschärft dieses Problem weiter.
Tabellen mit verbundenen Zellen
Mithilfe von HTML ist es möglich, einzelne Zellen einer Tabelle in horizontaler (colspan) oder vertikaler (rowspan) Richtung zu verbinden. Auf diese Weise können beispielsweise Tabellenköpfe erstellt werden, die sich über mehrere Spalten erstrecken.
Auch für derartige Zellverbünde bietet Confluence keine Formulierungsmöglichkeit. Zusammengefasste Tabellenzellen könnten demnach nur mit darstellerischen und inhaltlichen Verlusten überführt werden.
Manuell geschriebenes HTML
Als besonders schwerwiegend hat sich per Hand geschriebenes HTML herausgestellt. Viele Content Management Systeme verwenden sogenannte WYSIWYG-Editoren, um die Inhalte zu bearbeiten. Diese Editoren zeigen nicht den HTML-Code des Seiteninhalts an, sondern zeigen den Inhalt so, wie er später auf der Seite zu sehen sein wird. Diese Editoren haben den Vorteil, dass immer gleichartiges HTML generiert wird.
Für derartig generierte Inhalte können recht gute Migrationsmuster erkannt und entsprechend im Confluence abgebildet werden. Wurde der Seiteninhalt jedoch manuell geschrieben, ist der HTML-Code nicht gleichförmig. Solches Markup ist extrem schwierig zu migrieren, da dort prinzipiell der vollständige Funktionsumfang von HTML genutzt werden kann. Bei Migrationen, die manuell geschriebene HTML-Seiten als Quelle haben ist demzufolge mit beträchtlichen Darstellungsverlusten zu rechnen.
Interne Verlinkungen
Das Erkennen und korrekte Umwandeln von internen Verlinkungen kann sich mitunter äußerst schwierig gestalten. Mitunter sind schon die Verlinkungen des Quellsystems fehlerhaft, sodass diese nicht direkt ins Confluence übertragen werden können. Manchmal ist es notwendig, Ähnlichkeitsberechnungen mit den vorliegenden Links durchzuführen, um das "am besten passende Linkziel" auszuwählen.
Strukturierung der Informationen
Confluence bietet von sich aus folgende Möglichkeiten zur Strukturierung:
- Bereiche mit Seiten und Blogposts
- Seiten können Unterseiten haben (Baumstruktur)
- Seiten und Blogposts können Dateianhänge haben
Gibt es im Quellsystem Inhaltsstrukturen, die über diese hinaus gehen (z.B. mehrsprachige Inhalte), können diese nicht direkt auf die korrespondierenden Confluence-Typen abgebildet werden. Nur über die Nutzung oder Entwicklung weiterer Plugins (z.B. Communardo SubSpace Plugin für hierarchische Bereiche) ist eine Migration möglich.
Häufig sollen die Quelldaten zudem umstrukturiert werden. Durch das Einfügen generierter Übersichtsseiten und die Verteilung auf mehrere Bereiche wird die Komplexität zum Auflösen interner Verlinkungen weiter erhöht.
Unvorhersehbares Verhalten des Confluence-internen Wiki-Code-Konverters
Die Umwandlung von gegebenen HTML in Confluence-spezifischen Wiki-Code geschieht mittels einer internen Confluence-Componente (WysiwygConverter). Dieser hat erhebliche Probleme bei der Umwandlung von beliebigem (nicht vom WYSIWYG-Editor erzeugtem) HTML in Confluence Wiki-Code.
Schon kleinste Unterschiede im Quell-HTML-Code (z.B. Zeilenumbrüche, Verschachtelung von Elementen) können zu vollkommen verschiedenem Resultat führen. Insbesondere bei manuell geschriebenen HTML sind Migrationsverluste dadurch nicht zu vermeiden.
Zusammenfassung
Die Migration von Inhalten nach Confluence ist mit dem Content Import Plugin nahezu ohne Verluste möglich. Die Darstellung der Informationen muss jedoch an Confluence angepasst werden und unterscheidet sich folglich fast zwingend vom Quellsystem. Weiterhin ist es nicht möglich, Konzepte oder Funktionen nach Confluence zu migrieren, die im Quellformat verfügbar sind, sich jedoch nicht auf existierende Confluence-Konzepte abbilden lassen (verschachtelte Tabellen, Definitionslisten, …)
