Co potrafi zaskoczyć przy migracji Jiry do chmury? 

Co potrafi zaskoczyć przy migracji Jiry do chmury? 

Migracja do Jira Cloud rzadko kończy się problemami z samym przeniesieniem danych. Największe wyzwania pojawiają się wokół aplikacji, integracji, skryptów i raportów. Sprawdź cztery obszary, które warto zweryfikować przed rozpoczęciem projektu, aby uniknąć kosztownych niespodzianek.

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. 

Zanim zaprosisz dostawców, zrób porządki w instancji!

2026-07-24

Ile kosztuje migracja Jira do chmury? 

Koszt migracji do Jira Cloud nie zależy wyłącznie od liczby użytkowników. Dowiedz się, co naprawdę wpływa na wycenę projektu, które elementy generują największe koszty i jak przygotować instancję, aby ograniczyć wydatki jeszcze przed rozpoczęciem migracji.
2026-07-24

Co potrafi zaskoczyć przy migracji Jiry do chmury? 

Migracja do Jira Cloud rzadko kończy się problemami z samym przeniesieniem danych. Największe wyzwania pojawiają się wokół aplikacji, integracji, skryptów i raportów. Sprawdź cztery obszary, które warto zweryfikować przed rozpoczęciem projektu, aby uniknąć kosztownych niespodzianek.
2026-07-22

Jak przygotować Jirę do migracji do chmury? 

Migracja do Jira Cloud zaczyna się na długo przed przeniesieniem danych. Dowiedz się, jak uporządkować projekty, konfigurację, aplikacje i uprawnienia, aby przyspieszyć migrację, ograniczyć jej koszty i uniknąć niepotrzebnych problemów.