Van egy visszatérő pillanat a nagyvállalati IT-ben. Valaki felveti egy értekezleten, hogy frissíteni kéne a Camunda-motort a core alatt, mert közeleg a Camunda 7 támogatás vége, és pont az a verzió az, amin a folyamataitok futnak. A következő kérdés magától adódik: pontosan mit is csinálnak ma ezek a folyamatdefiníciók, és mi mást érint, ha hozzájuk nyúlunk. Ahogy a legtöbb legacy rendszernél, itt is csend a válasz.
Sok hazai biztosító, bank és telco ült rá évekkel ezelőtt a Camunda 7-re, hogy azon vigye a folyamatorkesztrációt (elszámolás, kárrendezés, hitelbírálat, onboarding), és azóta ez csendben, megbízhatóan járta a maga útját. Csakhogy időközben maga a platform is átalakult alattatok. Érdemes végignézni, mi változott, mert ez a következő egy-két év egyik halogathatatlan döntése lesz.
Mi történt a Camundával öt év alatt: a Camunda 7 támogatás vége és ami utána jön
Három nagyobb váltás futott le, gyors egymásutánban.
A korábbi főverzió kifut a támogatásból. A Camunda 7 Community Edition 2025 októberében megkapta az utolsó kiadását (7.24), a GitHub-repót archiválják, új közösségi verzió nem jön. Az Enterprise Edition tovább él: a támogatást a gyártó 2027-ről 2030 áprilisáig hosszabbította (utána még van fizetős kiterjesztett támogatás 2032-ig). Vagyis nincs holnapi tűzoltás, de van egy határidő, ami közeledik, és amivel a board felé tervezni kell.
A Camunda 8 nem a 7 új verziója, hanem másik architektúra. A régi motor jellemzően a Java-alkalmazásba ágyazva, relációs adatbázisra támaszkodva futott. A 8-as egy teljesen újraírt, felhő-natív motorra (Zeebe) épül, és a beágyazott mód, amire sok korábbi integráció támaszkodott, megszűnt. Neked ebből egy dolog számít igazán: a 8-ra váltás nem verziófrissítés és nem könyvtárcsere, hanem a meglévő BPMN-folyamatok és integrációk gyakorlati újraépítése az új minták mentén. Ez nem egy karbantartási ablak, hanem egy projekt.
Megjelent az agentic AI-irány. A Camunda 8.8-tól a gyártó az orkesztráció köré épített AI-ügynököket helyezi a középpontba: a determinisztikus folyamatokat dinamikus, AI-vezérelt lépésekkel vegyíti. A saját 2026-os felmérésük szerint a szervezetek 71 százaléka használ már valamilyen formában AI-ügynököt, de a használati eseteknek csak 11 százaléka jutott el éles üzembe. A logika, amit hangoztatnak (hogy az AI-t is orkesztrálni és kontrollálni kell, mint bármely más végpontot a folyamatban), védhető. De egy új képességrétegről beszélünk azon a platformon, aminek a régi verziójáról épp le kéne jönnöd.
A valódi kérdés nem a Camundáról szól
Könnyű ezt tisztán technikai migrációként kezelni: van egy régi verzió, van egy új, tervezünk rá egy projektet. A gyakorlatban viszont ugyanaz a fal jön szembe, mint minden más legacy döntésnél.
A Camunda 7-es folyamataitok üzletkritikusak, évek alatt csiszolódtak a helyükre, és jó eséllyel ma már senki nem látja át teljesen a végüktől a végükig, hogy mit csinálnak és mihez nyúlnak. Ott vannak a peremfeltételek, a kivételkezelések, a más rendszerekkel való összekötések, amiket annak idején valaki jó okkal épített be, csak azóta lecserélődött a csapat fele. Ez a szokásos legacy-teher: a kritikus tudás néhány ember fejében él, a dokumentáció (ha van) ellentmondó, és most kapott egy határidőt is.
Amíg ez a kép nincs meg, a migrációs döntés becslésen áll, nem tényeken. A „menjünk 8-ra”, a „maradjunk EE-n 2030-ig”, vagy a „váltsunk más platformra” közül bármelyik lehet a jó válasz, de csak akkor tudod megvédeni a board előtt, ha látod, mi mit érint a mostani folyamataitokban. Enélkül vagy túlbiztosítod a projektet, vagy menet közben jönnek a meglepetések.
Előbb a rálátás, aztán a döntés
Itt kapcsolódik a munkánk. A Nitro Legacy Explorer a meglévő kódbázist, a BPMN-folyamatokat és az adatmodellt egyetlen kereshető, ellenőrizhető tudásréteggé köti össze. Nem egy újabb, polcra kerülő dokumentáció: minden állítás visszavezethető a forráskód vagy a folyamatdefiníció konkrét pontjára, így egy szakértő napok alatt leellenőrzi, nem hinni kell neki. A „mi mást érint, ha ehhez a folyamathoz nyúlunk” kérdésre konkrét, hivatkozott lista a válasz, a hatáselemzés pedig hetekből percekre rövidül. A Camunda-döntésedhez így előbb megkapod a valós kiindulási képet: mit csinálnak ma a folyamataitok, mely rendszerekhez és adatokhoz nyúlnak, hol vannak a rejtett függőségek.
Az eredmény YAML és markdown a ti gitetekben, a meglévő eszközeitekbe (Copilot, Cursor és társaik) köthető. Ha holnap leállítasz minket, a tudásréteg akkor is a tiéd marad, a kritikus tudás nem sétál ki egyetlen nyugdíjazással. Nem ígérünk egygombos csodát és nem is kétéves nagyprojektet ahhoz, hogy ez látszódjon: egy általatok választott folyamaton hetek alatt megmutatható, mit ad. Nem magát a migrációt kezdjük el, hanem a tényeket teremtjük meg alá, amikre a döntést alapozhatod.
Ha szívesen megnéznéd egy saját, kisebb folyamatotokon, mit hoz ki belőle, foglalj egy 30 perces beszélgetést, vagy nézd meg közelebbről a Nitro Legacy Explorert. Onnan együtt eldöntjük, van-e értelme a következő lépésnek.
Források a Camunda-változásokhoz: Camunda 7 EoL bejelentés, Camunda 7 Enterprise EoL hosszabbítás, Camunda 7 → 8 migrációs stratégia, Camunda 8 vs 7 architektúra, Agentic orchestration a Camundában, State of Agentic Orchestration 2026.
