Alternatywa dla Jiry w 2026: co się zmieniło, czym jest dziś monday.com i jak przeprowadzić migrację

Jeżeli Twoja organizacja pracuje na Jirze, rok 2026 wymusza decyzję, której nie da się odłożyć na później. Nie chodzi o to, że Jira przestała działać. Chodzi o to, że zmieniły się trzy rzeczy naraz: model hostingu, polityka danych wobec AI i realny rachunek za środowisko. Firmy, które i tak muszą coś zrobić ze swoim setupem, zaczynają zadawać sensowne pytanie: skoro migracja jest nieunikniona, to dlaczego migrować do miejsca, które wybraliśmy 8 lat temu z zupełnie innych powodów?

Ten artykuł przechodzi przez to po kolei: dlaczego właśnie teraz, co dokładnie zmienia się w polityce danych 17 sierpnia 2026, czym jest dziś monday.com, jak wygląda uczciwe porównanie obu platform i jak przeprowadzić migrację bez utraty danych oraz bez zatrzymywania pracy zespołów. Na końcu dobre praktyki, które decydują o tym, czy nowe środowisko po roku będzie porządne, czy odziedziczy dotychczasowe zaszłości w nowszym interfejsie.

1. Dlaczego w 2026 warto rozejrzeć się za alternatywami dla Jiry

Krótka historia jednej decyzji

Duże organizacje w Polsce, zwłaszcza banki, ubezpieczyciele i firmy przemysłowe, wybierały Jirę z konkretnego powodu: dawała wersję on-premise. Dane zostawały na własnych serwerach, a to często wynikało wprost z zapisów w umowach z klientami końcowymi lub z wymogów regulacyjnych. Był to argument nie do podbicia przez narzędzia, które od początku istniały wyłącznie w chmurze.

Ten argument przestał obowiązywać. Atlassian przez kilka lat przesuwał rozwój produktu, nowe funkcje i model cenowy w stronę chmury, a we wrześniu 2025 ogłosił harmonogram wygaszania całej linii Data Center.

Twarde daty

Poniższe daty pochodzą z oficjalnego harmonogramu Atlassiana na stronie atlassian.com/migration.

Trzy szczegóły, które w większości omówień się gubią, a mają realne znaczenie przy planowaniu budżetu.

Odnowienia można kupować, ale nie da się nimi przedłużyć życia środowiska. Po 30 marca 2026 obecny klient nadal odnawia subskrypcję, jednak odnowienie nie może wykroczyć poza 28 marca 2029. Roczne odnowienie kupione po marcu 2028 zostanie proporcjonalnie skrócone do tej daty.

Przedłużone wsparcie po 2029 istnieje, ale nie jest opcją z cennika. Atlassian dopuszcza rozszerzone utrzymanie dla wybranych klientów Data Center po 28 marca 2029, za dodatkową opłatą i wyłącznie w drodze wyjątku, po ustaleniach z opiekunem handlowym. Planowanie strategii IT na założeniu, że taki wyjątek zostanie przyznany, jest ryzykiem, nie planem.

Nie wszystko jest objęte wygaszeniem. End of life dotyczy Jira Software Data Center, Jira Service Management Data Center, Confluence Data Center, Bamboo, Crowd, aplikacji mobilnych Data Center oraz aplikacji Marketplace dla Data Center. Poza zakresem są dwie rzeczy: Bitbucket Data Center, który zamiast wygaszenia dostaje nową licencję łączącą Data Center i Cloud, oraz Jira Align Data Center. Jeżeli więc trzymacie kod w Bitbuckecie u siebie, ten konkretny element stosu nie zmusza Was do niczego. Reszta zmusza.

Praktyczny wniosek: terminem jest 28 marca 2029 i nie przesuwa się on wraz z tym, kiedy zaczniecie. Dla instancji liczonych w setkach projektów i setkach tysięcy zgłoszeń to nie jest dużo. Realistyczny projekt migracyjny w tej skali, razem z okresem stabilizacji, zajmuje od 6 do 12 miesięcy. Start w 2028 roku oznacza pracę bez buforu, na środowisku, które w trakcie projektu przestaje dostawać poprawki bezpieczeństwa.

Rachunek, o którym mówi się najmniej

Cena licencji Jiry to nie cena środowiska Jiry. W dużych, wieloletnich instancjach realny koszt to licencja plus zestaw płatnych dodatków, bez których praca jest niewygodna albo niemożliwa: Advanced Roadmaps do planowania portfela, Tempo do czasu pracy, Structure do hierarchii, ScriptRunner do automatyzacji wykraczających poza standard. W audytach, które prowadzimy, koszt samych licencji tego zestawu w organizacji liczonej w tysiącach użytkowników sięga 150–200 tys. PLN rocznie, niezależnie od licencji Jiry i niezależnie od kosztu utrzymania infrastruktury oraz etatu administratora.

Do tego dochodzi wydatek, którego nie ma w żadnym rocznym planie finansowym: sama migracja do chmury. Ten koszt trzeba ponieść tak czy inaczej.

Świadomie nie podajemy tu cen monday.com. Zestawianie cen z cennika prowadzi do złych wniosków, bo zależą od planu, liczby osób i tego, ile funkcji dziś kupujecie osobno. Sens ma tylko porównanie pełnych rachunków: po jednej stronie licencja plus dodatki plus utrzymanie infrastruktury plus czas administratora, po drugiej jedna subskrypcja z portfelem, śledzeniem czasu i raportowaniem w standardzie. W porównaniach, które robimy dla klientów, różnica w całkowitym koszcie bywa wielokrotna, ale nie ma jednej liczby, która byłaby prawdziwa dla wszystkich. Dlatego to jest rozmowa na konkretnych danych, a nie akapit na blogu.

Harmonogram i rachunek to dwie zmiany, które da się policzyć w arkuszu. Trzecia jest trudniejsza, bo dotyczy nie kosztu, a kontroli. Zasługuje na osobną sekcję.

2. Dane i AI: zmiana z 17 sierpnia 2026

Co dokładnie się zmienia

Ta zmiana dotyczy również firm, które już siedzą w Jira Cloud, i jest chyba najczęściej przekręcanym tematem w całej dyskusji o Atlassianie. Opisujemy ją dokładnie tak, jak brzmi w oficjalnym FAQ Atlassiana, bez podkręcania i bez wygładzania. Na końcu sekcji jest checklista rzeczy do sprawdzenia w panelu administracyjnym. Ustawienia da się zmieniać w każdej chwili, więc jest aktualna niezależnie od tego, po której stronie tej daty czytacie ten tekst.

