Camunda 7 to 8: what changes in your models, code and data

Moving from Camunda 7 to Camunda 8 changes three things. Models keep their BPMN, but Camunda 7 extension attributes are converted and JUEL expressions become FEEL. JavaDelegates become job workers that run outside the engine. Running instances move with the Data Migrator or finish on Camunda 7. Camunda 7 Enterprise remains an option until April 2030.

Camunda 7 Community Edition reached end of life in October 2025, and its last release is 7.24. The Community Edition receives no further fixes from Camunda. Camunda 7 Enterprise is supported until April 2030, with paid extended support to April 2032.

Neither date is a legal deadline. Each ends the vendor’s fixes and support for an edition, and neither stops a running engine. What remains after them is your own risk: a security flaw in the engine, or in a library it depends on, with no fix from Camunda.

Camunda 8 releases carry their own dates. Camunda 8.8 came out in October 2025, 8.9 on 14 April 2026 and 8.10 on 13 October 2026, and standard support for 8.8 ends on 13 April 2027. A migration plan has to read both sets of dates.

Three paths lead on from Camunda 7, and the choice comes before any migration work.

1. Camunda 8. The platform Camunda develops, with the Zeebe engine in the Orchestration Cluster from 8.8. In production, Camunda 8 Self-Managed has needed a licence since 8.6, released in October 2024; SaaS is the alternative.
2. Camunda 7 Enterprise. Supported until April 2030, with paid extended support to April 2032. It needs an Enterprise subscription, and it moves the migration later rather than removing it.
3. A community fork. Operaton, CIB seven and Fluxnova continue the Camunda 7 code outside Camunda. You keep the Camunda 7 programming model and depend on each fork’s maintainers for fixes.

Staying on Camunda 7 is a real option for a defined period, with Enterprise or with a fork. The sections below cover the move to Camunda 8, where your models, code and data change.

Camunda 8 executes BPMN and DMN models, so most of each diagram carries over. What changes is the layer Camunda 7 added to the diagrams.

• Extension attributes. Camunda 7 stores implementation details in its own attributes: delegate classes, expressions, listeners, input and output mappings. Camunda 8 uses its own extension elements for job types and variable mappings, so each task needs converting.
• Expressions. Camunda 7 evaluates JUEL, Camunda 8 evaluates FEEL. Gateway conditions, timers and variable mappings written in JUEL are rewritten. A JUEL expression that calls a Java method or a Spring bean has no FEEL equivalent, so that logic moves into a job worker.
• Elements. Check each element type your models use against the Camunda 8 documentation for your target version. A construct without a direct equivalent needs remodelling.
• Forms and user tasks. Embedded forms tied to the Camunda 7 web applications need a new home, in Camunda forms or in your own front end. User tasks move to Tasklist or to your own task list.

Inventory every deployed model version, not only the versions in source control. A running instance may sit on an old version that nobody has opened since it was deployed.

In Camunda 7, a JavaDelegate runs inside the engine, often in the same transaction as the engine’s own state change. In Camunda 8, the engine creates a job. A job worker, a separate process you run, fetches the job through the Camunda 8 client, does the work and completes or fails the job.

That split has three consequences for your code.

• No shared transaction. The worker’s database write and the engine’s state are no longer one transaction. Design each worker to be idempotent, because a job can be delivered again after a timeout.
• Engine API calls change. Code that calls the Camunda 7 Java API, such as RuntimeService and TaskService, moves to the Camunda 8 client and its APIs. Queries over history need a new source.
• Listeners and scripts. Execution and task listeners, and script tasks written in Groovy or JavaScript, each need a decision: a job worker, a FEEL expression or a change to the model.

A JavaDelegate with clean boundaries, reading variables in and writing variables out with no engine calls, ports to a job worker with little change. The effort sits in the delegates that reach into the engine.

Process instances still running on Camunda 7 at cutover have three ways forward.

• Drain. New instances start on Camunda 8, and old ones finish on Camunda 7. Both engines run in parallel for as long as the longest instance takes.
• Migrate. The Camunda Data Migrator moves running instances from Camunda 7 to Camunda 8. Test it against a copy of your production data before you rely on it.
• Mix. Drain the short-lived processes and migrate the long-running ones.

History is a separate decision. Settle what you must keep for audit and reporting, for how long, and where it lives once Camunda 7 is switched off.

A model converted from Camunda 7 is proven when it takes the same path on Camunda 8 for the same input. For each process, run a set of cases on both engines and compare the path through the model, the variables at the end and the calls to other systems. Cases taken from production, with personal data removed, catch what invented cases miss. Automate the comparison, because you will run it again after every fix.

Target a Camunda 8 version whose support dates cover your cutover and the months after it. As of 17 October 2026, the newest release is 8.10, published on 13 October 2026, and standard support for 8.8 ends on 13 April 2027. Check the dates Camunda publishes for your target before you commit.

Choose the cutover per process, not for the whole estate at once. A single switch suits a small estate with short processes. A process-by-process move suits an estate where each process has its own owner and its own risk.

The dates in this article were checked on 17 October 2026 against Camunda’s announcements. How we plan and carry out the move is on the page Camunda 7 to 8 migration.