Sehr erfreulich ist, dass Atlassian einen Cloud Migration Assistant für Jira und Confluence entwickelt hat, welcher einen grossen Teil der Migration abnimmt. Es gibt gewisse Limitationen, aber grundsätzlich können die Vorgänge aus Jira und die Seiten aus Confluence migriert werden. Globale Konfigurationen und Einstellungen werden (Stand Januar 2023) nicht migriert.
Der Cloud Migration Assistant ist zum Teil aber auch ein wenig unberechenbar. Gewisses, was problemlos migriert wurde während der Testmigration, generiert dann Fehlermeldungen am Produktionstag, oder auch konnten Inhalte mit früheren Versionen des Assistenten fehlerfrei migriert werden, mit aktuellen Versionen muss für vergleichbare Inhalte ein anderes Migrationsvorgehen gewählt und mit Workarounds gearbeitet werden. Wir bei linkyard haben ein standardisiertes Migrationsvorgehen, das wir bei neuen Migrationsprojekten verwenden, sind aber auf unerwartete Abweichungen vorbereitet.

Ein zweiter Stolperstein können die verwendeten Plugins sein. Es gibt Plugins, die in der Atlassian Cloud nicht verfügbar sind. Hier müssen Alternativen gesucht werden und eine Migration der Daten in das Alternativplugin ist in den seltensten Fällen gewährleistet. Wenn die Plugins auch für die Cloud existieren, muss geprüft werden, wie die Daten in die Cloud übernommen werden können. Im besten Fall werden die Plugindaten mit dem Cloud Migration Assistant mitmigriert (z.B. als Attachment bei Gliffy). Im zweitbesten Fall wird vom Plugin ein Migrationspfad angeboten (z.B. bei draw.io) und die Daten können mit wenigen Klicks ebenfalls in die Cloud überführt werden. Wenn die Daten nicht wie in den soeben genannten Fällen migriert werden können, bleibt nur das manuelle Nachkonfigurieren und Erfassen der Daten (z.B. Scriptrunner), was je nach Plugins und deren Verwendung sehr aufwändig sein kann.
Wenn linkyard die Migration durchführt, sind wir bei den Plugins - vor allem bei solchen, die wir nicht verwenden, oder wir nicht wissen, wie sie in einer Firma genutzt werden - auf die Unterstützung der Kund:innen angewiesen und brauchen Informationen zur Arbeitsweise der Teams und Verwendung der Plugins.

Und somit kommen wir zum eigentlich zentralsten Punkt für die Migration: der Zusammenarbeit zwischen den Kund:innen und der linkyard. Die Migration soll immer als ein Projekt betrachtet werden, bei welchem von beiden Seiten entsprechend Zeit für die Arbeiten reserviert werden muss. Wir kennen nicht alle Instanzen und sehen die Besonderheiten nicht immer auf Anhieb. Deshalb sind wir angewiesen auf Erklärungen, wenn zum Beispiel ein spezielles Plugin in der Firma verwendet wird oder wie die Nutzenden verwaltet werden. Auch können mit ausführlichen Tests durch unsere Kunden Fehler bereits vor der produktiven Migration entdeckt und beseitigt werden, was dazu führt, dass bei der produktiven Migration die entdeckten Fehler vermieden oder rasch behoben werden können. So können die angepeilten Zeitpläne eingehalten werden.

Dies ist natürlich nicht eine vollständige Auflistung der Stolpersteine. Es gibt bspw. auch Confluence Makros, welche auf Server/Datacenter existieren, in der Cloud jedoch nicht existieren. Auch die Übernahme der Nutzenden in die Cloud muss nicht trivial sein, vor allem nicht, wenn eine AD-Anbindung verwendet wird oder eine solche in der Cloud neu verwendet werden soll.
Bei jeder Migration empfehlen wir, die gesamten Inhalte zuerst zu Testzwecken zu migrieren, zu analysieren und überprüfen, um dann optimal vorbereitet zu sein für die produktive Migration.