Od 17 sierpnia 2026 Atlassian używa danych klientów do ulepszania produktów i doświadczeń dla wszystkich klientów. Na tym polega zmiana: wcześniej te same dane służyły ulepszaniu doświadczenia wyłącznie w obrębie jednej organizacji, teraz zasilają rozwój produktu dla całej bazy. Razem z tą datą wchodzą w życie zaktualizowane Customer Agreement, AI Terms, Data Processing Addendum i Privacy Policy.

Dane dzielą się na dwie kategorie:

• Metadane: charakterystyki treści i wzorce wspólne dla wielu klientów. Atrybuty treści, czyli cechy statystyczne, pola liczbowe i pochodne danych in-app, na przykład liczba story pointów w zadaniu Jiry albo złożoność strony Confluence. Do tego wspólne wzorce: frazy, słowa kluczowe i tematy wyciągane z zapytań wyszukiwania, rozmów z Rovo i konfiguracji, przy pominięciu danych rzadkich, mogących być unikalne dla jednej organizacji.
• Dane in-app: treść wytworzona przez użytkowników. Tytuły i treść stron Confluence, tytuły, opisy i komentarze zadań Jiry, nazwy własnych statusów, workflow i emoji.

Ustawienia domyślne zależą od planu i to jest najważniejszy szczegół

Tu jest miejsce, w którym większość omówień się myli, także tych publikowanych przez konkurencję Atlassiana. Domyślne ustawienia nie są jednakowe dla wszystkich i nie wszystko jest domyślnie włączone.

Z tej tabeli wynikają dwa wnioski. Pierwszy: dane in-app, czyli realna treść zgłoszeń i dokumentacji, są domyślnie zbierane tylko na Free i Standard. Na Premium i Enterprise są domyślnie wyłączone, a wyłączyć albo włączyć je może każdy klient. Drugi: z metadanych nie da się zrezygnować na żadnym planie poza Enterprise.

I tu pojawia się kwestia, którą trudno obejść. Plan Cloud Enterprise dla Jiry i Confluence startuje od 801 użytkowników (dla Jira Service Management od 201). Organizacja mniejsza niż ta granica nie ma technicznej możliwości rezygnacji z przekazywania metadanych, bo nie ma dostępu do planu, który to umożliwia. Kontrola nad tą kategorią danych jest więc funkcją wielkości zakupu, nie decyzją administratora.

Ktoś w tym momencie powie: przecież u monday.com rezydencja danych w UE też jest tylko na Enterprise, więc jaka to różnica. Różnica jest w tym, co dokładnie stoi za progiem. U monday.com za progiem planu stoi fizyczna lokalizacja serwerów. Samo zobowiązanie, że dane i treść klienta nie są wykorzystywane do trenowania modeli i że dostawcy modeli działają w reżimie Zero Data Retention, nie zależy od planu i obowiązuje każdego klienta, także na Free. W drugim przypadku za progiem planu stoi możliwość niewykorzystania danych. To dwie różne klasy ograniczenia i warto je rozdzielić, zamiast wrzucać do jednego worka.

Mechanika, która zaskakuje

Decyduje najwyższy aktywny plan w organizacji, razem z trialami. Jeżeli w jednej organizacji Atlassiana masz Jira Standard i Confluence Premium, całą organizację obowiązują ustawienia Premium. Trial też się liczy jako aktywny plan.

Każda organizacja osobno. Jeżeli firma ma kilka organizacji Atlassiana, ustawienia trzeba przejrzeć i ustawić w każdej z nich niezależnie. To realny scenariusz w grupach kapitałowych i po akwizycjach.

Downgrade włącza metadane z powrotem. Jeżeli masz Enterprise z wyłączonym przekazywaniem metadanych i przechodzisz na plan, który tej opcji nie ma, przekazywanie metadanych zostaje włączone. Atlassian informuje o tym i daje 30 dni na przegląd ustawień, ale kierunek zmiany jest automatyczny.

Cloud Migration Trial jest w zakresie. To bezpośrednio dotyczy każdego, kto planuje migrację z Data Center. Dane w organizacji chmurowej podczas triala migracyjnego podlegają ustawieniom data contribution według najwyższego aktywnego planu. Natomiast dane w samych produktach Data Center nie są objęte tą zmianą.

Zakres startowy to nie cały stos. Ustawienia obejmują początkowo Jirę, Confluence i Jira Service Management razem z aplikacjami platformowymi (Rovo, Home, Teams, Projects, Assets, Goals, Analytics, Administration) oraz wybrane konektory Teamwork Graph. Loom, Trello, Bitbucket i aplikacje Marketplace nie mają jeszcze tych ustawień, a Atlassian deklaruje, że tam, gdzie ustawień nie ma, dane nie są przekazywane. Dane z jednej aplikacji mogą natomiast służyć ulepszaniu innej: wnioski z tego, jak zespoły używają Jiry, mogą poprawiać doświadczenie w Confluence.

Część organizacji jest wyłączona całkowicie. Klienci z kluczami zarządzanymi po swojej stronie (CMK/BYOK), Atlassian Government Cloud, Atlassian Isolated Cloud oraz organizacje z wymogami HIPAA są wyłączeni z data contribution. Wyłączone są też podmioty rządowe oraz część klientów z sektora finansowego. Instytucje edukacyjne, także publiczne, są objęte na zasadach ogólnych.

Co Atlassian deklaruje po swojej stronie

Uczciwość wymaga podania również zabezpieczeń, o których mówi dostawca. Wszystkie przekazywane dane są deidentyfikowane i agregowane przed użyciem, z usunięciem danych wskazujących wprost na osoby i kontrolami przeciw ponownej identyfikacji. Ustawienia rezydencji danych pozostają w mocy. Dane nie są sprzedawane ani przekazywane zewnętrznym dostawcom modeli do trenowania ich własnych usług. Po rezygnacji dane in-app są usuwane z zestawów treningowych w ciągu 30 dni, metadane w ciągu 90 dni, a modele wytrenowane na tych danych są trenowane ponownie.

Dlaczego to jest punkt decyzyjny, a nie ciekawostka

Dla CISO to pytanie o to, czy kontrola nad kategorią danych powinna zależeć od progu 801 użytkowników. Dla Inspektora Ochrony Danych to pytanie o podstawę przetwarzania i o to, czy zmiana warunków po stronie dostawcy uruchamia obowiązek ponownej oceny ryzyka. W praktyce uruchamia: materialna zmiana praktyk przetwarzania u dostawcy technologii to standardowy trigger przeglądu w każdym sensownym procesie vendor managementu, a w sektorze finansowym dodatkowo w reżimie DORA.

