Bestehende Intranet- und Wiki-Systeme im Unternehmen haben Inhalte. Wenn es darum geht, eine Confluence-Plattform oder ein Confluence-basiertes Intranet wie Linchpin neu einzuführen, wünschen sich viele Kunden, dass ihre bestehenden Informationen in die neuen Tools übernommen werden, und suchen nach einer Migrationsstrategie.
Das Idealbild sieht ungefähr so aus: Ein Software-Tool wird aufgesetzt und konfiguriert, dann drückt man einen Button - und schon rollt der saubere Export und Import der Daten. Nach einer Weile ist alles ordentlich in Confluence, Problem gelöst. Das ist eine sehr schöne Vorstellung. Leider ist sie in der Praxis nicht umsetzbar.
Der Stand der Dinge ist, dass es keine automatisierten Migrationslösungen gibt, die gute Resultate bringen, selbst wenn man iterativ vorgeht, Entwickler einbindet und die Datenübernahme mehrmals wiederholt. Zahllose Seiten werden zerschossen sein, Anhänge sind nicht korrekt eingebunden, die Berechtigungskonzepte unterscheiden sich von System zu System - die Fehlerquellen sind vielfältig und ungelöst. Kurz: Eine Intranet-Migration auf Knopfdruck lässt sich in der Realität nicht sauber und zufriedenstellend abbilden.
Es gibt alternative Vorgehensweisen. Allerdings sind sie alle mit etwas Aufwand verbunden, und ohne gewisse Schmerzen ist leider keine davon zu haben.
Die Inhalte im Altsystem abhaken und neu anfangen
Der erste Vorschlag ist radikal: Ziehen Sie einen Schlussstrich und fangen Sie im Neusystem bei Null an! Es werden keine Inhalte migriert. In der Legacy-Instanz wird das Licht ausgemacht und die Leute arbeiten von nun an mit Confluence oder dem neuen Confluence-Intranet.
Im Tagesgeschäft dürfte das für die Teams gar kein Problem sein. Die Vor- und Nachbereitung von Meetings erfolgt jetzt eben hier statt dort. Sie starten mit einem schlanken, sauberen System, sie können sich von Anfang an die vielen Möglichkeiten zunutze machen, die ein Confluence-Intranet mit seinem Weltklasse-Editor bietet, das System kann organisch wachsen.
Die Nachteile dieses Vorgehens liegen jedoch auf der Hand. Informationen, die dauerhaft benötigt werden, sind plötzlich nicht mehr verfügbar - all die Prozessinformationen, Software-Dokus, Onboarding-Inhalte usw. Die Mitarbeiter müssen längerfristig relevante Inhalte teils neu zusammentragen und dokumentieren. Viele Infos, die bereits früher erstellt wurden, müssen nun erneut entstehen und wachsen. Letztlich verringert sich vorübergehend die Informationsverfügbarkeit. Aus Anwendersicht sinken damit auch die Relevanz und der Nutzen im Vergleich zum Altsystem. Das ist durchaus gefährlich für die Mitarbeiterakzeptanz.
Manueller Import
Eine zweite Option ist die Datenmigration per Hand. Vielleicht rekrutieren Sie für so ein Projekt ein paar Studenten als Datenpfleger und nach der Einweisung in die Möglichkeiten und Funktionen des Confluence-Intranets geht dann alles seinen Gang.
Das ist in erster Linie eine Fleißaufgabe: Jemand kopiert Seite für Seite vom Altsystem in das neue Confluence und repariert dabei gegebenenfalls die Strukturierung, lädt vielleicht die Anhänge neu hoch, prüft die Links, vergibt gleich noch die richtigen Schlagwörter etc. Eventuell nimmt dieser Team sogar direkt Verbesserungen vor und macht sich die hilfreichen Zusatzfunktionalitäten zunutze, die Confluence von Haus aus bietet.
Der Vorteil: Sie werden alle Ihre Inhalte aus dem Altsystem akkurat aufbereitet und vollständig in der neuen Instanz zur Verfügung haben - womöglich sogar in besserer Form als zuvor. Das dauert zwar seine Zeit, aber die Ergebnisse sind bestmöglich.
Der erste Nachteil: Bei mehreren tausend oder zehntausend Seiten brauchen Sie eine gewisse Manpower und haben entsprechende Zusatzkosten. Und in diesem Zusammenhang wird es bei vielen Kunden sicher auch KO-Kriterien geben, was das Hinzuziehen externer Mitarbeiter betrifft: Nicht jede Organisation wird eine Handvoll Studenten mal eben auf all die internen Unternehmensinformationen loslassen. Dann wird das Intranet-Team wohl nicht darum herumkommen, intern Unterstützung für diese Fleißarbeit zu rekrutieren, und interne Ressourcen sind oft genug knapp.
Der zweite Nachteil: Es gibt im neuen System von Anfang an einen Haufen Müll mitsamt der negativen Begleiterscheinungen. Wenn alles kopiert wird, werden auch all die redundanten, veralteten und fehlerhaften Inhalte aus dem Legacy-System übernommen - und die damit verbundenen Effizienzprobleme gleich mit: längere Suchzeiten, unklare Suchergebnisse, Unsicherheit beim Erstellen von neuen Seiten. Das sind eigentlich keine günstigen Startbedingungen.
Parallelbetrieb beider Instanzen
Die Strategie, das neue und das alte System parallel laufen zu lassen, ist eine sehr organische Alternative und schafft die Voraussetzungen für einen sanften Übergang ohne Druck. Die Mitarbeiter werden ermutigt, auf der neuen Plattform zu arbeiten, aber das Bestandssystem bleibt währenddessen mit allen Funktionen voll verfügbar. Für das Ende des alten Intranets gibt es keinen festen Termin. Währenddessen bietet das Intranet-Team Unterstützung beim Confluence-Onboarding und bei der manuellen Migration von Informationen, die die Teams brauchen.
Nach einer großzügig bemessenen Zeitspanne kann sich das Intranet-Team die Nutzungsstatistiken vornehmen und schauen, ob auf der alten Plattform überhaupt noch jemand zugange ist. Es gibt noch einmal eine Ankündigung, sodass auch die Nachzügler (die es gewiss geben wird) Bescheid wissen und sich mit der neuen Lösung auseinandersetzen. Dann wird das alte Intranet abgeschaltet.
Dieser Ansatz ist langfristig - und auch derjenige, der in manchen Intranet-Teams ein gewisses Unwohlsein verursachen wird. Denn es ist ja möglich, dass sich die Dinge überhaupt nicht so entwickeln wie gewünscht: Die Mitarbeiter nutzen einfach weiterhin das gewohnte System und ignorieren das neue. Oder sie nutzen gar keins von beiden. Dann gerät das Team in Erklärungsnot.
Ein anderer offensichtlicher Haken ist hier der Kostenaspekt. Ein Parallelbetrieb bedeutet oftmals auch Lizenzgebühren (und gegebenenfalls Betriebsaufwand) an zwei Fronten - in diesem Fall vielleicht sogar auf Jahre hinaus. Das ist nicht in jeder Organisation gut vermittelbar. Wir kennen Projekte, in denen die eingesparten Lizenzkosten für das Legacy-System eigentlich ja das neue Confluence-Projekt finanzieren sollen.
Parallelbetrieb mit Legacy-System im Read-only-Modus
Diese Strategie basiert ebenfalls auf dem Parallelbetrieb von Alt- und Neusystem, allerdings einem vorübergehenden. Falls das Legacy-System ein entsprechendes Feature bietet (oder wenn das Berechtigungskonzept es ermöglicht), kann es sinnvoll sein, die Instanz in den Lesemodus zu schalten, sodass die Leute zwar Zugriff haben, aber keine Bearbeitungen mehr vornehmen und keine neuen Informationen einstellen können. Dafür gibt es nun Confluence bzw. das neue Confluence-Intranet. Wenn ein Team einen bestehenden Inhalt braucht, übernimmt es diesen einfach ins neue System und arbeitet dort damit weiter.
Auch hier sollte sich das Intranet-Team den Hut für die Förderung der Transition aufsetzen. Eventuell ist es sinnvoll, eine kleine Redaktionsmannschaft abzustellen, die die Mitarbeiter beim Umziehen von Inhalten und bei der Neuaufbereitung mit den Confluence-Bordmitteln unterstützen kann.
Zudem könnte das Team erwägen, etwas sanften Druck auszuüben und den offiziellen Abschalttermin für das Legacy-System immer wieder zu kommunizieren, beispielsweise in Form von Intranet-News und Community-Beiträgen im Intranet-Microblog:
"Liebe Kolleginnen und Kollegen, bitte denkt daran: Bis zum 30. Juni solltet ihr die Informationen, die ihr weiterhin braucht und haben wollt, ins neue Intranet umgezogen haben. Wenn ihr dazu Fragen habt oder dabei Hilfe braucht, wendet euch an das Intranet-Team."
Nach und nach werden die Mitarbeiter die Inhalte, die für ihre Arbeit relevant sind, in Eigenregie übernehmen. Diejenigen Informationen im Bestandssystem, die in diesen drei oder sechs Monaten nicht auf organische Weise migriert werden, sind dann irgendwann verloren. Kein Mensch wird sie je vermissen.
Doch auch hier sitzt dem Team der Lizenz- und Betriebskostenaspekt im Nacken.
Statischer Export des Bestandssystems
Bei diesem Vorgehen besteht das Ziel darin, die Informationen aus dem bestehenden System auf andere Weise verfügbar zu machen, ehe Sie den Stecker ziehen. Confluence bietet beispielsweise die Möglichkeit, die gesamte Instanz ins HTML-Format zu exportieren. Andere Systeme haben vermutlich ebenfalls Optionen für einen statischen Export.
Damit haben Sie einen exportierten Schnappschuss, den Sie zum Beispiel intern als HTML-Seite bereitstellen können, sodass alle Inhalte weiterhin zur Verfügung stehen. Aber wie im vorherigen Beispiel können User diese Daten nicht mehr bearbeiten und auch nicht mehr mit dem System interagieren. Es gibt ja keine Software mehr.
Die Mitarbeiter haben dann wiederum die Gelegenheit, die Inhalte, die sie brauchen und an denen sie weiterarbeiten wollen, selbständig und selbstregulierend (mit Unterstützung durch das Intranet-Team) auf die neue Plattform umzuziehen.
Termin- und Kostendruck besteht in diesem Fall zwar nicht. Doch viele Teams scheuen trotzdem davor zurück, einen selbstregulierenden Ansatz zu wählen und die Mitarbeiter aktiv in die inhaltliche Migration einzubeziehen. Diese Strategien erfordern Zeit, es bestehen zumindest vorübergehend Herausforderungen bei der effizienten Informationsbeschaffung und letztlich werden auch immer wieder Ressourcen für redaktionelle Arbeiten gebunden.
Alle genannten Ansätze sind Tradeoffs mit Vor- und Nachteilen. Einen Königsweg gibt es ebensowenig wie eine gescheite Lösung auf Knopfdruck. Für welchen Weg sich ein Unternehmen entscheidet, hängt stark von den Rahmenbedingungen des Projekts, von den gewünschten Startvoraussetzungen der Confluence-Lösung und und auch vom Grad der Eigenverantwortlichkeit ab, die die Mitarbeiter in der Organisation haben.
Konsequent einen Schlussstrich zu ziehen und bei Null anzufangen, mag in spezifischen Szenarien effektiv sein, doch die Gefahren kann man nicht ignorieren. Die manuelle Migration ist das aufwendigere Pendant zur automatisierten Migration: Sie bringt ein vollumfängliches und gutes Ergebnis, aber das System ist auch von vornherein mit Mist vollgestopft.
Meine Empfehlung würde lauten: Lassen Sie es Ihre Mitarbeiter in einem selbstregulierenden, pragmatischen Prozess selbst machen, wobei ihnen Ihr Intranet-Team fleißig unter die Arme greifen sollte. Die Leute, die das System täglich nutzen, wissen am besten, was sie brauchen und was nicht.
Ihr Partner für Atlassian Confluence
Haben Sie Fragen zu Atlassian Confluence oder Intranet-Lösungen auf Confluence-Basis? Denken Sie über ein Einführungsprojekt nach oder möchten Sie ein bestehendes System optimieren oder erweitern? Wir sind Atlassian Platinum Solution Partner und unterstützen Sie gerne bei allen Aspekten rund um eine erfolgreiche Einführung: Lizenzierung, Anpassung, Plugin-Entwicklung, Betrieb und Support. Melden Sie sich bei uns!
Weiterführende Infos
Linchpin - Social Intranet mit Confluence
Hürden bei einer Firmenwiki-Migration zu Confluence und warum es sich lohnt, sie zu überspringen
Warum ein Intranet einen Weltklasse-Editor braucht
Welche Wiki-Software ist die richtige? Ergebnisse einer Studie
Mehr über die Creative-Commons-Lizenz erfahren
