© Roman Zaiets / 123rf.com

Atlassian, Hersteller des bekannten Knowledge-Management-Systems Confluence sorgt seit Jahren für Ärger unter seinen Kunden. Dass es auch anders geht, zeigen zwei Open-Source-Tools, die Unternehmen sogar beim Umstieg helfen.

Vor ein paar Jahren schockierte Atlassian, der Marktführer bei Knowledge-Management-Systemen, seine Kunden: Nur noch in der Cloud, so hieß es zunächst [1], solle man das bewährte Gespann aus Confluence (Wissensmanagement), Bitbucket (Versionsverwaltung) und Jira (Projektmanagement für IT-Projekte) nutzen können. Lokale On-Premises-Installationen beim Kunden gehörten schlagartig der Vergangenheit an, der Support dafür werde bald auslaufen. Obgleich Atlassian ein wenig zurückruderte, mussten sich kleine und mittelgroße Installationen auf gehörige Preissteigerungen einstellen. Ab Februar 2024 endete ganz offiziell der Support für den Confluence-Server.

Die damit einhergehenden Preissteigerungen, zahlreiche größere Sicherheitsvorfälle und das nicht immer perfekte Reagieren des australischen Herstellers darauf (“Vor diesem Ausfall hatten wir 99,9 Prozent Uptime!” [2]), gleichzeitige Milliardengewinne und Entlassungswellen (Rebalancing [3] genannt), aber auch grundsätzliche Datenschutzbedenken führten bisspätestens 2023 zu großem Vertrauensverlust und einer Welle von Migrationen. Immer wieder finden sich zusätzlich Berichte im Web, dass Atlassian oder Confluence/Jira-Zulieferer die Kunden der freien Versionen durch überraschende Einschränkungen zu kostenpflichtigen Varianten bewegen wollen [4].

Gründe gegen Atlassian

Die Hersteller von Konkurrenzprodukten, vor allem solche, die On-Premises installierbar oder in Open-Source-Software implementiert sind, berichten von dicken Auftragsbüchern, sowohl im Confluence- als auch im Jira-Markt. Zu den Firmen, die aus Kosten- oder Sicherheitsgründen migrieren wollen und verunsicherten oder verärgerten Kunden gesellen sich zusätzlich jene, die ihre Daten wegen Compliance-, KRITIS- oder anderer Regulierungen nicht in eine von einem Unternehmen mit Sitz außerhalb der EU betriebene Cloud umziehen können.

Australien, die Heimat von Atlassian, ist Mitglied der Five Eyes Alliance [5], steht also im direkten Kontakt mit NSA und anderen US-Diensten. Atlassian nennt seine Cloud erst gar nicht digital souverän – im Jahr 2018 hielt man seine Kunden an, keine Firmengeheimnisse in Trello hochzuladen und verbot ihnen, über die Cloud-Performance zu sprechen [1]. Im Juli 2024 tauchten Millionen Benutzerdaten in Internetforen auf. Vertrauensbildende Maßnahmen sehen anders aus. Kunden mit schützenswerten Informationen wie forschende Unternehmen aus der Hightech-Industrie, Steuerberater, Anwälte, Finanzdienstleister oder Beschäftigte aus Journalismus oder Politik suchen verstärkt nach Alternativen. Und die gibt es: In den letzten Jahren entstanden zahlreiche Marktübersichten [6], die Auswahl [7] ist groß, die Vielfalt [8] noch größer.

Ein Wechsel funktioniert, doch häufig erweist sich die Übernahme der Atlassian-Daten in ein neues System als komplexe Aufgabe. Was bei Jira weniger wichtig sein mag, – oft sind alte, erledigte Tasks uninteressant – spielt gerade bei den Confluence-Alternativen eine große Rolle. Jeder Administrator kennt den Begriff Vendor Lock-in: So manche Software läuft nur noch, weil es an einer Alternative fehlt, man nicht davon wegkommt und die Daten aus den alten Systemen nicht mehr herausbekommt. Für Hersteller ist das bares Geld, auch Open-Source-Firmen sind dagegen nicht gefeit, Unternehmen und Admins fluchen.