Dla zarządu pytanie jest prostsze. Czy opisy incydentów, treść zgłoszeń od klientów, konfiguracje procesów i dokumentacja architektury mają zasilać rozwój produktu dostawcy, w modelu, w którym rezygnacja z części tych danych jest funkcją posiadanego planu?

To nie jest argument, że trzeba uciekać. To argument, że trzeba podjąć decyzję świadomie, udokumentować ją i wiedzieć, jaka jest alternatywa.

Pięć rzeczy do sprawdzenia w panelu Atlassiana

Te pięć rzeczy warto odhaczyć niezależnie od tego, czy rozważacie zmianę platformy, i niezależnie od tego, kiedy czytacie ten tekst. Ustawienia można zmieniać w każdej chwili, a zmiana planu w dół potrafi je przestawić bez Waszego udziału.

1. Sprawdźcie najwyższy aktywny plan w każdej organizacji. Atlassian Administration, sekcja Apps, potem Atlassian apps. Pamiętajcie o trialach.
2. Przejrzyjcie ustawienia data contribution. Atlassian Administration, sekcja Security, potem Data contribution. Uprawnienie ma organization admin, nie administrator Jiry.
3. Podejmijcie decyzję o danych in-app. Na Premium i Enterprise są domyślnie wyłączone. Na Free i Standard włączone, a wyłączyć je może każdy.
4. Udokumentujcie decyzję dla DPO i vendor managementu. Data przeglądu, kto decydował, na jakiej podstawie, jakie ustawienia obowiązują w której organizacji. Bez tego przegląd zostanie wykonany drugi raz, przy audycie, pod presją czasu.
5. Sprawdźcie, czy nie jesteście w kategorii wyłączonej. CMK/BYOK, Government Cloud, Isolated Cloud, HIPAA. Jeżeli tak, ustawienia będą wyłączone i nie da się ich włączyć. To zamierzone zabezpieczenie, ale i tak warto to zobaczyć w panelu.

Skoro i tak siadacie do tego przeglądu, to jest najlepszy możliwy moment, żeby zadać drugie pytanie: jak ta sama kwestia wygląda po drugiej stronie. Zobowiązanie, które nie zależy od planu, jest łatwiejsze do obrony przed audytorem niż ustawienie, które trzeba pamiętać, żeby przełączyć.

Trzy zmiany, jedna konsekwencja: w 2026 roku „zostajemy przy tym, co mamy" przestało być opcją zerowego kosztu i zerowego ryzyka. Środowisko trzeba przebudować tak czy inaczej, budżet na to i tak wyjdzie z kieszeni, a decyzja o platformie i tak zostanie podjęta przed marcem 2029. Pytanie jest tylko takie: przenosicie te procesy tam, gdzie kończą się na tym samym rachunku i tej samej polityce danych, czy tam, gdzie cała organizacja pracuje na jednej platformie.

3. Czym jest monday.com w 2026 roku

Największym nieporozumieniem w rozmowach o monday.com jest wyobrażenie z 2019 roku: kolorowe tabelki dla marketingu. Platforma, o której piszemy, to coś innego, i różnicę najłatwiej pokazać przez warstwy.

Warstwa danych

Podstawą jest relacyjna struktura tablic i elementów z typowanymi kolumnami. Elementy łączą się między tablicami (connect boards), a wartości można przeciągać z tablic powiązanych (mirror columns) i wyliczać formułami. W praktyce oznacza to, że jedno zgłoszenie może być jednocześnie widoczne w backlogu zespołu, w widoku portfela dla PMO i w raporcie dla zarządu, bez kopiowania danych i bez eksportów do Excela.

Warstwa widoków

Te same dane obsługują różne perspektywy: tablica, Kanban, sprint, Gantt, kalendarz, wykres, formularz, dashboard. Zmiana widoku nie jest zmianą konfiguracji i nie wymaga administratora. To brzmi banalnie, dopóki nie porówna się tego z procesem „poproś admina o nowy filtr i nowy widok".

Warstwa automatyzacji

Reguły buduje się wizualnie, w schemacie wyzwalacz plus warunek plus akcja, z możliwością budowania wieloetapowych przepływów. W audytach migracyjnych widzimy powtarzalny wzorzec: około 60% skryptów ScriptRunnera to proste reguły „kiedy A, wykonaj B", które przenoszą się na natywne automatyzacje jeden do jednego, a kolejne 20% to pola wyliczane i agregacje, które zastępują formuły oraz kolumny mirror.

Warstwa AI

To element, który realnie zmienił platformę w ciągu ostatnich dwóch lat i który uzasadnia nazwę AI work platform:

• Sidekick to asystent działający w kontekście danych konta. Odpowiada na pytania o stan projektów, buduje automatyzacje i dashboardy, podsumowuje status. Ma dostęp do zarządzania automatyzacjami, czyli może je tworzyć, czytać, wyłączać i usuwać.
• AI Blocks to gotowe operacje AI wstawiane wprost w kolumnę lub automatyzację: kategoryzacja, ekstrakcja danych, tłumaczenie, streszczenie, ocena sentymentu.
• Agenci AI to autonomiczne jednostki wykonujące wieloetapowe zadania w obrębie zdefiniowanego zakresu. W marcu 2026 monday.com udostępniło infrastrukturę, w której agent działający w imieniu człowieka rejestruje się, uwierzytelnia i pracuje na platformie na własnym koncie, z własnymi uprawnieniami i śladem audytowym.
• Vibe służy do budowania prostych aplikacji, widoków i kalkulatorów bez kodu, wewnątrz platformy.

Sensowny sposób myślenia o tym: nie „narzędzie z dodanym czatem", ale środowisko pracy, w którym zespół ludzi i zespół agentów pracują na tych samych danych i tych samych regułach.

Warstwa rozszerzeń

Dla zespołów, które w Jirze rozbudowywały środowisko pluginami, dostępne są monday Apps Framework, monday Code, REST i GraphQL API oraz webhooki. Rozszerzenia, których nie da się zbudować natywnie, buduje się jako aplikacje na platformie, a nie obok niej.

Dwie rzeczy, które trzeba powiedzieć uczciwie

Po pierwsze, AI na monday.com działa w modelu kredytowym. Pula kredytów jest wliczona w plan, a jej wykorzystanie zależy od liczby i typu operacji. Nie jest to więc funkcja „za darmo bez limitu" i przy projektowaniu automatyzacji z AI trzeba to policzyć. Dobra wiadomość: AI włącza się i wyłącza jednym przełącznikiem na poziomie całego konta, więc organizacja może zacząć z wyłączonym AI i uruchomić je wtedy, kiedy governance będzie gotowy.

