Camunda 7 to 8 migration
We plan and carry out Camunda 7 to 8 migrations. We inventory your models, delegate code, expressions and running instances. JavaDelegates become job workers, JUEL expressions become FEEL, and running instances move with the Data Migrator or finish on Camunda 7. Staying on Camunda 7 Enterprise until April 2030 is also an option.
The task.
Camunda 7 Community Edition reached end of life in October 2025, and its last release is 7.24. Camunda 7 Enterprise support ends in April 2030. You have three paths, and each one costs something.
A migration changes more than the engine. Camunda 7 calls your Java code inside its own transaction. Camunda 8 hands the work to job workers outside the engine. Models, code, expressions and data each need a plan.
What we do.
- 01
Inventory
We list every model, JavaDelegate, listener, expression and running instance. You see what converts directly and what needs new code.
- 02
The path
Camunda 8, Camunda 7 Enterprise until April 2030, or a community fork such as Operaton or CIB seven. Camunda 8 Self-Managed in production needs a licence, so the licence is part of the decision.
- 03
JavaDelegates to job workers
Each delegate becomes a job worker with its own job type. Logic that relied on the engine’s transaction gets a new design.
- 04
JUEL to FEEL
Expressions in gateways, inputs and outputs move from JUEL to FEEL. We test each converted expression against your data.
- 05
Running instances
Running instances can finish on Camunda 7 while new ones start on Camunda 8. Or Camunda’s Data Migrator moves them across, tested on a copy first.
- 06
Cutover
We choose the cutover approach with you, process by process. Each switch has a date, a test and a fallback.
// Camunda 7: the engine calls the delegate inside its own transaction
-public class CheckCredit implements JavaDelegate {
- @Override
- public void execute(DelegateExecution execution) {
- String customerId = (String) execution.getVariable("customerId");
- execution.setVariable("approved", creditService.check(customerId));
- }
-}
// Camunda 8: a job worker fetches the job and completes it
+@JobWorker(type = "check-credit")
+public Map<String, Object> checkCredit(@Variable String customerId) {
+ return Map.of("approved", creditService.check(customerId));
+}Scroll the code sideways to read each line.
Schematic. In Camunda 7, the engine calls the delegate inside its own transaction. In Camunda 8, a worker fetches the job, does the work outside the engine and completes the job with the returned variables (the @JobWorker annotation of the Camunda Spring Boot starter). In the model, the delegate reference becomes a job type.
Typical engagements.
Migration assessment
We map your models, code, expressions and running instances. You get a written assessment with the three paths compared.
Process-by-process migration
One process moves at a time, tested on a copy. The others stay on Camunda 7 until their turn.
Migration with your team
We migrate the first processes together with your engineers. Your team migrates the rest, with our review.
Versions and dates.
From the vendors' published pages, checked on 17 October 2026.
Camunda 7 Community Edition reached end of life in October 2025; its last release is 7.24.
Camunda 7 Enterprise support ends in April 2030, with paid extended support to April 2032.
The current Camunda 8 release is 8.10, and standard support for 8.8 ends on 13 April 2027.
These dates end the vendor’s support, not the software; we checked them on 17 October 2026.
- Standard or open-source support ends
- Extended support
- Limited support
- Last checked 17 October 2026
- October 2025Ended :
Camunda 7 Community Edition reached end of life; the last release is 7.24.
- 13 April 2027 :
Standard support for Camunda 8.8 ends.
- April 2030 :
Camunda 7 Enterprise support ends; paid extended support to April 2032.
Is this for you?
A good fit
- You have Camunda 7 in production, Community or Enterprise Edition.
- Your Java team will own the job workers after the migration.
- You want the path chosen from an inventory, not from a guess.
Not a fit
- You expect a migration with no change to your Java code.
- You need people placed, with no technical lead on your side.
- You want licences resold, with no migration work.
Questions.
Can you migrate us from Camunda 7 to Camunda 8?
Yes, we plan and carry out Camunda 7 to 8 migrations. We start with an inventory of models, delegate code, expressions and running instances. JavaDelegates become job workers, and JUEL expressions become FEEL. Staying on Camunda 7 Enterprise until April 2030 is also an option. We choose the cutover approach with you.
Do we have to leave Camunda 7 now?
You do not have to leave Camunda 7 at once: Camunda 7 Enterprise support runs until April 2030, with paid extended support to April 2032. Camunda 7 Community Edition reached end of life in October 2025, with 7.24 as its last release. A community fork such as Operaton or CIB seven is a third path.
What happens to our running process instances?
Running instances either finish on Camunda 7 or move to Camunda 8 with Camunda’s Data Migrator. We decide per process, by how long its instances live.
How does JUEL become FEEL?
Each JUEL expression in a gateway, an input or an output is rewritten in FEEL, the expression language of Camunda 8. Simple comparisons convert directly. Expressions that call Java beans need a new design, often a job worker.
Which version are you on?
Tell us the platform, the version and what has to change. We reply with questions or a proposed next step.
Plan your migration