Camunda 7 to 8 migration, one process at a time
4 min read · Updated Nov 11, 2026
Camunda 8 is not an upgrade of Camunda 7 but a new engine. Here is what changes, what you have to rewrite, and how to move without a big-bang cut-over.
Why this is a migration, not an upgrade
Camunda 7 runs as a library inside your Java application or as a shared engine next to it. Your process code (Java delegates, listeners, scripts) runs in the same process as the engine and writes to the same database.
Camunda 8 is built differently. The workflow engine, Zeebe, runs as its own cluster. Your code no longer runs inside the engine: it runs in job workers that ask the engine for work over the network and report the result. Operate, Tasklist and the other Camunda 8 tools read from that cluster, not from your database.
That design is what lets Camunda 8 scale, but it means a Camunda 7 project cannot simply be pointed at a new version. Some parts move as they are, some need to be adapted, and some need to be rebuilt.
What changes, piece by piece
| Camunda 7 | Camunda 8 | What it means for you |
|---|---|---|
| BPMN diagrams | BPMN diagrams | Mostly reusable, with Camunda-specific attributes converted |
| Java delegates and listeners | Job workers | Rewritten as workers that run outside the engine |
| JUEL expressions | FEEL expressions | Conditions and mappings rewritten in FEEL |
| Embedded and generated forms | Camunda Forms or your own forms | Embedded HTML forms have to be rebuilt |
| DMN decision tables | DMN decision tables | Usually move as they are |
| Engine history in your database | History in the Camunda 8 cluster | Old history does not move by itself |
Camunda publishes a migration guide and tools that convert diagrams and point out what needs to change. They are worth running early: they turn a vague worry into a list.
The two things teams underestimate
Running instances. Cases that started on Camunda 7 are still running when you switch. The usual choices are to let them finish on Camunda 7 while new cases start on Camunda 8, or to move them with dedicated tooling. Either way, you need to know how many there are and where they are.
History. Auditors, support teams and process owners still need to look up last year's cases after the move. If Camunda 7 is switched off, that history has to live somewhere readable.
Migrate one process at a time
A big-bang migration means rewriting everything, testing everything and switching on one date. It rarely goes to plan. A steadier approach is to move one workflow at a time:
- Inventory. List every workflow, form, decision table, piece of code and running instance.
- Pick a first workflow. Choose one that matters but is not the most complex: it will teach you how long the rest will take.
- Check the target. Make sure the Camunda 8 cluster can receive the deployments before anything moves.
- Move and verify. Deploy the workflow with its forms and decisions, rewrite its workers, and run real cases through it.
- Keep the people's experience stable. If users keep the same inbox and the same forms, they do not need to care which engine runs underneath.
- Repeat, and keep Camunda 7 running only for what has not moved yet.
A checklist before you start
- Which workflows still have running instances, and how many?
- Which Java delegates, scripts and expressions need a job worker?
- Which forms are embedded HTML forms that must be rebuilt?
- Where will completed Camunda 7 cases be searched after the switch?
- Who signs off each workflow once it runs on Camunda 8?
In Bridge
Bridge connects to your Camunda 7 and lists what it finds: workflows, forms, decision tables, the code that needs a job worker, history, and the instances still running. You tick the workflows to move; the forms and decisions they use follow, and every item appears in a quote whose price is frozen when you send the request.
Before anything moves, Bridge checks that your Camunda 8 cluster can receive the deployments. The run then deploys with live progress and a record per item, and retries of the same items are free. Completed Camunda 7 instances stay searchable in a read-only Historic Archive, and because the task inbox and the forms stay the same, the people doing the work barely notice the engine change.