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.
