Artykuł Sezon grillowy czas start pochodzi z serwisu Nekken.

Artykuł Za nami kolejny event Runmageddon pochodzi z serwisu Nekken.

Artykuł Spotkanie wielkanocne pochodzi z serwisu Nekken.

Artykuł Partner Activation Day 2026 pochodzi z serwisu Nekken.

Artykuł Pizza Day 2026 pochodzi z serwisu Nekken.

Artykuł Podsumowaliśmy 2025 rok podczas firmowej imprezy pochodzi z serwisu Nekken.

Artykuł Dobre wieści z frontu cyfryzacji administracji skarbowej pochodzi z serwisu Nekken.

Artykuł Poznaj Nas pochodzi z serwisu Nekken.

Artykuł Wyjazd integracyjny 2025 pochodzi z serwisu Nekken.

Największe zmiany techniczne
Przejście na Camundę 8 wiąże się z fundamentalnymi zmianami architektonicznymi. Najważniejsza z nich dotyczy samego silnika, który w nowej wersji działa zdalnie. W Camundzie 7 silnik mógł być wbudowany bezpośrednio w aplikację, co pozwalało na współdzielenie transakcji bazodanowych. W ósemce silnik Zeebe działa jako osobny komponent, a komunikacja odbywa się przez gRPC. Oznacza to brak wspólnych transakcji, więc trzeba zupełnie inaczej myśleć o spójności danych i stosować wzorce kompensacyjne.
Kolejna istotna zmiana dotyczy zmiennych procesowych. Camunda 8 akceptuje tylko typy proste lub JSON, więc trzeba przepisać kod wykorzystujący obiekty Java czy transformacje XML przez Camunda Spin. System wyrażeń również uległ zmianie – zamiast JUEL (Java Unified Expression Language) używa się FEEL (Friendly Enough Expression Language). Wyrażenia odwołujące się do beanów Springa przestają działać, a logikę trzeba przenieść do zewnętrznych serwisów. Również cały system integracji działa inaczej. Konektory, delegaty i listenery wymagają przepisania na nowy model oparty o job workers. Stare integracje HTTP i SOAP trzeba będzie zaimplementować od nowa.

Jak przebiega migracja?
Proces migracji rozpoczyna się od dokładnej inwentaryzacji. Trzeba wiedzieć, ile mamy modeli BPMN i DMN, gdzie znajdują się skrypty, delegaty i listenery, oraz jakie integracje są wykorzystywane. Camunda udostępnia Migration Analyzer – narzędzie, które automatycznie skanuje modele i wskazuje elementy wymagające zmian. Następnie należy podjąć kluczowe decyzje architektoniczne. Trzeba określić model wdrożenia Camundy 8 (self-managed czy SaaS), zdecydować o strategii dla aktywnych procesów oraz ustalić, jak długo oba systemy będą działać równolegle. Konwersja modeli i kodu to kolejny etap. Diagram Converter automatycznie przenosi diagramy BPMN i DMN, ale to tylko początek. Wyrażenia, listenery i delegaty wymagają ręcznej refaktoryzacji, a logika biznesowa często musi zostać przeniesiona do zewnętrznych serwisów.

Migracja danych to szczególnie delikatny moment. Camunda oferuje Data Migrator do przenoszenia aktywnych instancji, ale można też zostawić stare procesy w siódemce do naturalnego zakończenia lub wdrożyć rozwiązanie hybrydowe. Wdrożenie powinno odbywać się etapami – najpierw testy w środowisku testowym, potem staging z pełnym monitorowaniem, a na końcu canary deployment w produkcji. Ważne jest obserwowanie wydajności, latencji i możliwych przeciążeń oraz przygotowanie planu awaryjnego.

Największe wyzwania
Nie wszystkie elementy BPMN są jeszcze w pełni wspierane w Camundzie 8, więc przed migracją warto dokładnie sprawdzić dokumentację kompatybilności. Szczególnym problemem są listenery – jeśli duża część logiki znajduje się w execution listeners czy task listeners, trzeba ją przenieść do job workers lub zewnętrznych serwisów. Najtrudniejszą zmianą mentalną jest koniec ze wspólnymi transakcjami. W architekturach rozproszonych kluczowe jest zapewnienie spójności w sposób asynchroniczny i wykorzystywanie wzorców kompensacyjnych, takich jak Saga. Dodatkowo przez pewien czas utrzymywanie równoległych środowisk generuje podwójne koszty – dodatkowe serwery, testy, a zespół musi znać obie platformy. Warto też dokładnie sprawdzić model licencyjny, ponieważ w wersji open source niektóre komponenty mogą mieć ograniczenia w produkcji.

Alternatywy
Migracja to nie jedyna opcja. Jeśli procesy są stabilne i nie ma potrzeby skalowalności chmurowej, można pozostać na Camunda 7 Enterprise, która ma dłuższe wsparcie. Można też rozważyć alternatywne silniki BPM o podobnej architekturze, gdzie migracja może być łatwiejsza, nowoczesne orchestratory workflow lub forki Camundy 7, choć ta ostatnia opcja jest ryzykowna.
Interesującym rozwiązaniem jest strategia hybrydowa – projektowanie nowych procesów już w Camundzie 8, podczas gdy stare pozostają w siódemce. Takie podejście pozwala uniknąć dużego skoku technologicznego, choć wymaga przez jakiś czas utrzymywania dwóch systemów.

Podsumowanie
Migracja to duży projekt – techniczny, organizacyjny i kosztowy. Kluczem do sukcesu jest dokładna analiza przy użyciu Migration Analyzer, planowanie etapami i intensywne testowanie. Trzeba być realistą – część procesów może wymagać przepisania, a nie tylko konwersji. Jeśli procesy działają dobrze na siódemce, nie ma pośpiechu, szczególnie przy posiadaniu licencji Enterprise. Jeśli jednak potrzebna jest skalowalność i architektura chmurowa, warto zaplanować migrację na kilka miesięcy. Automatyczne narzędzia pomogą, ale większość pracy to przemyślana refaktoryzacja wymagająca zaangażowania doświadczonego zespołu.

Artykuł Camunda 8 – Czy warto migrować? Praktyczny przewodnik pochodzi z serwisu Nekken.