Co potrafi zaskoczyć przy migracji Jiry do chmury? 

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. 

2026-09-06

Kiedy Atlassian Cloud Enterprise zamiast Premium?

Enterprise to plan dla firm, które potrzebują wielu instancji pod jedną subskrypcją, centralnej analityki łączącej dane z wielu systemów albo infrastruktury operacyjnej na inną skalę: audit log bez limitu retencji ze streamingiem do SIEM, nieograniczona automatyzacja i dedykowane wsparcie z 30-minutowym czasem reakcji. Próg wejścia to 801 użytkowników i rozliczenie roczne.
2026-09-04

Jira Cloud Standard czy Premium, który plan wybrać?

Ten, który wynika z Waszych wymagań, a nie z cennika. Większość organizacji odruchowo wycenia Standard, bo jest tańszy w przeliczeniu na użytkownika, a to, że część funkcji Premium jest dla niej wymogiem, odkrywa już po budżetowaniu. Poniżej różnice bez marketingu, razem z sekcją o tym, kiedy Standard wystarczy.
2026-09-04

Czy firma objęta uKSC, NIS2 lub DORA może przenieść Atlassiana do chmury?

Ani uKSC, ani NIS2, ani DORA nie zakazują chmury publicznej. Wszystkie trzy wymagają czegoś trudniejszego: wykazania, że organizacja panuje nad ryzykiem, danymi i ciągłością działania, również wtedy, gdy część systemów prowadzi zewnętrzny dostawca. Ten artykuł rozpisuje, jak przy migracji Jiry i Confluence zbudować zestaw dowodów, który obroni się przed audytorem.