Was Sie von unserer eigenen Confluence-Cloud-Migration lernen können

Offiziell gibt es bei einer Cloud-Migration viele Punkte zu berücksichtigen wie beispielsweise die Migration der einzelnen User und ihrer E-Mail-Adressen oder die Evaluation von Apps, die wichtige Funktionen in der Cloud übernehmen. Atlassian liefert umfangreiches Material wie zum Beispiel Checklisten für jeden erforderlichen Schritt.

Hauptschritte unserer Confluence-Cloud-Migration

In unserem Fall hatten wir wenige technische Bauchschmerzen, da die Migration von unserem CTO Oliver Sträßer durchgeführt wurde. Wir konnten uns so stärker auf die eigentlichen Inhalte und das Erlernen der neuen Cloud-Umgebung fokussieren.

Unsere Hauptpunkte:

1. Entscheiden, welche Inhalte migriert werden sollen.
2. Sich von liebgewonnenen (selbst gemachten) Makros verabschieden.
3. Die eigentliche Migration durchführen.
4. Die Vorzüge und Tücken des Confluence-Cloud-Editors kennenlernen und Inhalte vom Legacy-Editor in den neuen Cloud-Editor überführen.
5. On-Premise-Funktionen und -Makros in Cloud nachbauen.

Dieser Beitrag behandelt die Punkte I bis III. Der zweite Artikel ist dem Cloud-Editor gewidmet, während der dritte und letzte Teil die Funktionen und Makros in der Cloud aufgreift.

Welche Inhalte sollen migriert werden?

Atlassian streicht es im Leitfaden zur Cloud-Migration klar heraus: Es ist wichtig, den Inhalt Ihres bestehenden Systems zu bewerten und zu entscheiden, welche Inhalte es überhaupt wert sind, migriert zu werden. Denken Sie daran, dass jede Seite mit einem benutzerdefinierten Benutzermakro oder einem App-spezifischen Makro mühsam zu migrieren ist (mehr dazu später).

Datengestützter Inhalts-Audit

Es ist sehr wichtig, sich selbst zu fragen: Macht diese Seite noch Freude? Ist sie noch relevant resp. wird sie noch häufig gelesen? Diese Bewertung kann für Content-Manager und technische Redakteure, denen ihre Inhalte sehr am Herzen liegen, eine schmerzhafte Aufgabe sein. Anstatt sich in emotionale Debatten darüber zu stürzen, welche Inhalte bleiben können und welche verschwinden sollten, ist es besser, sich auf harte Fakten zu konzentrieren:

Welche Inhalte werden am häufigsten aufgerufen? Da die bitvoodoo-App-Dokumentation öffentlich zugänglich ist, interessierten uns vor allem die Seitenaufrufe durch externe (=anonyme) Nutzer.

• Welche Inhalte werden geliked, kommentiert oder beobachtet? (Nun gut, die Dokumentation ist natürlich kein Ort, an dem sich User freiwillig lange aufhalten. Dennoch gibt es ab und zu Likes und Kommentare und eine Seite wird beobachtet, weil sie besonders relevant scheint.)

   

• Um diese Informationen zu erhalten, konnten wir auf unsere eigene App Viewtracker zurückgreifen. So gingen wir vor, um Seiten mit relativ wenigen Aufrufen zu finden:

•  
•  

1. Wir riefen den Content & Usage Report im Analytics Cockpit auf.

2. Wir setzten den eingebauten Filter auf “content with fewer than 20 views” (Inhalt mit weniger als 20 Seitenaufrufen). Warum gerade 20? Wir legten eine Mindestanzahl von 20 Aufrufen pro Seiten fest, um eine Seite als relevant einzustufen. Dies ist eine willkürliche Zahl und kann in Ihrem Fall natürlich ganz anders sein.

1.  
2. 3. Wir setzten den Datumsbereich auf "This year” (Dieses Jahr), um Daten von mehreren Monaten zu sammeln.
   Die kombinierten Filter ergaben eine übersichtliche Tabelle von Seiten, die dieses Jahr erst weniger als 20 Aufrufe erzielt haben.
3.  
4.  

 4. Wir schauten uns die Seiten in dieser Liste genauer an und eliminierten diverse davon.

 

Natürlich hätten wir auch ganz andere Filter setzen können, um z.B. die Inhalte mit den meisten Aufrufen, solche ohne Edits oder nur neu erstellten Inhalt anzuzeigen und daraus Schlüsse für die Migration zu ziehen. All dies ist mit dem Content & Usage Report von Viewtracker möglich. Wenn Sie sich dafür interessieren, empfehlen wir den Beitrag auf unserem englischsprachigen Blog.

 

Nebeneffekte des Audits

Die Überprüfung der Inhalte hatte einige willkommene Nebeneffekte:

