Camunda 7 Migration: What Your Existing System Decides

Your existing system decides where a Camunda 7 migration can go. Four properties of your installation determine which targets stay open and which drop out. The first is how the engine is deployed. The second is the transaction boundary between the engine and your business code. The third is how much of your Java code depends on the Camunda 7 API. The fourth is where that code bypasses the public API.

Camunda says so in its own migration guide: “It is not sufficient to exchange a library; you might have to adjust your BPMN models, refactor code, and probably also re-architect your solution. This effort greatly depends on how your existing Camunda 7 solution is built.” (docs.camunda.io, Camunda 7 to Camunda 8 migration guide)

So this article looks at your installation alone and leaves the comparison of products to the articles linked at the end. For each of the four properties it names the artefact in your repository where you read it, and the finding that follows. That finding is what any comparison of targets has to start from. You can make all four findings today, without talking to anyone.

Why does your existing system decide the target?

Because two Camunda 7 systems can be further apart than two target products. Camunda describes this range itself: “Solutions range from small implementations with clean delegates to large solutions with hundreds of processes using internal API hacks.” (docs.camunda.io, Migration journey)

The Camunda sources read here hold no single combined list of the points where an existing system reaches a limit. The points are spread over seven pages. Three of them are “Conceptual differences”, “Migration-ready solutions” and “Migration journey”. Then come the Data Migrator’s pages on limitations and on variable types. The last two are the tooling pages on code conversion and on the Diagram Converter. Camunda documents these limits at length. The next four sections pull them together, and each one names the artefact where you read the finding.

Where can you see how your engine is deployed?

The artefact: your pom.xml or build.gradle. Your installation records which of the deployment scenarios documented by Camunda you run (docs.camunda.org, Architecture). If the engine is a dependency in your build and starts and stops with your application, the answer is clear.

