Nie ma jednej ceny migracji Jiry do chmury i każdy, kto podaje kwotę bez obejrzenia środowiska, zgaduje. Koszt zależy od tego, co siedzi w instancji: od skryptów, wtyczek i integracji, nie od liczby użytkowników. Dwie rzeczy są za to pewne: koszt da się rzetelnie oszacować po krótkim rozpoznaniu i realnie obniżyć, zanim projekt w ogóle wystartuje.
Ten artykuł nie poda Ci kwoty. Pokaże za to mechanizm: z czego koszt się składa, co go winduje, a co jest mitem, jak wygląda wycena, której nie trzeba brać na wiarę, i co zrobić przed startem, żeby zapłacić mniej.
Dlaczego nikt poważny nie poda ceny bez rozpoznania?
Dwie instancje o tej samej liczbie użytkowników potrafią różnić się nakładem pracy wielokrotnie. Migracja Jiry na kilkadziesiąt osób, która przez lata obrosła skryptami i integracją z systemem ITSM, to większy projekt niż przeniesienie bezskryptowej instancji na kilka tysięcy kont, w której wszystkie wtyczki mają wersję chmurową.
Kwota podana bez zajrzenia do instancji przybiera więc jedną z dwóch postaci. Pierwsza to widełki tak szerokie, że nic nie mówią. Druga, gorsza, to niska cena na wejściu, która rośnie z każdym aneksem, gdy w trakcie projektu wychodzą na jaw kolejne skrypty i integracje. Rzetelna kolejność jest odwrotna: najpierw rozpoznanie, potem kwota.
Z czego składa się koszt migracji?
Przede wszystkim z pracy projektowej, rozłożonej na pięć etapów:
Co podnosi koszt, a co nie?
Do tego dochodzi koszt po Twojej stronie: czas zespołu na testy, decyzje i naukę nowego narzędzia. Nakład i na jedno, i na drugie rośnie ze złożonością środowiska, nie z jego wielkością.
Koszt podnosi kustomizacja. Konkretnie:
A teraz mit: liczba użytkowników i projektów sama w sobie nie podnosi kosztu migracji. Podnosi za to przyszły koszt subskrypcji, bo w chmurze płacisz od liczby użytkowników. Skala zwiększa pracę projektową tylko pośrednio (więcej osób do przeszkolenia, dłuższe testy odbiorcze), ale nie decyduje o charakterze projektu. Podobnie wymóg trzymania danych w UE: to wybór regionu w konfiguracji Atlassiana, nie dodatkowy projekt. Duża instancja blisko standardu bywa tańsza w migracji niż mała, mocno zmodyfikowana.
Jak wygląda uczciwa wycena?
Zaczyna się od bezpłatnej konsultacji: rozmawiamy o Twoim środowisku godzinę, może dwie. Po takiej rozmowie wiadomo, którą z dwóch ścieżek pójdzie wycena:
Ten układ odpowiada też na częstą obawę: „wciągną nas w projekt bez końca”. Nie wciągną, bo projekt jest pod Twoją kontrolą: każdy etap kończy się punktem decyzyjnym, w którym możesz iść dalej, zmienić zakres albo się zatrzymać. Szacunek dostajesz przed zobowiązaniem, nie po nim.
Jak obniżyć koszt jeszcze przed migracją?
Porządkami we własnej instancji, na długo przed wyborem wykonawcy. Koszt rośnie z każdym przenoszonym elementem, więc im mniej przenosisz, tym mniej płacisz:
Pełną checklistę porządków rozpisaliśmy w osobnym artykule. [link: artykuł #1, porządki przed migracją] To praca, którą wykonujesz we własnym tempie i która zwraca się niezależnie od tego, kiedy i z kim migrujesz.
O jakich kosztach po migracji pamiętać?
O trzech pozycjach, które pojawiają się co miesiąc lub co rok, zależnie od modelu rozliczeń, zamiast dotychczasowego utrzymania serwerów:
W zamian znikają serwery, aktualizacje i backupy platformy. Administratorzy Jiry nie znikają, zmienia się za to ich praca: utrzymanie infrastruktury przejmuje Atlassian, a im zostaje konfiguracja i wsparcie zespołów. Na czas samego przejścia Atlassian oferuje mechanizmy licencyjne, które pozwalają nie płacić podwójnie za okres równoległego działania obu środowisk. Komu przysługują i na jakich warunkach, opisaliśmy osobno.
Chcesz wiedzieć, którą ścieżką pójdzie Twoja wycena? Umów bezpłatną konsultację: przejdziemy przez Twoje środowisko i powiemy wprost, czy migracja będzie prosta, czy złożona. Wycenę dostajesz po rozpoznaniu, nie w ciemno. [link: landing migracji, CTA „Umów bezpłatną konsultację”] Cztery rzeczy, które najczęściej przesądzają o złożoności, opisaliśmy osobno, razem z tym, jak sprawdzić je u siebie.