Wissen, wild gewachsen

Schon in kleinen Unternehmen wächst der Wissensbestand schnell, das interne Wiki, zu denen Mitarbeiter auch die Atlassian-Tools gern rechnen, wird komplex und unübersichtlich. Von Atlassian selbst können Anwender meist keine Hilfe beim Umzug erwarten, Confluence-Support-Dienstleister lassen sich die Hilfe selbstverständlich fürstlich entlohnen. Erschwerend kommt hinzu, dass Confluence anders arbeitet als die meisten Wikis: Es verwaltet einzelne Seiten in Arbeitsbereichen, hat eigene Zugriffsrechte und beherrscht untergeordnete Seiten sowie zahlreiche Makros.

Nicht alle Open-Source-Tools können da mithalten. Gut, dass dem Confluence-Administrator Export-Funktionen zur Verfügung stehen, die zumindest in der Lage sind, den gesamten Content beispielsweise in XML zu exportieren. Auf den ersten Blick klingt das gut, denn wer mit Skripten umgehen kann, kann früher oder später schon manuell gute Ergebnisse erzeugen. Doch der Teufel steckt im Detail und der meist großen Menge heterogener Daten.

Da trennt sich die Spreu vom Weizen, weil außer auf die Struktur der eigenen Wissensdatenbank zudem stark darauf ankommt, ob die neue Software beispielsweise Erweiterungen wie die Makros aus Confluence unterstützt, und ob Medien (meist Bilder und PDFs) korrekt übernommen werden. Dazu bieten Hersteller speziell angepasste Tools an. Von den Open-Source-Alternativen werben nur zwei mit einem Migrationsassistenten (XWiki und Bluespice), beide versprechen weitgehende Analysefunktionen und Support, der von Bluespice liegt sogar als Open-Source-Software auf Github zum Download vor und lädt zu kostenfreien Vorabtests ein.

XWiki

Das Java-basierte, im bundesdeutschen ZenDiS OpenDesk [9] eingesetzte französische XWiki stellt sein Migrationswerkzeug nicht als freie Software, sondern dauerhaft ausschließlich gegen Bezahlung zur Verfügung. Für 1900 Euro bekommt der Kunde das Confluence Migration Toolkit [10]. Interessenten können es 30 Tage kostenlos testen, nachdem sie einen Test-Key [11] eingegeben haben. Doch Achtung, bei Redaktionsschluss führte der Klick auf Sources im XWiki-Shop noch ins Leere (auch nach Monaten der Tests). Der Hersteller versprach immer wieder, das zu korrigieren.

Weil das Werkzeug noch recht jung ist, ist das Repository noch vergleichsweise leer, Spielzeuge zum Testen konnten die Autoren dort nicht finden. Auf Rückfrage bestätigte der Hersteller, dass für die Migration eine Reihe zusätzlicher Erweiterungen für XWiki notwendig seien, was sich im Github-Repository nachvollziehen lässt. Im Preis enthalten seien jedoch neben der Lizenz auch technischer Support für alle Pro-Apps, der Migrator, die Bridge Makros und der Task Manager.

Gegenüber dem Autor erklärte XWiki, eine “freie Lizenz” (Trial Licence) (Abbildung 1) für das Migration Toolkit gebe es jederzeit auf Anfrage. Dafür müsse der XWiki-Kunde lediglich seine Instance ID an den Hersteller schicken und unter Global Administration | Licences im Bereich Add Licence einfügen. XWiki bietet viele Ressourcen zum Nachlesen, das Blog enthält zahlreiche Artikel rund um Migration und die 60 unterstützten Confluence-Makros [12].

Abbildung 1: Den Migrationsassistenten von XWiki gibt es nur gegen Geld, das Github-Repository ist noch vergleichsweise leer. Der Anwender braucht einen Registrierungs-Key für den 10-Tage-Test und eine Reihe anderer XWiki-Erweiterungen.

