Jak przygotować Jirę do migracji do chmury? 

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.

Przy przeprowadzce do nowego miejsca nikt nie pakuje do kartonów rzeczy, których nie używa od lat. Z Jirą warto postąpić tak samo i pozbyć się zbędnego bagażu, zanim projekt ruszy.  Poniżej cztery obszary do uporządkowania i checklista na start.  

Dlaczego sprzątać przed migracją, a nie po niej?

Koszt migracji rośnie z każdym przenoszonym elementem. Każdy projekt, schemat czy wtyczka wymaga podjęcia decyzji, przeniesienia na nowe środowisko i sprawdzenia prawidłowego działania. Porządki po migracji też są możliwe, tyle że wtedy płaci się najpierw za przeniesienie i licencje elementów, które i tak zostaną usunięte. 

Uporządkowana instancja to również niższa wycena, mniej niespodzianek w trakcie projektu i krótsze testy odbiorcze. Czasu na spokojną pracę nie brakuje: wsparcie Data Center kończy się w marcu 2029, więc porządki da się rozłożyć w czasie bez presji. 

Co przejrzeć w projektach? 

Zacznij od zakończonych projektów. Przez lata pracy w instancji zbierają się setki projektów, z których spora część nie była aktualizowana od dłuższego czasu. Każdy z nich zweryfikujesz trzema pytaniami: kiedy była w nim ostatnia zmiana, czy ktoś jeszcze z niego korzysta oraz czy wymogi (np. retencja dokumentacji) każą go zachować. 

Projekty potrzebne tylko do wglądu zarchiwizuj przed migracją. Każdy aktywny projekt wydłuża ją i podnosi jej koszt. Instancję Data Center można przy tym zostawić jako archiwum tylko do odczytu, więc zarchiwizowanych projektów nie trzeba w ogóle przenosić: historia zostaje pod ręką. 

Co z polami, schematami i przepływami pracy? 

W dojrzałej instancji zwykle znajdziesz pola niestandardowe, których nikt nie wypełnia, kilka niemal identycznych kopii schematów  (przepływów pracy, ekranów, uprawnień) i statusy, przez które żadne zgłoszenie nie przeszło od dawna. To naturalny osad po kolejnych zmianach i opłaca się go usunąć przed migracją: skasować nieużywane pola (po sprawdzeniu, że nie zawierają danych do zachowania), scalić powielone schematy, uprościć przepływy pracy. Im mniej schematów, tym prostsze mapowanie konfiguracji do chmury i mniej przypadków do przetestowania. 

Jak zrobić przegląd wtyczek?

W chmurze za większość wtyczek płacisz subskrypcyjnie, zależnie od liczby użytkowników. Na instancji, która przepracowała lata na Data Center, wtyczek jest zwykle więcej, niż potrzeba: część nie ma wersji w chmurze, część ma tam ograniczone funkcje, a inne można już zastąpić natywnymi mechanizmami Atlassian Cloud. Dlatego przegląd opłaca się zrobić pod kątem kosztu i realnej potrzeby, zaczynając od najdroższych. To tu oszczędności są najbardziej odczuwalne . 

Dla każdej wtyczki ustal: kto z niej korzysta, jaką rolę pełni, ile będzie kosztować w modelu chmurowym i czy można ją zastąpić funkcjami natywnymi Cloud. Wynik przeglądu to prosta lista: zostaje, zastępujemy, rezygnujemy. 

Co z użytkownikami i uprawnieniami? 

Przejrzyj konta: nieaktywni użytkownicy, dostępy po byłych pracownikach i współpracownikach, uprawnienia nadane „na chwilę” dawno temu. W chmurze subskrypcja zależy od liczby użytkowników z dostępem, więc porządek w kontach przekłada się wprost na niższe koszty licencji. 

To także dobry moment, by uporządkować model uprawnień: kto powinien mieć dostęp do czego i jak będziecie tym zarządzać po migracji. Porządek w tym obszarze upraszcza konfigurację logowania i ról w nowym środowisku, a przy okazji zmniejsza ryzyko, że do wrażliwych danych dostanie się ktoś, kto nie powinien. 

Od czego zacząć? Checklista na start 

  • Wypisz projekty bez aktywności od ponad roku: to kandydaci do archiwizacji. 
  • Sprawdź, które pola niestandardowe są realnie wypełniane. 
  • Przejrzyj schematy przepływów pracy: scal podobne lub identyczne, uprość te, które mogą przejść na schematy ogólne.
  • Zrób listę wtyczek: kto ich używa, co robią, czy mają wersję w Cloud i czy da się je zastąpić funkcjami natywnymi. 
  • Przejrzyj konta: nieaktywni użytkownicy i zbędne dostępy. 

Porządki najlepiej potraktować jak stały proces, niejednorazowy zryw: wyznacz właściciela i zarezerwuj regularny czas, choćby godzinę w tygodniu. Ta praca zwraca się niezależnie od terminu migracji. Mniejsza, uporządkowana instancja to szybsza przeprowadzka i niższe rachunki po niej. 

Co jeszcze potrafi zaskoczyć w trakcie migracji, opisaliśmy w artykule o czterech pułapkach przenosin do Jira Cloud. [link: artykuł „cztery rzeczy”] Na bezpłatnej konsultacji przejdziemy natomiast przez Twoją instancję i powiemy wprost, czy migracja będzie prosta, czy złożona. 

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.