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.

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.

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.

Skrypty Groovy napisane w ScriptRunnerze na Data Center po migracji danych do Jira Cloud nie zadziałają: narzędzia migracyjne przenoszą dane i konfigurację, ale nie działanie skryptów. Migracja skryptów to projekt przepisania, nie przeniesienia. Logikę działania można odtworzyć na kilka sposobów, ale część skryptów może się okazać w ogóle niepotrzebna. Koszt przepisania zależy od złożoności skryptów, ale to inwentaryzacja decyduje, czy plan i budżet będą realistyczne. Kto wie, ile ma skryptów, co robią i gdzie żyją, ten migruje przewidywalnie. Kto nie wie, ten odkrywa brakującą walidację trzy tygodnie po migracji.

Po zrealizowaniu migracji wszystkie raporty, które sięgają wprost do bazy danych Jiry, przestaną działać. Jira Cloud nie daje dostępu do bazy, a dane do raportowania udostępnia innymi drogami - od API po mechanizmy analityczne w wyższych planach. Raportowanie da się odtworzyć, choć wymaga to dodatkowego nakładu pracy, a czasem również zmienionej formy. Warunek ciągłości raportowania jest jeden: model raportowy trzeba zinwentaryzować jeszcze przed migracją, a nie po niej.

Kluczowe są trzy daty: 2026, 2028 i 2029, a każda oznacza coś innego dla obecnych klientów. Sprawdzamy, co dokładnie zmieni się dla Jiry, Confluence i wtyczek Marketplace oraz kiedy warto rozpocząć przygotowania do migracji do Atlassian Cloud.

Zmienił się model rozliczeń: wtyczka z Data Center staje się w chmurze aplikacją subskrypcyjną i kosztuje więcej. Część z nich rozwiązuje przy tym potrzeby, które minęły albo które chmura pokrywa natywnie, więc rachunek za aplikacje da się obniżyć. Przegląd wtyczek przed migracją to finansowo najwdzięczniejsza część przygotowań: efekt widać wprost na fakturze. Poniżej mechanizm cenowy i to, jak taki przegląd zrobić u siebie.

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.

Migracja to najlepszy moment na odchudzenie instancji. Im mniej przenosisz, tym szybciej i taniej przebiega sam projekt, a mniejsza instancja to potem niższe rachunki za licencje w chmurze. Porządki można przy tym zacząć samodzielnie, na długo przed wyborem wykonawcy.