If your application does not run on the JVM, Camunda names the case itself, under the heading “Polyglot applications (C#, Node.js)”: “When you run your application in Node.js or C#, for example, you exchange one remote engine (Camunda 7) with another (Camunda 8). As Zeebe comes with a different API, you need to adjust your source code.” (docs.camunda.io, Conceptual differences) What remains in that case is adapting your source code to a different API. Camunda names no change of architecture for it.

At the other end, Camunda’s migration journey names the case that has no equivalent in Camunda 8: “Your solution relies on an architecture that is not possible with Camunda 8. For example, software vendors that embedded Camunda 7 as a Java library into their own build, relying on shipping exactly one self-contained Java application.” Two sentences further on, the same page adds what goes with it: “Most often, you could still migrate those scenarios if you rearchitect the solution.” (docs.camunda.io, Migration journey) So this is a restriction with a condition attached. With a rebuilt architecture, migration stays possible in most cases, according to Camunda.

Do the engine and your business code share a transaction?

In Camunda 7, the step from one wait state to the next is a single transaction: “The transition from one such stable state to another stable state is always part of a single transaction, meaning that it succeeds as a whole or is rolled back on any kind of exception occuring during its execution.” The misspelling is in the source. On how the engine runs, the same page says: “The process engine is a piece of passive Java code which works in the Thread of the client.” (docs.camunda.org, Transactions in Processes)

For Camunda 8, Camunda reverses the rule, in its own guide “Migration-ready solutions”: “You should not trust ACID transaction managers to glue together the workflow engine with your business code.” A few lines further down, the same point appears in a form you can check: “A process solution that relies on five service tasks to be executed within one ACID transaction, probably rolling back in case of an error, will make migration challenging.” (docs.camunda.io, Migration-ready solutions)

The artefact: your engine configuration and your BPMN XML. Camunda 7 integrates with external transaction management as standard: “Out of the box, the process engine supports integration with Spring and JTA”. In the model, the counterpart is an attribute: “An asynchronous continuation before an activity is enabled using the camunda:asyncBefore extension” (docs.camunda.org, Transactions in Processes). For Camunda 8 the rule reads: “Instead, embrace eventual consistency and make every service task its own transactional step. If you are familiar with Camunda 7 lingo, this means that all BPMN elements will be async=true.” (docs.camunda.io, Migration-ready solutions) What you can count is therefore the reverse: how many of your BPMN elements carry neither camunda:asyncBefore nor camunda:asyncAfter today.

That count tells you how many places in your models run inside the engine’s transaction today without an asynchronous continuation of their own. On its own, it gives no effort figure.

How much of your Java code depends on the Camunda 7 API?

A Java delegate is defined by exactly one interface: “this class needs to implement the org.camunda.bpm.engine.delegate.JavaDelegate” (docs.camunda.org, Delegation Code). The search term for your inventory is therefore the package name org.camunda.bpm.

Camunda’s page on code conversion says which code is affected: “You must especially rewrite code that does the following:” It lists code that uses the Client API, with the examples “Starting process instances, correlating messages, managing tasks, etc.” It adds code that implements service tasks, meaning external task workers and Java code the engine calls directly. The same page sorts its conversion patterns into groups. Next to general patterns there are “Client code (code that calls the Camunda API)”, “Glue code (code executed by the process engine)” and test code. In the table of import replacements, the first row under “Remove” is the package org.camunda.bpm.engine.* (docs.camunda.io, Code Conversion). You can run the matching inventory in your own repository today. For every Java file with an import from org.camunda.bpm.*, ask whether it calls the Camunda API, is called by the engine, or is a test.

The artefact: your import statements. A tool that Camunda names in its migration journey can measure the same footprint: “The Code Migration Detector (based on ArchUnit) can check how much Camunda 7 API is used in your codebase to allow you refactor to reduce the footprint step-by-step.” (docs.camunda.io, Migration journey) That is the finding in its most robust form, checked against your own source code.

For converting this code, Camunda puts a route of its own first: its migration skill for AI agents. The overview page of the migration tools says: “Agentic migration (recommended): An AI coding agent uses the Diagram Converter for models and forms, lets you select an AI-first or recipe-assisted Java migration path, and migrates your tests to Camunda Process Test (CPT).” (docs.camunda.io, Migration tools)

Camunda’s Code Conversion page describes the recipe route like this: “Use OpenRewrite as an optional recipe-assisted path for repeated, supported, primarily syntactic Java transformations. It creates a deterministic first diff, but it does not complete a migration.” For these recipes Camunda names an access condition that stands out in a Community Edition system: “The use of camunda-7-to-8-code-conversion-recipes artifact requires access to the Camunda Enterprise Maven repository.” The condition concerns access to a repository, and the sentence is about that access alone. The same page also says: “The recipes are still under development. Expect recipes to work out-of-the-box only in simple scenarios.” (docs.camunda.io, Code Conversion)

Where does your code bypass the public API?

You find the fourth property by searching, because there is nothing to count. Camunda states it as three prohibitions for Camunda 8: “Never cast to Camunda implementation classes, use any ThreadLocal object, or influence the transaction manager in any way.” The next sentence adds a fourth requirement: “Java delegates should always be stateless and not store any data in their fields.” (docs.camunda.io, Migration-ready solutions)

The artefact: your Java source and your BPMN XML. Turned around, the prohibitions become search terms for your own code. They are casts to classes with .impl. in the package name, ThreadLocal, and any interference with the transaction manager.

The Camunda 7 documentation explicitly leaves this route open: “it is also possible to provide a class that implements the org.camunda.bpm.engine.impl.pvm.delegate.ActivityBehavior”. In the same paragraph it advises against it: “However, note that this is not a very good practice and should be avoided as much as possible.” (docs.camunda.org, Delegation Code) If your code followed that advice, this search finds nothing. If it did not, the search finds them by exactly this package name.

The second half sits in the model. For Camunda 8, Camunda advises against it: “Don’t call Spring beans in expressions (for example to leverage Java code to do data transformations).” (docs.camunda.io, Migration-ready solutions) In Camunda 7 BPMN XML, you find these places by two attributes, camunda:expression and camunda:delegateExpression. The Camunda 7 documentation describes the second like this: “The attribute camunda:delegateExpression is used for expressions which evaluate to a delegate”. Its examples there are ${myBean} and ${myBean.createDelegate()}. For camunda:expression, the same page shows ${myBean.myMethod(execution)}, a call to a bean method (docs.camunda.org, Unified Expression Language).

Camunda puts the consequence and the exception on the same page, its guide “Migration-ready solutions”. The consequence: “Such code cannot be executed within Camunda 8 FEEL expressions, and the logic needs to be moved elsewhere.” The exception: “If you write simple expressions, they can be migrated automatically, as you can see in the test case of the migration community extension.” (docs.camunda.io, Migration-ready solutions) What matters, then, is whether Java sits behind an expression.

What decides your Camunda 7 migration?

Which of your running instances and data come along?

The first question is whether you need to bring running instances along at all. Camunda’s migration journey says: “If you drain out your Camunda 7 processes, or if they are typically very short-lived, you do not need runtime instance migration.” (docs.camunda.io, Migration journey) With short-lived processes, this whole section does not apply to you, and that too is a property of your existing system.

If you do need to bring them, the content of your variable table decides. The Data Migrator lists variable types for which it skips the instance: “The following Camunda 7 variable types are not supported and will cause the process instance migration to be skipped”. Among them are “Java objects serialized as application/x-java-serialized-object like List, Set, Map, float, byte, char or custom types”. The consequence is on the same page, above the table. It is the first point under the heading “Unsupported types”: “Skip the entire process instance” (docs.camunda.io, Data Migrator: variables). You can count this in your own database before anything is migrated.

The state an instance is in right now counts as well. On joining parallel gateways, Camunda writes: “Process instances with active joining parallel gateways cannot currently be migrated. The migrator will skip these instances during migration.” On multi-instance elements: “Processes with active multi-instance elements can currently not be migrated.” For processes with a timer start event, the same page gives the prerequisite and the limit in a single point: “Timer start events: prior to migration, you must ensure that your process has at least one none start event. Processes that only have a timer start event cannot be migrated.” (docs.camunda.io, Data Migrator: limitations)

If your system runs CMMN, Camunda’s migration journey lists it among the features that are deprecated and not planned for Camunda 8 (docs.camunda.io, Migration journey). On the History Data Migrator, Camunda writes: “CMMN entities: CMMN user tasks and CMMN variables are not supported and are skipped during migration.” (docs.camunda.io, Data Migrator: limitations)

On asynchronous continuation, shortened versions go wrong, so here is the exact wording. Camunda writes: “Camunda 8 does not support asynchronous continuation before or after any kind of wait state.” It goes on: “Service-task-like activities are executed asynchronously by default in Camunda 8” and “a service task waiting for asynchronous continuation before will be correctly migrated”. So a service task with asyncBefore comes across correctly. An instance waiting asynchronously at another element, such as a gateway, would just carry on without waiting in the Camunda 8 model. Camunda says you might need to adjust the model before migration. The same page names two more prerequisites for migrating running instances. The first reads: “The minimum supported history level is ACTIVITY.” The second reads: “You must add an execution listener of type migrator to all your start events.” For history migration it names a different threshold: “The minimum required history level in Camunda 7 is FULL to ensure that sufficient data is available for migration.” (docs.camunda.io, Data Migrator: limitations)

Which parts do not exist in Camunda 8 at all?

Four more questions take a yes or a no, and you answer them on your own installation. Camunda lists them under “Conceptual differences” (docs.camunda.io, Conceptual differences):

• Engine plugins. “Process engine plugins are not available in Camunda 8, as such plugins can massively change the behavior or even harm the stability of the engine.”
• Cockpit and Tasklist plugins. “Cockpit or Tasklist plugins cannot be migrated.”
• CDI and OSGi. “Due to limited adoption, there is no support for CDI or OSGI in Camunda 8.”
• Jakarta EE application servers. “Camunda 8 doesn't provide integration into Jakarta EE application servers like Camunda 7 does.”

Then there is the form technology on your user tasks. In “Migration-ready solutions”, Camunda writes: “Use your own user interface for task forms or Camunda Forms; the other form mechanisms are not supported out of the box in Camunda 8.” (docs.camunda.io, Migration-ready solutions) Which technology you use shows on the user tasks in your models.

What can you run yourself today?

For the models, Camunda runs the Diagram Converter itself: “Use the hosted Diagram Converter at https://diagram-converter.camunda.io/. This option requires no local setup and is suitable for quick evaluations or one-off migrations.” On confidentiality, the same page says: “Your models are not stored on this platform, and all processing happens in-memory.” (docs.camunda.io, Diagram Converter) If your process models may not leave the company, this one sentence is the commitment you can hold the hosted version to. That commitment comes from Camunda.

The result is a list of findings at four levels. Two of them mean that the tool could not resolve the case. The first reads: “WARNING: A Camunda 7 concept cannot be directly mapped to a Camunda 8 equivalent.” The second reads: “TASK: Manual changes are required to make the diagram work in Camunda 8.” The third, “REVIEW: The conversion will modify some expressions or attributes.”, calls for a functional review. The fourth is the quiet one: “INFO: No action needed. Diagram conversion can successfully map attributes to the Camunda 8 implementation.” (docs.camunda.io, Diagram Converter)

Camunda’s migration journey describes how such an analysis turns into an estimate. For the analysis, the page names the “Migration Analyzer”. According to the page, Camunda’s consultants use rule-of-thumb numbers for how much effort typical tasks take. Your own estimate per task can be multiplied by the number of tasks from the analysis. In Camunda’s past projects, this gave “a good ballpark estimation” (docs.camunda.io, Migration journey). None of the sources read here names a threshold at which a number tips the decision.

The migration skill, which Camunda presents as the recommended route, takes in models, forms, Java code and Camunda 7 tests together. In Camunda’s description of the skill, the first step, “Assess migration scope”, inventories the files and estimates effort. The skill asks for the scope of the run, and one option is called “Assessment only”, described as “Inventories files and estimates effort without changes.” The Camunda pages read here do not say in what form this estimate comes out. On cost and duration, Camunda writes for both Java routes: “Neither path guarantees lower token use, cost, or migration time.” (docs.camunda.io, Migration tools)

What does a fork preserve, and what does that route depend on?

This is the cross-check on the first property. What a fork of the Community Edition preserves, each vendor states for itself. Operaton’s own FAQ says, about its 1.x line: “The 1.x versions of Operaton prioritize full compatibility with Camunda 7. Your BPMN models, process definitions, and execution logic will continue to work without changes.” The same page makes no such commitment for later versions. Operaton also names three options, the first being “embed the engine in your Java application (Spring Boot, Quarkus, Jakarta EE)” (operaton.org/faq). The FAQ names this embedded mode, which has no equivalent in Camunda 8, without tying it to a version line.

On the 1.x line, Operaton’s FAQ says: “The 2.x line is the active development line; 1.x continues to receive patch releases per the Roadmap.” The same FAQ gives the support window: “Each major/minor is supported for 6 months, until the next major/minor ships.” The roadmap it refers to lists the entry “End of Support 1.1” under August 2026 (operaton.org/roadmap). According to Operaton’s release list on GitHub, the last version of the 1.x line is 1.1.5, of 24 July 2026. Every release after it belongs to the 2.x line (GitHub, operaton/operaton).

This route has an inventory question of its own. CIB gives the search pattern itself: “You can search for the string pattern org.camunda.* inside the BPMN files to find the processes with the camunda namespace.” The reason stands next to it: “All such objects are stored in the database and are not automatically renamed to the cibseven namespace during migration”. Accessing them “may result in ClassNotFoundException”. The same page offers a way out. CIB names two configuration properties, useCibSevenNamespaceInScripting and useCibSevenNamespaceInReflection, that rename these objects on first access. CIB adds that they are included in the configuration files of the Tomcat, Wildfly and Run distributions from CIB seven 2.0 onwards. There, though, they are “disabled by default” (docs.cibseven.org, Camunda Migration). So the finding concerns your stored data. The properties rename persisted objects in the database on first access. The CIB page read here describes neither a dry run nor a way back. That has to be decided before the first access.

In none of the sources read here does Camunda comment on either project, for or against. The Camunda quotes and the vendor quotes in this article come from separate sources.

On its migration page, Flowable names Camunda twice. The first mention concerns running instances: “If you have in-flight process instances, you may need to enable the Flowable 5 compatibility engine. This works for any Flowable 5 equivalent engine (such as Activiti 5 and Camunda 7).” For class delegates on service tasks, the same document expects code changes: “In certain use cases, such as for example using class delegates for a service task, a change to the code will need to be applied”. At this point, Flowable documents no Camunda 7 history migration and no Camunda 7 code path (documentation.flowable.com, Flowable Migration Guide).

There is a checking tool on this route too, and its description holds the second of the two mentions: “Flowable Leap (Legacy Execution Analysis of Processes) is a tool that can analyze BPMN models from other BPM products, such as Camunda and Activiti, and highlight any incompatibilities with running them on Flowable.” One limitation matters as soon as your database is not one of the three it names: “Flowable Leap includes drivers for H2, MySQL and PostgreSQL”. The page also says: “The online version of Flowable Leap cannot connect to your database to analyze BPMN models.” (documentation.flowable.com, Flowable Migration Guide)

What this article deliberately leaves out about a Camunda 7 migration

A threshold. None of the sources read here says at how many process definitions, Java delegates or running instances a decision tips. The four properties can be established, but they cannot be turned into a threshold, and we do not invent one here.

For the same reason, this article gives no figure for effort, duration or cost. Nor does it say which deployment model is common. In none of the sources read here does a vendor publish numbers on that. A sentence claiming that most systems run embedded would be a guess.

The other side belongs here too. On its own migration page, Camunda writes: “Camunda 7 Enterprise Edition remains supported through April 2030, but we recommend all new projects be developed on Camunda 8.” (camunda.com/platform-7/migrate) And in its own migration guide: “While there is some urgency to start migration efforts, you are not yet under hard pressure.” (docs.camunda.io, Migration journey) Making the four findings today prepares that decision.

If a process alongside the migration is done by hand, you can have that process automated; two weeks after the kickoff workshop it runs.

Two articles go through the targets that appear here only as findings: Camunda 7 vs Camunda 8 sets the two products side by side. Camunda 7 forks compared compares CIB seven and Operaton.

If you would rather read the whole decision before you talk to anyone, the handbook The Camunda PATH works through it from start to finish.