Po drugie, sprawa lokalizacji danych. monday.com nie wykorzystuje treści i danych klienta do trenowania modeli i nie zezwala na to podmiotom trzecim. Modele działają przez zarządzane API dostawców chmurowych (AWS Bedrock, Azure) w reżimie Zero Data Retention, czyli dostawca modelu nie przechowuje wejść ani wyjść. Dane są szyfrowane w tranzycie (TLS 1.3) i w spoczynku (AES-256). Platforma ma certyfikaty SOC 1/2/3 Type II oraz ISO 27001, 27017, 27018 i 27701, ze zgodnością z RODO i HIPAA. Natomiast hosting w regionie UE (Niemcy, infrastruktura AWS) jest dostępny wyłącznie na planie Enterprise. Na planie Pro dane domyślnie znajdują się w regionie US. Jeżeli residency w UE jest wymogiem, trzeba to zaplanować od początku, na poziomie wyboru planu, a nie odkryć w połowie wdrożenia.

Jak wygląda poniedziałek w nowym środowisku

Architektura to jedno, a codzienna praca to drugie. Tak wygląda pierwszy dzień tygodnia w organizacji, która przeszła migrację, opisany z perspektywy czterech różnych osób.

9:00, zespół deweloperski. Sprint zamknął się sam. Statusy zadań przeszły na „done", bo przyszły z repozytorium razem z merge'em, nikt nie przeklikiwał tablicy w piątek wieczorem. Nowy sprint jest już wypełniony z backlogu, a obciążenie zespołu widać na jednym wykresie, bo pojemność liczy się z dostępności ludzi, nie z pamięci scrum mastera.

10:30, PMO. Jeden widok portfela, wszystkie projekty, zależności między nimi i ryzyka oznaczone tam, gdzie terminy się nachodzą. Zero maili z pytaniem o status, zero zbierania danych do arkusza przed poniedziałkowym przeglądem. Dane są te same, których używa zespół, więc nie ma wersji „dla zarządu" i wersji „prawdziwej".

13:00, marketing i obsługa klienta. Zgłoszenie od klienta wpada formularzem, agent AI klasyfikuje je i przypisuje do właściwego zespołu, a osoba, która je zgłosiła, widzi postęp na tablicy. Bez licencji, bo dostęp podglądowy jest darmowy. Bez pytania kogokolwiek z IT o uprawnienia.

16:00, zarząd. Podsumowanie tygodnia jest gotowe, bo powstało samo: trzy liczby, trend i lista rzeczy, które utknęły. Nikt nie przygotowywał prezentacji, nikt nie pisał zapytania, nikt nie eksportował do arkusza.

Czego nie ma w tym dniu: pisania JQL, zgłoszenia do administratora o nowy widok, ręcznego zbierania statusów i eksportu do Excela. To nie są funkcje z cennika. To jest efekt tego, że wszyscy pracują na jednej platformie, a powtarzalne czynności wykonują automatyzacje i agenci.

4. Jira vs monday.com: uczciwe porównanie

Poniższe zestawienie dotyczy platformy monday.com jako całości, a nie pojedynczego produktu. To celowe. Największa różnica między tymi środowiskami nie leży w tym, które lepiej obsługuje sprint, ale w tym, że jedno jest narzędziem dla działu IT, a drugie środowiskiem pracy dla całej organizacji.

Dwa pytania, na które trzeba odpowiedzieć przed decyzją

Nie każdy element środowiska Jiry ma odpowiednik dostępny od pierwszego dnia i nie ma sensu tego ukrywać. Z naszych audytów wychodzą dwa miejsca, które wymagają decyzji, a nie deklaracji.

Ile logiki siedzi w skryptach. Organizacje, które zbudowały w ScriptRunnerze logikę branżową liczoną w tysiącach linii kodu, znajdą natywny odpowiednik dla większości reguł. Około 10% przypadków to nie jest przeniesienie, a zaprojektowanie od nowa: jako aplikacja na monday Code albo warstwa pośrednia. To pozycja w wycenie, nie niespodzianka.

Czy proces stoi na wąskospecjalizowanym dodatku. Trzy tysiące aplikacji Marketplace to trzy tysiące aplikacji. Jeżeli kluczowy proces opiera się na jednej z nich bez oczywistego zamiennika, sprawdzamy to na audycie i wyceniamy, zamiast odkrywać w trakcie transferu. Podobnie z zakresem natywnych integracji z repozytoriami: dostępny zakres zależy od planu, więc potwierdzamy go zanim cokolwiek obiecamy.

Reszta obszarów, które jeszcze dwa lata temu były argumentem za pozostaniem, w 2026 ma już odpowiedź. Obsługa zgłoszeń i procesy serwisowe to monday service, czyli pełny system ticketowy w tej samej platformie, a nie osobno kupowany produkt. Dokumentacja to monday docs powiązane z elementami, a nie oddzielne narzędzie. Portfel projektów, śledzenie czasu i raportowanie są w standardzie, nie w płatnych dodatkach. Kod źródłowy może zostać tam, gdzie jest: Bitbucket Data Center nie jest objęty wygaszeniem i jego klienci dostają licencję łączącą Data Center z Cloud, więc model hybrydowy jest realną opcją, nie kompromisem.

Dla kogo to się zwraca najszybciej

Z naszej praktyki wychodzi dość spójny profil organizacji, w której zmiana daje efekt w pierwszych miesiącach, nie w drugim roku.

Środowisko stoi na Data Center, więc przebudowa i tak jest w planie. Ponad połowa osób pracujących w narzędziu to nie deweloperzy, a mimo to wszyscy pracują w narzędziu zbudowanym dla deweloperów. Rachunek zawiera dodatki Marketplace za funkcje, które w nowszej platformie są standardem. Raporty dla zarządu powstają ręcznie albo przez eksport do arkusza, a wgląd w projekt zaczyna się w momencie, gdy ktoś przygotuje prezentację. Polityka danych i AI weszła do rozmowy z compliance.

Im więcej z tego brzmi znajomo, tym szybciej zmiana się zwraca. Jeżeli natomiast pracujecie w wąskim, czysto inżynieryjnym zespole, nie macie problemu z rachunkiem i nikt poza IT nie potrzebuje wglądu w te dane, spokojnie możecie zostać dłużej. Uczciwa odpowiedź brzmi wtedy: policzcie to jeszcze raz w 2028.

Dowody, nie deklaracje

Vistra. Globalny dostawca usług biznesowych obecny w ponad 50 krajach, ponad 10 tysięcy pracowników, obsługa 30% firm z listy Fortune 500. Zespół inżynieryjny przeszedł z chaotycznego, opartego na Jirze procesu przyjmowania zgłoszeń na scentralizowane środowisko monday.com. Wyniki: 28% krótszy czas wprowadzania zmian na rynek, pełna przejrzystość procesów inżynieryjnych dla zespołów biznesowych i handlowych oraz ustrukturyzowany podział czasu zespołu w proporcji 75/25 między roadmapę strategiczną a wsparcie i błędy.

