Migracje do Jira Cloud zaskakują w czterech powtarzalnych obszarach: dane aplikacji poza EOG, wtyczki i skrypty, których nie da się przenieść jeden do jednego, limity integracji oraz raporty sięgające wprost do bazy Jiry. Żaden z tych czterech obszarów nie blokuje migracji. Warunek jest jeden: każdy trzeba zweryfikować jeszcze przed startem projektu, co pozwoli na uniknięcie niemiłych niespodzianek w trakcie.
Poniżej mechanizm każdego z tych obszarów i pytania, które pozwalają zbadać każdy z nich własnymi siłami.
Gdzie naprawdę leżą dane Twoich aplikacji?
Wybór regionu UE w Atlassian Cloud nie przesądza tego, że wszystkie dane zostają w Europie. Data residency obejmuje dane Jiry, Confluence i JSM. Aplikacje z Marketplace zwykle przechowują swoje dane osobno, na infrastrukturze producentów. Wyjątkiem są aplikacje działające w całości w ekosystemie Atlassiana (oznaczenie „Runs on Atlassian”) albo takie, które pozwalają przenieść dane do wybranego regionu. Jednak część aplikacji przechowuje dane poza Europejskim Obszarem Gospodarczym. .
W praktyce można mieć instancję we Frankfurcie i aplikację raportową, która wysyła dane za ocean. Dla firm objętych RODO, uKSC czy DORA to różnica między zgodnością, a problemem na audycie.
Jak to rozbroić: przed migracją sprawdza się lokalizację danych każdej aplikacji z osobna i spisuje wynik w rejestrze, który można pokazać audytorowi. Producent deklaruje lokalizację w dokumentacji. Brak deklaracji to też informacja.
Co się stanie z wtyczkami i skryptami?
Część wtyczek z Data Center nie istnieje w Cloud. Zwykle wychodzi to przy pierwszym przeglądzie Marketplace i budzi obawę, że migracja utknie. Nie musi. Audyt na starcie dzieli wtyczki na cztery grupy: zostają (mają wersję chmurową), zastępujemy (jest odpowiednik innego producenta), budujemy od nowa (funkcja potrzebna, odpowiednika brak), wycofujemy (nikt już z niej nie korzysta). Ostatnia grupa bywa zaskakująco liczna. To dobra wiadomość: mniej aplikacji w chmurze to niższy miesięczny rachunek, a Atlassian stale dodaje do Cloud natywne funkcje, które przejmują zadania kolejnych wtyczek potrzebnych jeszcze w Data Center.
Ze skryptami jest podobnie, tylko mniej widocznie. Logika zapisana w skryptach (walidacje, scripted fields, listenery, joby) nie przeniesie się razem z danymi. Trzeba ją odtworzyć na mechanizmach chmurowych. To najczęściej niedoszacowana część migracji, bo skrypty narastały latami i często brakuje ich pełnej dokumentacji.
Droga odtworzenia zależy od kompetencji w zespole. Zespół administratorów może dostosować skrypty do instancji chmurowej lub skonfigurować ich odpowiedniki funkcjonalne w Automation for Jira. Na tym etapie warto też rozważyć zewnętrznego dostawcę, który ma zasoby i kompetencje, by sprawnie dostosować skrypty do Cloud. Rozpoznanie zaczyna się od inwentaryzacji: ile skryptów działa na instancji, jaka jest ich złożoność, co robią i czy wszystkie są w repozytorium, czy część jest wpisana bezpośrednio w konfigurację. Dopiero na tej podstawie da się oszacować koszt i zdecydować, co przepisujemy, co upraszczamy, a co wycofujemy.
Dlaczego intensywne integracje to najtrudniejszy punkt?
Chmura narzuca limity liczby zapytań i po ich przekroczeniu odrzuca kolejne wywołania. Data Center limitu nie narzucało: przyjmowało tyle ruchu, ile udźwignął serwer albo na ile pozwalały ustawienia. Cloud działa inaczej. Nie ma wbudowanego kolejkowania ani ponawiania komunikacji, więc buforowanie, bezpieczne ponowienia i kontrola tempa wysyłki muszą powstać po stronie środowiska klienta.
Przy pojedynczych, rzadkich wywołaniach jest to niezauważalne. Przy integracji, która wymienia dane w czasie rzeczywistym albo masowo (system ITSM, narzędzia monitoringu, hurtownia danych), warstwa pośrednia staje się osobnym zadaniem projektowym. Warstwę projektuje się przed migracją, razem z pomiarem realnego wolumenu wywołań.
Które raporty przestaną działać?
Raporty pobierające dane wprost z bazy Jiry (systemy BI, własne zapytania) w chmurze nie zadziałają. Cloud nie daje dostępu do bazy danych, a dane do raportowania udostępnia innymi drogami: przez API i mechanizmy analityczne dostępne w wyższych planach.
To zaskoczenie ujawnia się późno, nieraz dopiero po migracji, gdy dział raportowania przestaje dostawać dane. Dlatego model raportowy warto zbadać wcześniej: które raporty sięgają do bazy, kto z nich korzysta i czym je odtworzyć w chmurze.
Jak sprawdzić te cztery rzeczy u siebie?
Zadaj swojemu zespołowi cztery pytania!
Brak odpowiedzi na któreś z nich to nie problem, tylko wskazanie, od czego zacząć. Wsparcie Data Center kończy się w marcu 2029, a licencje przechodzą wtedy w tryb tylko do odczytu.
Te cztery problematyczne elementy migracji możemy omówić na bezpłatnej konsultacji.