Erfreulich ist, dass sich das XWiki-Migrations-Toolkit in die Weboberfläche von XWiki integriert und Anwender mit einem geführten Migrationsprozess lockt. Allerdings finden sich lediglich wenige Informationen, was Confluence-Kunden unternehmen können, wenn unterwegs Probleme auftreten. Insgesamt wirkt das Produkt stimmig, aber nur mithilfe von XWiki selbst erfolgversprechend umsetzbar.

Hallo Welt Bluespice

Anders macht das Hallo Welt aus Regensburg. Deren Produkt Bluespice ist eine Art Enterprise-Version von MediaWiki, also der Software, die die Wikipedia antreibt. Es ist wie die diversen Enterprise-Erweiterungen ebenfalls Open Source und auf Github erhältlich. Auch Hallo Welt rät Kunden dazu, sich bei der Migration begleiten zu lassen. Das mag dem Geschäftsmodell oder der Komplexität der Aufgabe geschuldet sein; vielleicht ist es in den meisten Fällen aber eben einfach unrealistisch, alles selbst und allein zu migrieren.

Mit Bluespice ist der Versuch dennoch möglich: Dank der Open-Source-Natur der Migrationsskripte können Anwender alles komplett ohne den Hersteller unternehmen, und bei manchen scheint das zu funktionieren. Im Internet kursieren Berichte oder Dokumentation darüber, wie Institutionen wie die NASA [13] oder die Universität Illinois [14] sogar die Migration zum freien Upstream-Projekt MediaWiki bewerkstelligten. Die Dokumentation für die Vorgehensweise hat Bluespice auf der Webseite veröffentlicht. Jeder Confluence-Admin kann hier Schritt für Schritt ausprobieren, was geht und wo es haken wird. Ein Test-Account oder Kontakt mit Hallo Welt ist zwar ratsam, aber nicht nötig.

Die Migration bei Bluespice läuft in fünf Schritten ab: Infrastruktur bereitstellen (Server, Storage, Netzwerk, Installation), Content extrahieren, Homogenität der Daten prüfen, Sprache und Medien korrigieren beziehungsweise integrieren. Dem initialen Makro-Check folgt der XML-Export aus Confluence und abschließend die eigentliche Migration – mit Datenimport.

Makros testen

Viele Confluence-Installationen nutzen eingebaute oder von Dritten programmierte Makros, um die Inhalte aufzubereiten, zu verknüpfen und darzustellen. Davon gibt es so viele, dass Bluespice oder XWiki nicht alle unterstützen können. Hallo Welt bietet auf seiner Webseite einen Test an, mit dessen Hilfe Administratoren herausfinden können, ob oder welche Makros bei der Migration unterstützt werden.

Die Prüfung umfasst vier Schritte: Über das Zahnrad oben rechts in Confluence öffnet der Administrator die Einstellungen zur Datenverwaltung und navigiert daraufhin in die Einstellungen für die Makroverwaltung. Im folgenden Dialog wählt er sämtliche Makros aus und kopiert sie mit [Strg]+[C] in die Zwischenablage. Auf der Bluespice-Webseite [15] nutzt er dann den Live-Makro-Check, wo er die gefundenen Makros mit [Strg]+[V] einfügt und auf Check klickt.

Sobald alle Makro-Probleme gelöst sind, geht es daran, einen ganzen Bereich von Confluence nach Bluespice zu überführen. Confluence kann Daten nach CSV, HTML, XML und PDF exportieren. XML (Abbildung 2) ist die beste Wahl, wenn es um strukturierte Datenmigrationen geht – im folgenden Beispiel ordentlich verpackt in einem Archiv.

Abbildung 2: In den Bereichseinstellungen von Confluence finden sich auch die Einstellungen zum Datenexport.

Der Admin extrahiert die Daten aus Confluence und hinterlegt das Archiv auf dem Bluespice-Server oder einem Arbeitsgerät. Dort richtet er die Unterverzeichnisse »input« und »workspace« ein und entpackt das Confluence-Archiv nach »input«. Jetzt gilt es, die Migrations-Tools aus Git zu holen und ihre Funktion zu testen. Sie brauchen beispielsweise das allseits bekannte Dokumentationsuniversalwerkzeug Pandoc und mehr (alles im Readme dokumentiert). Die Migrations-Tools bereiten die Daten so weit vor, dass sie sich importieren lassen; sie landen im Ordner »workspace/result/«. Schließlich kann der Admin das Migrationsskript aus Github [16] starten.

