Migracja Jira i Confluence on-premise → Cloud: co poszło nie tak

Migrację Jira Server i Confluence Server do wersji Cloud robiłem u obecnego pracodawcy w całości — od pierwszego audytu instancji, przez próbne migracje, po właściwe okno migracyjne w weekend. Atlassian od dawna popycha wszystkich w tym kierunku, kończąc wsparcie dla Server, więc to nie był wybór z ciekawości, tylko konieczność z twardym terminem. Ten wpis to nie recenzja narzędzia Atlassian Cloud Migration Assistant — to lista rzeczy, które faktycznie sprawiły problem, i tego, jak je obeszliśmy.

Audyt przed migracją

Zanim cokolwiek ruszyło, spędziłem dobre dwa tygodnie na inwentaryzacji tego, co w ogóle siedzi w instancji. To był najbardziej niedoceniany etap całej pracy — bez niego migracja rusza w ciemno i wszystkie problemy wychodzą dopiero w oknie migracyjnym, kiedy najmniej jest na nie czasu.

Wtyczki (plugins/apps) — lista wszystkiego zainstalowanego na Server, z adnotacją, czy dany dodatek ma odpowiednik w Marketplace na Cloud. Kilka miało — ale z inną nazwą, innym modelem licencjonowania i częściowo innym zestawem funkcji.
Custom fieldy — ile ich jest, które są używane realnie, a które to relikty projektów sprzed lat. Migracja kopiuje wszystko, więc lepiej posprzątać przed, niż przenosić bałagan jeden do jednego.
Workflow — screeny każdego customowego workflow z warunkami przejść i post-funkcjami, bo część post-funkcji od dodatków Server po prostu nie istnieje na Cloud.
Permission schemes i grupy — kto ma dostęp do czego, jak zmapowane są grupy AD/LDAP na grupy w Jira, i czy w ogóle wszyscy użytkownicy mają już konta Atlassian (SSO trzeba było spiąć wcześniej, nie w trakcie).
Rozmiar załączników — bo to on w praktyce dyktuje długość okna migracyjnego, nie liczba ticketów.

Cloud Migration Assistant nie jest jednym kliknięciem Narzędzie od Atlassiana (CMA) robi dużo dobrej roboty automatycznie, ale to nie jest przycisk „migruj i zapomnij”. Sam decyduje, co pominąć po cichu, jeśli coś nie ma odpowiednika w Cloud — i jeśli nie sprawdzisz logów po migracji próbnej, dowiesz się o tym od użytkownika, który zgłosi brakujący załącznik tydzień po starcie.

Załączniki — największy koszt czasowy

Confluence po latach działania miał kilkadziesiąt gigabajtów załączników — screeny, PDF-y specyfikacji, eksporty z narzędzi zewnętrznych. CMA migruje je przez API, a nie przez bezpośredni transfer plików, co oznacza, że prędkość ograniczona jest rate limitem API Cloud, nie przepustowością łącza. Pierwsza próbna migracja testowego zestawu danych pokazała realny czas — ekstrapolacja na pełen wolumen wyszła grubo poza jeden weekend, gdybyśmy migrowali wszystko naraz.

Rozwiązaniem było rozbicie migracji na fale: najpierw projekty aktywne i przestrzenie używane codziennie, osobno archiwalne projekty sprzed lat, które mogły poczekać do kolejnego okna. Nie każdy klient to akceptuje, ale u nas archiwalna dokumentacja nie musiała być dostępna od pierwszej minuty po starcie Cloud.

Fala 1 (weekend startowy):
  - projekty aktywne w Jira (sprint w toku)
  - przestrzenie Confluence z edycją w ostatnich 90 dniach
  - użytkownicy aktywni + ich grupy uprawnień

Fala 2 (+2 tygodnie):
  - projekty zamknięte / archiwalne
  - przestrzenie referencyjne (bez edycji od >1 roku)
  - historyczne załączniki >50MB, przenoszone osobno przez skrypt

Uprawnienia — tu boli najbardziej

Model uprawnień w Cloud różni się od Server na tyle, że jeden do jednego mapowanie nie zawsze ma sens. Server pozwalał na bardzo drobiazgowe permission scheme per projekt, z grupami LDAP mapowanymi ręcznie. Cloud wprowadza swój własny model organizacji i site'ów, z rolami produktowymi (Jira admin, Confluence admin, org admin) na innym poziomie niż permission scheme projektu.

