Przejdź do treści
szaman.it
← Wszystkie artykuły

Systemy zgłoszeń

Migracja z OTRS do Zammada: co przeniesie importer, a co zostawisz za sobą

Tomasz DziobaAWS Certified Solutions Architect, w IT od 2013

20 sierpnia 2026 · 7 min czytania

OTRS Community Edition dostał ostatnią aktualizację w grudniu 2020 roku. Wersja 6.0.30 i cisza. Jeśli twój system zgłoszeń wciąż na niej stoi, to codziennie parsuje maile od obcych ludzi kodem, w którym od ponad pięciu lat nikt nie załatał ani jednej dziury. A system zgłoszeń to nie aplikacja wewnętrzna. On z definicji przyjmuje ruch z zewnątrz.

Takich instalacji zostało sporo. OTRS był latami domyślnym wyborem: darmowy, dojrzały, dobrze udokumentowany. Firmy go wdrożyły, skonfigurowały i zostawiły, bo działał. Dalej działa. I to jest właśnie problem, bo nic nie zmusza do decyzji.

Trzy wyjścia z martwego systemu

Znuny. Fork rozwijany przez firmę, która latami prowadziła forum społeczności OTRS. Najbliższa kontynuacja: ten sam Perl, ta sama logika, te same pojęcia. I żyje — LTS 6.5 dostał łatkę w lipcu 2026, równolegle rozwija się linia 7.

OTOBO. Drugi fork tej samej bazy kodu, z mocniejszym naciskiem na ITSM. Rzadszy w Polsce, ale również aktywny.

Zammad. Nie fork, tylko osobny system: Ruby zamiast Perla, interfejs z tej dekady, inna filozofia. Przejście na niego to przeprowadzka, nie remont.

Jest jeszcze czwarta ścieżka, którą wymieniam z kronikarskiego obowiązku: komercyjny OTRS. Pod koniec 2024 roku EasyVista przejęła ponad 90 procent akcji OTRS AG i od tego czasu scala produkty w jedną ofertę. Może z tego wyjść coś dobrego. Ale kupowanie licencji w środku takiej fuzji to zakład o cudzą roadmapę.

Moje stanowisko: jeśli celem jest przetrwać przy minimalnym ruchu, wybierz Znuny. Jeśli i tak czeka cię projekt migracyjny, wyjdź z niego z systemem, który daje więcej niż święty spokój. Czyli z Zammadem.

Co naprawdę przenosi importer

Zammad ma oficjalny mechanizm importu z OTRS-a, obsługujący wersje od 3.1 do 6.x. Po stronie starego systemu instalujesz dwa pluginy dobrane do wersji: Znuny4OTRS-Repo i właściwy migrator. Import odpalasz z kreatora w przeglądarce albo z konsoli. Przy większej bazie tylko konsola, bo kreator lubi polec na timeoutach.

Przechodzą tickety z pełną historią i załącznikami. Przechodzą konta klientów, ale tylko tych z przypisanymi zgłoszeniami; martwe rekordy zostają na starym serwerze. Hasła przenoszą się od OTRS 3.3 wzwyż, przy starszych wersjach wszystkich czeka reset. I detal, który potrafi zepsuć weekend: znaczniki czasu w bazie muszą być w UTC, bo Zammad niczego sam nie skonwertuje.

Najciekawszy jest import różnicowy. Pełny import robisz w środku tygodnia, zespół dalej pracuje na starym systemie, a tuż przed przepięciem dosyłasz wyłącznie zmiany. Warunek jeden: między przebiegami nikt nie dotyka danych w Zammadzie. Dzięki temu samo przełączenie to godziny, nie noc z niedzieli na poniedziałek.

W planie przełączenia jest jeszcze poczta, o której wszyscy pamiętają na końcu. Adresy zgłoszeniowe muszą w jednym momencie przestać trafiać do OTRS-a i zacząć wpadać do Zammada, inaczej przez kilka godzin dwa systemy będą zakładać tickety równolegle. Technicznie to najprostszy krok całej operacji. Organizacyjnie — ten, który wymaga ustalenia godziny „zero" i trzymania się jej.

Czego importer nie załatwi? Niczego, co przez lata dobudowano obok. Kolejki znajdą swój odpowiednik w grupach, ale rozbudowane pola dynamiczne, procesy ITSM i własne moduły w Perlu nie mają dokąd się przenieść. To nie wada narzędzia, tylko inna architektura. Jeśli twój OTRS ma dwieście pól dynamicznych, migracja jest w istocie projektem porządkowania, a import danych będzie jej najłatwiejszą częścią.