Migration starten

Das Migrationsskript »migrate-confluence.phar« müssen Sie viermal nacheinander aufrufen: Einmal zur Analyse der Daten (»analyse«), dann zum Extrahieren (»extract«), zum Konvertieren (»convert«) und letztlich zum Zusammenbauen im neuen Format (»compose«).

In den Abbildungen 3 bis**7 sehen Sie die genaue Syntax in Beispielen und das Feedback des Systems für einen einfachen Confluence-Bereich sowie das Ergebnis im Verzeichnisbaum. Den Parameter »–config=config.yml« bei der Analyse (Abbildung 3) braucht es lediglich in Fällen, in denen der Admin über eine solche YAML-Datei im Verzeichnis »input/« spezielle Konfigurationsoptionen definiert hat. Wer diese verwendet, muss sie bei den ersten drei Schritten zwingend angeben.

Abbildung 3: Das Migrationsskript »migrate-confluence.phar« analysiert die Daten.

Das Kommando aus der ersten Zeile von Listing 1 nimmt die Daten aus dem Verzeichnis »input/« und hinterlegt sie im Verzeichnis »workspace/« (Abbildung 4). Der Parameter »analyze« bereitet den Export vor. Der Parameter »-config=…« ist nur nötig, wenn die oben erwähnte optionale Konfiguration zum Einsatz kommt. Ansonsten können Sie diesen Codeteil einfach weglassen. Die restlichen Zeilen geben Aufschluss über den exportierten Content.

$ php migrate-confluence.phar analyze --src=input --dest=workspace
$ php migrate-confluence.phar extract --src=input --dest=workspace --config=config.yml
$ php migrate-confluence.phar convert --src=workspace --dest=workspace --config=config.yml
$ php migrate-confluence.phar compose --src=workspace --dest=workspace

Im zweiten Schritt nimmt der Aufruf auf der zweiten Zeile die aus Confluence exportierten und analysierten Daten und hinterlegt sie in der »destination«, im Beispiel im Verzeichnis »workspace/«. Danach übernimmt der Befehl aus der dritten Zeile von Listing 1 die Daten aus »workspace/« und wandelt sie dort in ein für Bluespice importierbares Format um (Abbildung 4).

Abbildung 4: Das Migrationsskript »migrate-confluence.phar« wandelt das Format der Daten um.

Nun finden sich im Verzeichnis »workspace/« meist zahlreiche Raw-Dateien mit dem aufbereiteten Confluence-Export. Als letzter Schritt dient die Option »compose« (Listing 1, Zeile 4) zum Zusammenbauen der verschiedenen Elemente. Das Kommando »compose« setzt die aus Confluence extrahierten Rohdaten zusammen und hinterlegt sie als XML-Dateien (Abbildung 5). Unter »workspace/result/« findet der Anwender den erfolgreich umgewandelten Export (Abbildung 6).

Abbildung 5: Die Option »compose« baut die Daten wieder zusammen, jetzt aber für Bluespice.

Abbildung 6: Das finale Ergebnis landet im Ordner »workspace/result«.

Hat bis hierhin alles geklappt, kann der Admin in Bluespice die notwendigen Namensräume (Abbildung 7) anlegen, die Unterstützung für Dateitypen (über deren Dateiendungen realisiert) überprüfen und Bilder importieren. Welche Namensräume er benötigt, sieht er entweder während des »analyze«-Durchlaufs in der Ausgabe des Skripts oder aber direkt in der Datei »workspace/result/output.xml«. Unter Linux genügt dazu ein simpler Grep-Befehl:

$ grep -in "<"title>" workspace/result/output.xml

Damit erhält der Admin eine Liste mit sämtlichen Titeln und Namespaces, beispielsweise »Management:Arbeitsanweisung«. In der auch bei Bluespice verwendeten Wikipedia-Syntax ist dabei »Management« der Namensraum, getrennt durch einen Doppelpunkt vom Seitentitel »Arbeitsanweisung«. Die gefundenen Namensräume sollte der Admin nun in der Spezialseite »Spezial:NamespaceManager« alias »Namensraumverwaltung« anlegen.

