Camunda 7 vs Camunda 8: What Actually Changes

The most important sentence in this comparison comes from Camunda itself, in its official migration guide: “It is important to understand that Camunda 8 is not a drop-in replacement for Camunda 7.” Camunda 8 is a separate platform, with a different engine, a different API and a different operating model.

How big the difference is for you comes down to one question. Does your engine run inside your application today, or beside it? If it runs beside it, the move is a project. If it runs inside it, the move is a rebuild.

The one difference all the others follow from

Camunda 7 lets you embed the engine as a library in your application. Both then run in the same Java process, share thread pools and can use the same data source and transaction manager. For Camunda 8, the documentation says: “the workflow engine in Camunda 8, Zeebe, is always a remote resource for your application, while the embedded engine mode is not supported.” (docs.camunda.io, Conceptual differences)

The same page names the consequence, and calls it conceptually “the only big difference”: “with a remote engine, you cannot share technical ACID transactions between your code and the workflow engine.” Your application may rely on a database write and a process step succeeding or failing together. That behaviour then has to be rebuilt in your business logic.

Wherever your application quietly depends on that shared transaction today, someone has to make a design decision. Those places live in your code, so finding them means reading the code.

What Camunda itself names as showstoppers

Camunda’s page on migration-ready solutions contains a remarkably frank paragraph (docs.camunda.io, Migration-ready solutions): “Given that Java delegates and the workflow engine are embedded as a library, projects can do dirty hacks in their code. Casting to implementation classes? No problem. Using a ThreadLocal or trusting a specific transaction manager implementation? Yeah, possible. Calling complex Spring beans hidden behind a simple Java Unified Expression Language (JUEL) expression?” That one too, Camunda says, is “doable!”

And the sentence after it: “Those hacks are the real showstoppers for migration, as they cannot be migrated to Camunda 8.”

Look past the dismissive tone. If your estate grew up on an embedded engine, these “dirty hacks” are simply what the engine allowed for years. They may well be the part of your estate that nobody has documented. The honest consequence: the number of process models tells you little about the effort of a migration. Your Java code, where these patterns live, sets it.

Which tools Camunda provides

Camunda documents its own set of tools for the move to Camunda 8 (docs.camunda.io, Migration tools). The page opens: “Camunda is invested in supporting and easing your migration from Camunda 7 to Camunda 8 with migration tools.” That is a real advantage of this route, and it belongs in any fair comparison.

Expect from these tools what you would expect from a compiler. They take over the mechanical work and leave the decisions with you.

Licensing and production use: a separate running cost

For the Camunda 7 Community Edition, Camunda states that “the entire software is provided under various open source licenses (mainly Apache 2.0 and MIT)”. For Camunda 8, the source code of the core components is under the Camunda License v1, and the compiled software under a proprietary licence. For production, Camunda writes: “To use the software in production, purchase the Camunda Self-Managed Enterprise Edition.” (docs.camunda.io, Licensing)

For an estate on the Community Edition, this is the real change. An open source library becomes a platform that needs a licence in production, plus a cluster that someone has to run. Together they become a running cost, on top of the project budget. Camunda publishes no price for this, and we publish none here either.

The comparison at a glance

When switching is not the right answer

We sell Camunda 7 migrations, which is exactly why this section is here. In the cases below, a switch to Camunda 8 is not the obvious decision.

First: you run 7.24 LTS with an Enterprise subscription. Then Camunda maintains 7.24 LTS for the Enterprise Edition until April 2030. For the Enterprise Edition, Camunda keeps shipping patch releases and Environment Update Releases with newly supported environments. No date forces you into anything. Anyone selling you urgency in that position is selling you a date Camunda has not published.

Second: your engine is deeply embedded. Then the move to Camunda 8 is the rebuild described at the top. Camunda’s guide says the effort “greatly depends on how your existing Camunda 7 solution is built”. The showstoppers above grow out of the embedded design. The forks of the Community Edition deserve at least a look before you commit, and Camunda 7 Forks Compared sets them side by side. Which targets exist, and the case against each one, is set out in Camunda 7 end of maintenance per version.

Your own estate settles both cases. A comparison table, ours included, is only the starting point for that check. If a process alongside your estate is still done by hand, you can have that process automated, live two weeks after the kickoff workshop.

If you are still unsure which of the two products you actually run, What is Camunda? gives four quick checks. Only the first one needs access to your code.