Canva. Zespół Growth Marketing Creative przyjmował zgłoszenia przez trzy różne narzędzia, w tym Jirę. Po przejściu na jedno środowisko monday.com: 40% szybsza realizacja projektów, ponad 60 tysięcy wyprodukowanych reklam (trzykrotny wzrost outputu), rozszerzenie działania z 9 do 56 rynków i wyeliminowanie 657 ręcznych czynności administracyjnych.

Zwróćcie uwagę na wspólny mianownik obu przypadków. To nie były migracje wykonane dlatego, że Jira nie potrafiła obsłużyć zgłoszeń. To były migracje wykonane dlatego, że narzędzie nie łączyło zespołu technicznego z resztą organizacji.

5. Plan migracji

Trzy najczęstsze przyczyny nieudanych migracji

Migracje tej klasy rzadko zawodzą na technologii. Transfer danych jest problemem inżynieryjnym o znanym rozwiązaniu. Zawodzą na trzech decyzjach podejmowanych na starcie projektu.

Błąd pierwszy: odtworzenie starego środowiska jeden do jednego. „Zbudujmy Jirę w monday, żeby zespół nie odczuł zmiany." W wieloletniej instancji Jiry ogromna część pól dodatkowych nie jest realnie używana, a spora część procesów to pozostałości po procedurach, które przestały obowiązywać. Migracja to jedyna okazja w kilkuletnim cyklu, żeby to uciąć. Bez tej decyzji nowe środowisko dziedziczy te same zaszłości konfiguracyjne, tylko w nowszym interfejsie, a organizacja wydaje budżet na przeprowadzkę zamiast na uporządkowanie procesów.

Błąd drugi: bezterminowa praca w dwóch systemach. „Zostawmy Jirę na pół roku, na wypadek problemów." Nikt nie utrzymuje dwóch systemów w dyscyplinie. Po trzech miesiącach stan danych się rozjeżdża, część zespołu pracuje tu, część tam, a firma płaci dwie faktury licencyjne. Standardem jest ustrukturyzowane wygaszanie: kontrolowana synchronizacja dwukierunkowa w okresie przenoszenia zespołów, potem twarde przełączenie, potem Jira w trybie tylko do odczytu jako bufor stabilizacyjny na 1–2 miesiące, potem wyłączenie.

Błąd trzeci: brak pilota. „Przenieśmy wszystkich na koniec kwartału." Pilotowy zespół liczący 5–10 osób weryfikuje architekturę na prawdziwych danych i prawdziwych ludziach. Wyłapuje problemy, które na warsztacie projektowym wyglądały rozsądnie. Bez pilota rolę pilota pełni pierwsza fala migracji, tylko ze znacznie większą liczbą świadków.

Cztery fazy, które działają w każdej skali

Faza 1. Audyt i decyzje (od 1 do 3 tygodni)

Inwentaryzacja projektów, pól, procesów, automatyzacji, skryptów i pluginów Marketplace. Odpowiadamy na pytanie, co jest naprawdę używane, a co jest zaszłością. Każdy skrypt i plugin trafia do jednej z czterech kategorii:

• natywna automatyzacja lub workflow (w typowej instancji ok. 60% przypadków),
• natywne formuły i kolumny mirror, czyli pola wyliczane, agregacje, monitorowanie SLA (ok. 20%),
• agent AI, gdy chodzi o decyzję lub klasyfikację, na przykład triage zgłoszeń albo agregacja statusów (ok. 10%),
• dedykowana aplikacja lub warstwa pośrednia (ok. 10%).

W tej fazie ustalamy też trzy rzeczy, których nie da się zdecydować później: architekturę uprawnień, sposób technicznego transferu danych i zakres wykorzystania agentów AI (z decyzją governance).

Faza 2. Konfiguracja środowiska docelowego i mapowanie (od 2 do 4 tygodni)

Struktura przestrzeni roboczych, szablony dla typów projektów, konwencje statusów, słownik pojęć Jira na monday.com. Podłączenie logowania korporacyjnego (SSO, SCIM, Active Directory). Konfiguracja integracji z repozytoriami i systemem CI/CD. Budowa dashboardów dla poszczególnych odbiorców: zespół, PMO, zarząd, compliance.

Słownik pojęć wygląda tak:

Elementy bez bezpośredniego odpowiednika, na przykład wyniki skryptów albo dane wtyczek zewnętrznych, inwentaryzujemy w audycie i rozstrzygamy decyzją biznesową: przepisać, zastąpić natywnym mechanizmem, czy zarchiwizować.

Faza 3. Pilot i transfer (od 2 do 8 tygodni, zależnie od skali)

Pilot na projektach archiwalnych, żeby przetestować podejście na danych, które nie wpływają na ciągłość pracy. Po pilocie aktualizujemy plan i mapowanie. Dopiero potem transfer projektów aktywnych, partiami, z walidacją po każdej partii. W okresie przenoszenia zespołów działa dwukierunkowa synchronizacja: zespoły jeszcze nieprzeniesione pracują w Jirze, przeniesione w monday.com, a pola nowych elementów są utrzymywane spójnie po obu stronach.

Narzędzie do transferu dobieramy do skali. Dla zespołu z kilkoma projektami i kilkoma tysiącami zgłoszeń wystarcza natywna integracja monday.com z Jirą: konfigurujesz ją na tablicy docelowej, oznaczasz partie zgłoszeń etykietą wyzwalającą i elementy przechodzą po stronie monday.com. Integracja jest dostępna już od planu Standard.

Przy setkach tysięcy zgłoszeń, z historią zmian, komentarzami, załącznikami i hierarchią podzadań, dokładamy dedykowany pipeline: transfer partiami, walidacja po każdej partii, logika ponawiania i raport rozbieżności, którego wymaga compliance. Dokładny podział na to, co przechodzi natywnie, a co potrzebuje dedykowanego mechanizmu, rozpisujemy w audycie i pokazujemy w osobnym przewodniku migracyjnym, jeszcze przed wyceną. Nikt nie powinien podpisywać umowy bez tej listy przed oczami.

Faza 4. Przełączenie, szkolenia i opieka

Twarda, wcześnie komunikowana data przełączenia. Szkolenia w modelu train-the-trainer dla key userów, z materiałami dostępnymi dla wszystkich. Kilka dni intensywnego wsparcia bezpośrednio po przełączeniu, na dedykowanym kanale. Jira w trybie tylko do odczytu jako archiwum na czas buforu stabilizacyjnego, potem wyłączenie.