Największy błąd, jaki widziałem w trakcie próbnej migracji: grupa, która na Server nazywała się tak samo jak istniejąca już grupa w Atlassian Cloud (bo ktoś wcześniej zakładał tam testowe konto do innego narzędzia Atlassiana), i migrator scalił uprawnienia obu grup zamiast je rozdzielić. Efekt — osoby z zupełnie innego kontekstu dostały dostęp do projektów firmowych. Wykryliśmy to dzięki temu, że próbna migracja była robiona na osobnym site'ie testowym z pełnym audytem uprawnień po fakcie, a nie na produkcyjnym Cloud od razu.

Zasada, której się trzymałem Każda migracja próbna kończy się raportem różnic uprawnień: eksport grup i ich członków ze Server, eksport tych samych grup po migracji na Cloud, diff. Ręczne przeglądanie diffa nudne, ale to jedyny sposób, żeby złapać scalenia i rozjazdy, zanim zobaczy je ktoś spoza zespołu IT.

Custom fieldy i konfiguracje, których Cloud nie ma

Kilka pól typu „Cascading Select” z zagnieżdżonymi opcjami przeniosło się bez problemu. Gorzej wyszły pola pochodzące z dodatków Server, których dokładnego odpowiednika na Cloud po prostu nie ma — trzeba było zdecydować, czy zastąpić je najbliższym możliwym typem pola natywnego, czy poszukać zamiennika w Marketplace. Wybraliśmy pierwsze rozwiązanie tam, gdzie pole było używane tylko do raportowania, i drugie tam, gdzie logika biznesowa (automatyzacje, workflow) faktycznie zależała od wartości pola.

Automatyzacje (dawne workflow post-functions z pluginów typu Script Runner) to osobny rozdział — Script Runner dla Cloud istnieje, ale część skryptów Groovy pisanych pod Server wymagała przepisania pod inne API. Nie ma tu skrótu — trzeba przejrzeć każdą automatyzację osobno i sprawdzić, czy w ogóle nadal jest potrzebna, zanim zainwestuje się czas w przepisanie jej jeden do jednego.

Timeline realistycznego okna migracyjnego

Dla instancji naszej wielkości (kilkadziesiąt projektów Jira, kilkanaście przestrzeni Confluence, kilkaset kont użytkowników) okno migracyjne wyglądało tak:

Piątek wieczór — zamrożenie zapisu na instancji Server (tryb tylko do odczytu), start migracji CMA.
Sobota — migracja główna: dane Jira, potem Confluence, potem załączniki w tle równolegle. Monitorowanie postępu i logów błędów co godzinę.
Niedziela rano — weryfikacja: losowa próbka projektów sprawdzana ręcznie, porównanie liczby ticketów, sprawdzenie uprawnień kluczowych grup, test SSO.
Niedziela popołudnie — decyzja go/no-go. Mieliśmy przygotowany plan odwrotu (instancja Server nadal działa w trybie read-only, można wrócić), ale nie musieliśmy z niego korzystać.
Poniedziałek rano — start pracy w Cloud, instancja Server przechodzi w archiwalny tryb tylko do odczytu na kolejne kilka tygodni, na wypadek gdyby ktoś potrzebował czegoś, co się nie przeniosło.

Trzy dni to minimum dla instancji tej wielkości, i to zakładając, że próbna migracja została zrobiona wcześniej i większość niespodzianek już wyłapana. Nie próbowałbym tego okna skrócić do jednego dnia — bufor na sobotę wieczór, gdyby coś się przeciągnęło, uratował nam realnie jeden przypadek z długo migrującymi się załącznikami w największej przestrzeni Confluence.

Największym ryzykiem migracji Jira/Confluence nie jest utrata danych — CMA jest w tym solidny. Największym ryzykiem jest ciche pominięcie czegoś, czego nikt nie zauważy do czasu, aż będzie potrzebne.

Po migracji

Utrzymanie Jira Cloud i Confluence Cloud różni się od Server bardziej, niż się wydaje na pierwszy rzut oka — znika administracja serwerem (patche, backupy, restarty), pojawia się za to administracja organizacją Atlassian: zarządzanie site'ami, politykami dostępu, integracjami przez Atlassian Access. To przesunięcie roli z „administratora instancji” na „administratora platformy SaaS”, co samo w sobie jest zmianą warto opisania osobno.

Zmigrowana dokumentacja z Confluence stała się zresztą później bazą wiedzy dla wewnętrznego systemu RAG, o czym piszę osobno w tekście o budowie RAG na Ollama, vLLM i OpenWebUI — bez uporządkowanej, jednej instancji Confluence ten projekt byłby dużo trudniejszy do ogarnięcia.