Abbildung 7: In der Namensraumverwaltung des Bluespice-Wikis müssen vor dem Import die benötigten Namensräume angelegt sein.

Dateiformate und -endungen

Außerdem muss der Administrator in der Konfigurationsverwaltung (»Spezial:BluespiceConfigManager«) des Wikis sicherstellen, dass alle benötigten Dateiendungen erlaubt sind, also sämtliche Medien und Dateiformate, die vorher im Confluence eingebettet waren. Der Bluespice-Import erfolgt selektiv: Dateien aus dem Verzeichnis »workspace/result/images/« werden nicht importiert, wenn sie eine andere Dateiendung haben als die in Abbildung 8 aufgelisteten.

Abbildung 8: In der Konfiguration von Bluespice muss der Administrator sicherstellen, dass alle in Confluence verwendeten Mediendateiformate unterstützt werden.

Import und Erfolgskontrolle

Jetzt geht es daran, die Confluence-Daten auf den Bluespice-Server zu kopieren, beispielsweise in dessen »/tmp«-Ordner. Die Abbildung 9 zeigt im Installationspfad des Wikis die Ausgabe des Kommandos für den Datenimport, jeweils eine Zeile pro Datei.

Abbildung 9: Der Datenimport der Mediendateien auf dem Wiki-Server ist gelungen. Jede Zeile steht für eine Mediendatei, die er erfolgreich importiert hat.

Im letzten Schritt, dem »ImportDump«, zieht der Migrationsassistent noch die Inhalte selbst aus der XML-Datei von Confluence in seinen Datenbestand. Der Code aus der ersten Zeile von Listing 2 erledigt das. Sobald alle Daten aus Confluence importiert wurden, frischt das Kommando aus der zweiten Zeile verschiedene Tabellen auf, die zum Beispiel Verlinkungen für Bilder enthalten. Der Aufruf für die Aktualisierung des Suchindex findet sich in der dritten Zeile.

Nun sollte der Administrator den Befehl aus der letzten Zeile ausführen, der angefallene Aufgaben abarbeitet. Bei vielen Migrationen ist das mehrmals notwendig, weil einzelne Schritte neue Aufgaben auslösen. Am Ende steht die visuelle Erfolgskontrolle, also die Gegenüberstellung von Alt und Neu mit einem Check der Inhalte.

$ php maintenance/importDump.php /tmp/result/output.xml
$ php maintenance/rebuildall.php
$ php extensions/BluespiceExtendedSearch/maintenance/rebuildIndex.php
$ php maintenance/runJobs.php

Fazit: durchaus machbar

Die beiden wichtigsten Open-Source-Alternativen zu Atlassian bieten Umzugshelfer für Atlassian Confluence an. Obwohl die Strategien von XWiki und Hallo Welt sich unterscheiden, eint sie doch eines: Nur selten wird die Migration eines komplexen, historisch gewachsenen Knowledge-Management-Systems reibungslos und automatisch funktionieren. Im Gegenteil: Fast immer erfordert sie manuelles Nacharbeiten und Handanlegen, gerade, wenn es beispielsweise um Benutzer- und Metadaten geht.

XWiki bietet eine integrierte Oberfläche für die Migration an, legt Anwendern Hilfestellung deutlich nahe und lässt ihnen wenig Freiheiten. Bluespice dagegen punktet mit komplett freier Software und Standard-Tools. Das geht so weit, dass man sogar die Migration zum Upstream-Projekt MediaWiki ermöglicht, selbst wenn dem Hersteller dann Kunden durch die Lappen gehen. Aber ganz grundsätzlich gibt es auch bei Hallo Welt die Option, die Migration mit Hersteller-Support durchzuziehen.

Egal, für wen man sich entscheidet: Sich unter die Arme greifen zu lassen, scheint bei Knowledge-Management-Migrationen nie eine schlechte Idee zu sein. (csi)