Po zamknięciu migracji zaczyna się część, którą najczęściej się pomija w planach: opieka. Pierwsze miesiące realnej pracy pokazują, które elementy konfiguracji wymagają korekty. To normalne i trzeba na to zaplanować budżet oraz czas konsultanta, w modelu miesięcznego retainera z przeglądem po stronie PMO.

Kolejność tych czterech faz jest nienegocjowalna i to jest jedyna rzecz w całym planie, której nie zmieniamy pod presją terminu. Można skrócić audyt, można zawęzić pilota do dwóch projektów, można rozłożyć transfer na więcej partii. Nie można przeskoczyć pilota i wejść od razu w projekty aktywne, bo wtedy pierwsza fala migracji sama staje się pilotem, tylko na produkcji. Nie można też zacząć transferu bez rozstrzygniętej architektury uprawnień, bo uprawnienia przepisuje się na końcu tylko raz, a poprawia się je już na żywym środowisku, przy ludziach, którzy w nim pracują.

Ile to trwa i od czego zależy

Czas trwania projektu wyznacza pięć zmiennych i żadna z nich nie jest liczbą użytkowników, mimo że właśnie od niej wszyscy zaczynają. Liczy się liczba realnie używanych projektów, bo każdy wymaga decyzji o mapowaniu. Liczy się wolumen zgłoszeń i załączników, bo to on decyduje, czy wystarczy natywna integracja, czy potrzebny jest dedykowany pipeline. Liczy się liczba automatyzacji i skryptów, bo każdy trafia do jednej z czterech ścieżek migracji. Liczy się liczba zespołów do onboardingu, bo szkolenia i przenoszenie idą falami, nie jednym wydarzeniem. I liczy się dostępność ludzi po stronie klienta, bo to najczęstszy powód przesunięć w harmonogramie.

Liczba użytkowników jest w tym wszystkim tylko przybliżeniem, ale wygodnym, bo zwykle koreluje z pozostałymi zmiennymi. Dlatego poniższe widełki są punktem wyjścia do rozmowy, a nie wyceną.

Do tego dwa warunki, które nie zależą od dostawcy. Bez sponsora wykonawczego na poziomie CIO lub CTO migracja zatrzyma się na pierwszym poważnym oporze, a opór pojawi się najpóźniej w momencie, w którym trzeba będzie komuś powiedzieć, że pole dodatkowe używane przez jego zespół od lat nie zostanie przeniesione. Bez dedykowanego PMO po stronie klienta, choćby w części etatu, decyzje będą się przeciągać i harmonogram się rozjedzie, bo przy migracji tej klasy decyzji do podjęcia jest kilkadziesiąt, a każda z nich blokuje kolejny krok.

W największej skali plan rozkłada się na dwanaście miesięcy i wygląda tak, jak na poniższej linii czasu. Cztery miesiące to praca migracyjna i konfiguracyjna, dwa kolejne to bufor stabilizacyjny, a pozostałe osiem to opieka, w trakcie której środowisko dojrzewa razem z zespołami.

Zwróćcie uwagę na dwie rzeczy. Jira nie jest wyłączana w momencie przełączenia, tylko przechodzi w tryb tylko do odczytu na dwa miesiące, żeby dało się zweryfikować integralność danych i zajrzeć w archiwalną konfigurację, gdy okaże się to potrzebne. Druga rzecz to okno licencyjne: licencje w nowym środowisku aktywuje się sekwencyjnie, zgodnie z kolejnością przenoszenia zespołów, a nie wszystkie w dniu startu. To decyduje o tym, jak długo firma płaci za dwa środowiska równolegle, i jest jedną z niewielu pozycji w tym projekcie, którą da się realnie zoptymalizować bez wpływu na jakość.

W mniejszej skali ten sam układ się kompresuje, ale nie zmienia kształtu. Zamiast czterech miesięcy migracji są trzy tygodnie, zamiast dwóch miesięcy buforu jest dwa tygodnie w trybie tylko do odczytu, a opieka trwa kwartał zamiast ośmiu miesięcy. Proporcje między etapami zostają te same, bo wynikają z tego, jak ludzie przyswajają nowe środowisko, nie z wolumenu danych.

Czego nie robić z harmonogramem

Nie planujcie przełączenia w czwartym kwartale ani przed dużym wydaniem biznesowym. Nie planujcie też końca migracji na moment wygaśnięcia licencji, bo wtedy każde opóźnienie staje się kryzysem. I zaplanujcie okno licencyjne: kolejność aktywacji licencji w nowym środowisku powinna odpowiadać kolejności przenoszenia zespołów, żeby skrócić okres, w którym firma płaci za oba środowiska równolegle.

Kto siedzi po drugiej stronie takiego projektu

Migracji w skali enterprise nie robi jeden zespół wykonawczy i nie udajemy, że jest inaczej. W projektach tej klasy pracujemy w układzie trzech stron.

Zespół techniczny CXLABS prowadzi projekt. Audyt środowiska, projekt i konfiguracja docelowego workspace'u, koordynacja z PMO po stronie klienta, transfer danych, szkolenia i opieka po przełączeniu. To jest strona, która odpowiada za harmonogram i za wynik.

monday.com wchodzi w projekt jako strona, nie jako logo na slajdzie. Przy migracjach enterprise mamy bezpośredni kontakt z zespołem odpowiedzialnym za ścieżkę migracyjną i za dwukierunkową synchronizację Jira ↔ monday.com. To oznacza rozstrzyganie skomplikowanych przypadków technicznych przy udziale producenta, dostęp do jego wiedzy wewnętrznej i priorytetowe ścieżki eskalacji. Tego nie zorganizuje wykonawca bez statusu partnera, a przy transferze liczonym w setkach tysięcy zgłoszeń to różnica między „zgłosiliśmy ticket" a „mamy odpowiedź w tym samym dniu".

Niezależny konsultant weryfikuje architekturę w punktach krytycznych. W dużych projektach dokładamy specjalistę z portfolio migracji Jira do monday.com, żeby skonfrontować nasze decyzje projektowe z praktyką z innych wdrożeń. Drugie spojrzenie na architekturę uprawnień i na model danych jest tańsze przed transferem niż po nim.

Po stronie klienta potrzebujemy dwóch rzeczy, o których było wyżej: sponsora wykonawczego i dedykowanego PMO. Przy mniejszych migracjach ten układ się upraszcza i prowadzimy projekt sami, bo trzy strony przy dwudziestu użytkownikach to koszt bez wartości.

6. Dobre praktyki pracy z monday.com