Tu jestem ci winien uczciwość: tej konkretnej migracji nie mam jeszcze w portfolio. Zammada znam od środka, bo wdrażam go i prowadzę na nim własną obsługę zgłoszeń, natomiast opis importera pochodzi z dokumentacji i rozpoznania, jakie robię przed pierwszym takim projektem. Nie z przeżytej nocy przełączenia. Dlatego jedno powtórzę z naciskiem: zanim podejmiesz decyzję, zrób próbny import na kopii bazy. Zwłaszcza gdy u ciebie stoi nie czysty OTRS, a nowszy Znuny — dokumentacja wymienia wersje do 6.x i zgodności z linią 6.5 czy 7 nikt ci nie obieca.

Po drugiej stronie

O życiu po migracji mogę już mówić z pierwszej ręki, bo na Zammadzie obsługuję zgłoszenia we własnej firmie. U mnie stoi w Dockerze, za Traefikiem, który kieruje ruch do właściwego kontenera i sam wystawia certyfikaty Let's Encrypt. Aktualizacja systemu zgłoszeń to podmiana obrazu i chwila przerwy, nie popołudnie spędzone na perlowych zależnościach. Po latach oglądania instalacji stawianych z pakietów tę różnicę czuć co miesiąc.

Jedno zastrzeżenie do planowania zasobów: Zammad nie przyjedzie sam. Obok niego w kontenerach żyją PostgreSQL i Elasticsearch od wyszukiwarki pełnotekstowej — i to głównie ten drugi ustawia poprzeczkę pamięci dla całego serwera. Na maszynie, która ledwo ciągnęła starego OTRS-a, może być ciasno.

Sam produkt się rozwija: w marcu 2026 wyszła wersja 7.0 z pierwszymi funkcjami AI, w czerwcu — 7.1. Co Zammad potrafi na co dzień i dla kogo ma sens, opisałem w osobnym tekście, a jeśli agenci mają logować się firmowym kontem, jest też relacja z podpinania SSO przez Keycloak — razem z trzema pułapkami, na które wtedy trafiłem.

Kiedy zostać na Znuny

Są sytuacje, w których odradzam Zammada. Dwadzieścia procesów ITSM, własne moduły i ktoś w zespole, kto zna ten kod na pamięć? Znuny jest wtedy racjonalny: łatki bezpieczeństwa wychodzą, fork żyje, a koszt przeprowadzki przebiłby korzyść. To nie jest gorsza decyzja. To inna decyzja.

Ale jeśli twoja instalacja to kilka kolejek, kilkunastu agentów i konfiguracja z 2017 roku, której nikt już nie pamięta, to taki system nie potrzebuje kontynuacji. Potrzebuje nowego startu z przeniesioną historią.

Migracja, którą planujesz, trwa godziny. Migracja, która planuje się sama, trwa tygodnie.

Bo odkładana migracja ma to do siebie, że w końcu zrobi się sama: po awarii dysku, po włamaniu, po odejściu ostatniej osoby, która znała system. Wtedy nie ma próbnego importu na kopii ani różnicowego dosyłu. Jest eksport na szybko i nadzieja, że załączniki przeżyły.

Jeśli twój zespół wciąż loguje się do OTRS-a, potraktuj ten kwartał jako termin, który wyznaczasz sobie sam. A gdybyś chciał przejść to z kimś, kto Zammada zna od podszewki — od wdrożenia krok po kroku po integracje — napisz.

Pytania i odpowiedzi

Najczęściej zadawane pytania

Czy Zammad potrafi zaimportować dane z OTRS?
Tak. Oficjalny importer obsługuje OTRS od wersji 3.1 do 6.x i przenosi tickety z pełną historią i załącznikami oraz klientów powiązanych ze zgłoszeniami. Hasła przechodzą od OTRS 3.3 wzwyż, a import można wykonać etapami: najpierw pełny, potem różnicowy tuż przed przełączeniem.
Czy OTRS Community Edition jest jeszcze wspierany?
Nie. Ostatnie wydanie, 6.0.30, ukazało się w grudniu 2020 roku i od tego czasu nie ma łatek bezpieczeństwa. Kontynuacją tej bazy kodu są forki Znuny i OTOBO, a komercyjny OTRS od końca 2024 roku należy do EasyVista.
Znuny czy Zammad — co wybrać po OTRS?
Znuny, gdy instalacja ma rozbudowane procesy ITSM, własne moduły w Perlu i kogoś, kto to utrzyma, bo to najbliższa kontynuacja OTRS-a. Zammad, gdy zespół potrzebuje sprawnego helpdesku i woli nowoczesny system zamiast utrzymywania perlowego kodu.

Wdrażam systemy zgłoszeń, w tym Zammada — jeśli szukasz pomocy przy podobnym temacie, napisz.