• Wir fanden Inhalte, die immer noch relevant waren, auf die aber stärker verlinkt werden musste.

• Der Inhalt einiger Seiten hätte längst in andere Seiten überführt werden können (und sollen). Nun konnte dies endlich angegangen werden.

• Wir stiessen auf Seiten, die schon seit Jahren nicht mehr bearbeitet oder aufgerufen wurden. Es war an der Zeit, sie ein für alle Mal zu löschen.

• Wir fanden sogar Seiten mit bestehenden Zugriffseinschränkungen, die schon vor Monaten hätten entfernt werden müssen. Nun konnten wir sie endlich unseren Kund:innen zugänglich machen.
  
  

Die Überprüfung war zwar zeitaufwändig und nicht immer spannend. Wir sind uns aber sicher: Die Zeit für diesen späten Frühjahrsputz hat sich gelohnt.

Sich von lieb gewonnenen (selbst gemachten) Makros verabschieden

Nun hatten wir also die relevanten und migrationswürdigen Seiten beisammen. Allerdings gab es ein Problem: Auf unzähligen dieser Seiten hatten wir Elemente unserer eigenen App Enterprise Theme im Einsatz (u.a. Buttons und Tabs). Enterprise Theme ist nicht verfügbar auf Confluence Cloud (denn Cloud unterstützt diese Elemente nicht), sodass es bei einer Migration zu unzähligen Fehlermeldungen “unknown macro” kommen würde. Dies wollten wir verhindern und daher bereits auf Data Center die entsprechenden Makros loswerden.

 

Ein Blick in die Macro-Usage-Statistik gab dann ein genaueres Bild, welche Makros wie oft verwendet wurden (siehe folgender Auszug).

Für die meistverwendeten dieser Makros mussten wir eine andere Lösung finden. Oft konnten wir auf Standard-Makros zurückgreifen, die einen ähnlichen Funktionsumfang hatten (z.B. Panels). Die bestehenden Tabs ersetzten wir mit Makros aus unserer Navitabs-App, die auch auf Cloud funktionieren. Andere Elemente wie Boxen in der Seitenleiste können in Confluence Cloud ohnehin nicht verwendet werden; diese deaktivierten wir daher vor der Migration. In Confluence Cloud gibt es alternative Möglichkeiten für Verlinkungen auf andere Systeme (mehr dazu in Teil 3 dieser Reihe).

Einige dieser Schritte erforderten manuelle Anpassungen der Seiteninhalte. Andere Makros konnten automatisiert mit “Search and replace” in allen betroffenen Spaces ersetzt werden.

Migration

Die Migration selbst war, im Gegensatz zur ganzen Vorarbeit, eine kurze Sache. Innert einiger Stunden wurden die Dokumentations-Spaces und die Appdaten mit dem Migrationsassistenten in die Cloud migriert. Die benötigten bitvoodoo-Apps Viewtracker, Navitabs, Translations und Advanced Panelboxes haben allesamt einen automatisierten Migrationsprozess.

Atlassian bietet eine grosse Fülle an Materialien zur Migration selbst, daher gehen wir hier nicht ins Detail. Im "data migration progress" Report konnten wir jederzeit den Stand der Migration nachverfolgen.

Wie geht es weiter?

Nachdem die Inhalte bereinigt und erfolgreich migriert worden sind, geht es nun darum, den neuen Confluence-Editor und die vielen praktischen Funktionen von Confluence Cloud kennenzulernen.

Warum Sie Ihre Atlassian-Cloud-Migration jetzt angehen sollten

Wie anfänglich erwähnt: Eine Cloud-Migration ist kein Selbstläufer und braucht beträchtliche zeitliche Ressourcen. Die Zusammenarbeit mit kompetenten Atlassian-Partnern hilft, unnötige Fehler und Verzögerungen zu verhindern. Das Beratungsteam von bitvoodoo hat schon unzählige Migrationen begleitet und verhilft auch Ihrem Migrationsprojekt gerne zum Erfolg.

Weshalb Sie bei Ihrer Cloud-Migration auf bitvoodoo als Partner setzen sollten:

• Zeitersparnis: Sie können von unseren Erfahrungen bei früheren Migrations-Projekten profitieren. Wir halten uns über die neuesten (technischen) Veränderungen stetig auf dem Laufenden und kennen unterdessen gewisse Abkürzungen.

•  

• Kontakt zu Atlassian: Falls es doch zu akuten Problemen kommen sollte, haben wir als Atlassian-Partner einen direkten Draht zu deren Support und können für schnelle Abhilfe sorgen.

•  

• Vermeidung von Ärgernissen: Dank unserer Erfahrung kennen wir mögliche Stolpersteine und denken aktiv mit, damit Ihre Cloud-Migration möglichst reibungslos über die Bühne geht.

•