Migracja to projekt. To, czy nowe środowisko po roku będzie porządne, zależy od decyzji podjętych w pierwszych tygodniach po przełączeniu. Poniżej praktyki, które w naszych wdrożeniach robią najwięcej różnicy.

Architektura, nie improwizacja

Zaprojektujcie strukturę przestrzeni roboczych przed pierwszym importem, nie po dwudziestym. Dobra reguła: przestrzeń robocza odpowiada jednostce organizacyjnej albo produktowi, a nie pojedynczemu projektowi. Ustalcie konwencję nazewnictwa tablic i widoków oraz zamknięty zestaw statusów. Trzy różne wersje statusu „w toku" w trzech zespołach oznaczają, że dashboard dla zarządu nigdy nie będzie się zgadzał.

Jedno źródło prawdy zamiast kopii

Nie duplikujcie danych między tablicami. Do powiązań używajcie kolumn connect boards, do pokazywania wartości z tablic powiązanych kolumn mirror, do wyliczeń formuł. Każda ręczna kopia to przyszła rozbieżność w raporcie.

Dashboard per odbiorca, nie jeden dla wszystkich

Zespół potrzebuje obciążenia i blokerów. PMO potrzebuje statusu portfela, zależności i ryzyk. Zarząd potrzebuje trzech liczb i trendu. Jeden „dashboard uniwersalny" nie obsłuży żadnej z tych potrzeb. Zbudujcie trzy i uzgodnijcie, kto na który patrzy.

Automatyzacje z właścicielem i przeglądem

Każda automatyzacja powinna mieć zrozumiałą nazwę i właściciela biznesowego. Raz na kwartał przejrzyjcie listę i wyłączcie te, które nie odpalają się od miesięcy. To ta sama dyscyplina, której brak zamienia wieloletnie instancje Jiry w zbiór procesów nieużywanych, ale nadal aktywnych. Zaczynajcie od automatyzacji rutynowych i wysokiej częstotliwości, nie od tych najbardziej efektownych.

AI wprowadzajcie przypadkiem użycia, nie ogłoszeniem

Najgorszy sposób wdrożenia AI to komunikat „mamy AI, korzystajcie". Wybierzcie dwa lub trzy konkretne, powtarzalne procesy, w których AI daje mierzalny efekt: triage i klasyfikacja zgłoszeń wpływających formularzem, podsumowanie statusu projektu dla zarządu, ekstrakcja danych z dokumentów. Zmierzcie czas przed i po. Dopiero z tym wynikiem idźcie dalej.

Przy okazji policzcie kredyty. Automatyzacja z AI odpalająca się przy każdej zmianie statusu na tablicy z tysiącem elementów zużyje pulę szybciej, niż ktokolwiek się spodziewa. To kwestia projektowania wyzwalaczy, nie limitu platformy.

Agentów wpuszczajcie z uprawnieniami, nie z zaufaniem

Agent AI działa na własnym koncie, z własnymi uprawnieniami i śladem audytowym. Wykorzystajcie to. Zakres agenta powinien być ograniczony do tablic, na których faktycznie ma pracować, a jego działania powinny być rozpoznawalne w historii elementu. Uzgodnijcie z bezpieczeństwem i compliance zakres, zanim agent trafi na produkcję, a nie po pierwszym pytaniu audytora.

Uprawnienia i darmowi viewerzy

Uprawnienia mapujcie na strukturę organizacji, na poziomach: organizacja, przestrzeń robocza, tablica, kolumna, wiersz. I wykorzystajcie darmowy dostęp podglądowy. To najprostszy sposób, żeby zarząd, PMO, sprzedaż i obsługa klienta widziały stan prac bez zwiększania liczby płatnych licencji i bez cotygodniowego raportu robionego ręcznie przez kogoś z zespołu.

Governance zamiast pojedynczego administratora

Nie odtwarzajcie modelu „jeden administrator, który wie wszystko". To jest dokładnie ta zależność, która w Jirze robiła z prostej zmiany widoku zgłoszenie do IT. Zamiast tego: mały zespół kompetencyjny, po jednym key userze na dział, wspólne standardy konfiguracji i regularny przegląd. Zespoły konfigurują sobie widoki same, w ramach uzgodnionych ram.

Mierzcie adopcję, nie tylko wdrożenie

Po miesiącu, trzech i sześciu sprawdźcie kilka rzeczy: jaki procent zespołów aktualizuje statusy bez przypominania, ile raportów nadal powstaje ręcznie w arkuszach, ile automatyzacji faktycznie się odpala, ile czasu zajmuje przygotowanie przeglądu portfela. To są liczby, które mówią, czy migracja się udała. Data przełączenia mówi tylko, że się skończyła.

FAQ

Czy monday.com poradzi sobie z zaawansowanym zarządzaniem projektami software'owymi?
‍Tak. Platforma obsługuje sprinty, backlogi, tablice Scrum i Kanban, planowanie wydajności, zarządzanie błędami i wydaniami oraz dwukierunkowe integracje z GitHubem, GitLabem i Bitbucketem. Zakres natywnych integracji z repozytoriami zależy od planu, dlatego potwierdzamy go na etapie audytu, przed wyceną. Tam, gdzie natywna integracja nie sięga, używa się API, webhooków albo własnej aplikacji na monday Code.

Czy migracja zatrzyma pracę zespołów?
‍Nie, jeżeli jest dobrze zaplanowana. Zespoły pracują w Jirze przez cały okres przygotowań. W fazie przenoszenia działa synchronizacja dwukierunkowa, więc część zespołów może już pracować w nowym środowisku, a część jeszcze w starym. Samo przełączenie odbywa się w okienku serwisowym.

Czy stracimy historię zgłoszeń?
‍Nie, o ile zakres został zdefiniowany przed startem. Natywna integracja z Jirą przenosi zgłoszenia i wspierane typy pól, ale nie odtwarza struktury podzadań, a components traktuje jako osobne elementy. Komentarze, załączniki, historia zmian i hierarchia podzadań w dużych migracjach są obsługiwane dedykowanym mechanizmem transferu, nie standardową integracją. Elementy bez odpowiednika, na przykład wyniki skryptów albo dane wtyczek zewnętrznych, inwentaryzujemy w audycie i rozstrzygamy osobno, decyzją biznesową: przepisać, zastąpić natywnym mechanizmem, czy zarchiwizować.

Czy wystarczy natywna integracja, czy potrzebujemy czegoś więcej?
‍Zależy od skali. Kilka projektów i kilka tysięcy zgłoszeń: natywna integracja wystarczy. Setki projektów i setki tysięcy zgłoszeń, z wymogiem śladu audytowego: potrzebny jest dedykowany pipeline z walidacją per partia. Starszy mechanizm „import from Jira Server" pomijamy, bo działa tylko na planie Enterprise i został oznaczony do wycofania.

Mamy rozbudowane schematy uprawnień. Da się to odwzorować?
‍Tak. Uprawnienia działają na poziomie organizacji, przestrzeni roboczej, tablicy, kolumny i wiersza, razem z dostępem gościnnym. Odwzorowanie schematów jest częścią fazy konfiguracji, nie improwizacją po przełączeniu.

Czy monday.com też będzie kiedyś trenować na naszych danych?
‍Zobowiązanie monday.com jest niezależne od planu: dane i treść klienta nie są używane do trenowania modeli i nie zezwala się na to podmiotom trzecim, a dostawcy modeli działają w reżimie Zero Data Retention. To istotna różnica konstrukcyjna wobec modelu, w którym możliwość wyłączenia jednej z kategorii danych jest funkcją posiadanego planu. Zobowiązanie warto oczywiście weryfikować w AI Trust Center, tak samo jak każde inne.

Co z RODO i lokalizacją danych?
‍Platforma ma certyfikaty SOC 1/2/3 Type II oraz ISO 27001, 27017, 27018 i 27701, ze zgodnością z RODO i HIPAA. Dane klienta nie są używane do trenowania modeli AI, a dostawcy modeli działają w reżimie Zero Data Retention. Hosting danych w regionie UE (Niemcy) jest dostępny na planie Enterprise. Na planie Pro dane domyślnie znajdują się w regionie US.

Jira jest tańsza, mamy już wykupione licencje.
‍Porównajcie całkowity koszt, nie cenę licencji. Do rachunku należą dodatki Marketplace zapewniające funkcje, które w monday.com są w standardzie, koszt utrzymania infrastruktury dla Data Center, czas administratora i nieuchronny koszt migracji do chmury, która i tak nastąpi. W dużych instancjach same licencje typowego zestawu dodatków to koszt rzędu 150–200 tys. PLN rocznie. Nie podajemy tu cen monday.com, bo zależą od planu i skali, a porównanie cenników prowadzi do złych wniosków. Przynieście listę dodatków i liczbę użytkowników, policzymy oba rachunki na Waszych danych.

Czy monday.com obsłuży nasze zgłoszenia serwisowe i procesy ITSM?
‍Tak, w tej samej platformie. monday service to pełny system ticketowy: portal dla zgłaszających, kolejki, SLA, baza wiedzy i automatyczna klasyfikacja zgłoszeń przez agenta AI. Nie jest to osobny produkt kupowany obok, co dla organizacji utrzymującej dziś Jira Service Management obok Jiry oznacza jeden rachunek i jedno środowisko mniej. W wymagających wdrożeniach osadzonych głęboko w ITIL przechodzimy zakres funkcja po funkcji na etapie audytu.

Kto realnie przeprowadza taką migrację?
‍Przy skali enterprise pracujemy w układzie trzech stron: zespół techniczny CXLABS prowadzi projekt i odpowiada za wynik, zespół monday.com odpowiedzialny za ścieżkę migracyjną i synchronizację Jira ↔ monday.com wchodzi w projekt z priorytetową ścieżką eskalacji, a niezależny konsultant z portfolio takich migracji weryfikuje architekturę w punktach krytycznych. Po stronie klienta potrzebny jest sponsor wykonawczy i dedykowane PMO. Przy mniejszych wdrożeniach ten układ się upraszcza.

Cała firma żyje w ekosystemie Atlassiana. Nie zepsujemy spójności?
‍Możliwy jest model hybrydowy. monday.com pobiera dane z narzędzi Atlassiana, a monday docs może częściowo przejąć rolę Confluence. Nie każda organizacja musi migrować całość i nie każda powinna.

Od czego zacząć

Pierwszym krokiem nie jest wybór narzędzia, a policzenie tego, co już macie. Ile projektów jest realnie używanych, które pola i procesy jeszcze coś znaczą, za jakie dodatki płacicie i co one robią, ile kosztuje utrzymanie infrastruktury i czas administratora. Bez tych liczb każda rozmowa o migracji jest rozmową o wrażeniach, także ta o cenach.

Dlatego proponujemy konkret. Przyjdźcie na godzinne spotkanie z listą dodatków Marketplace, liczbą użytkowników i orientacyjną liczbą projektów. Wychodzicie z niego z trzema rzeczami: porównaniem pełnych rachunków dla Waszej skali, wstępnym zakresem migracji z podziałem na to, co przechodzi natywnie, a co wymaga dedykowanego mechanizmu, oraz realnym harmonogramem. Bez zobowiązania i bez prezentacji o naszej firmie.

Warto też wiedzieć, jak wygląda ryzyko po Waszej stronie. Audyt i pilot na projektach archiwalnych są osobnym etapem z własnym budżetem. Po pilocie widzicie na swoich danych, jak przenosi się Wasza konfiguracja, i dopiero wtedy podejmujecie decyzję o pełnym transferze. Można się zatrzymać po tym etapie i nikt nie zostaje z połową przeprowadzki.

CXLABS jest oficjalnym partnerem monday.com w Polsce. Przeprowadzimy migrację Twojej organizacji z Jiry, od kilkunastu użytkowników do środowisk liczonych w tysiącach, razem z konfiguracją, szkoleniami i opieką po przełączeniu. Umówmy to spotkanie.

Źródła

• Atlassian, harmonogram end of life Data Center — daty, zakres produktów objętych i wyłączonych, zasady odnowień i rozszerzonego utrzymania
• Atlassian, opcje ścieżki do chmury — rozszerzone utrzymanie po 28 marca 2029 wyłącznie w drodze wyjątku
• Atlassian, Data contribution FAQ — tabela ustawień domyślnych według planu, zakres aplikacji, wyłączenia, retencja, mechanika najwyższego aktywnego planu
• Atlassian, dokumentacja ustawień data contribution
• Atlassian, czym jest plan Enterprise — progi wejścia na plan umożliwiający wyłączenie metadanych
• monday.com, migracja danych z Jiry — procedura z etykietą wyzwalającą i transferem partiami
• monday.com, import z Jira Server — ograniczenia mapowania pól, brak podelementów, plan Enterprise, zapowiedź wycofania
• monday.com AI Trust Center oraz Trust Center
• monday.com, dokumentacja data residency
• monday.com, komunikat o infrastrukturze dla agentów AI
• monday.com, historia klienta: Vistra
• monday.com, historia klienta: Canva (Growth Marketing Creative)
• Dane o strukturze skryptów, pluginów i pól dodatkowych: audyty migracyjne CXLABS

‍