Flowable and Camunda 7: What the Compatibility Engine Really Covers

Flowable names Camunda 7 in its documentation exactly once, and only for one thing: in-flight process instances. The sentence sits in the step “Step Two: Migrate database” and reads: “Install Flowable and configure it to use your existing (or duplicated) database. If you have in-flight process instances, you may need to enable the Flowable 5 compatibility engine.” Right after it comes the only mention of Camunda 7 in that documentation: “This works for any Flowable 5 equivalent engine (such as Activiti 5 and Camunda 7).” (documentation.flowable.com, Migration Guide)

The rest of a Camunda 7 estate is the Java code written against org.camunda.bpm.engine and the camunda: extension namespace in the models. For that part, Flowable publishes no migration guide. We counted. On 29 October 2026 we fetched every URL in Flowable’s own three sitemaps. That came to 731 pages of Enterprise documentation, 42 of the 43 pages of open source documentation and 470 website pages. The string “org.camunda” appears on none of these pages, and “camunda:” on none of the 731 Enterprise documentation pages.

Flowable is a workflow engine, and its maker is based in German-speaking Europe. Flowable AG has its head office at Baslerstrasse 60 in Zurich, listed under “Registration number: CHE-105.136.021”. The same imprint names Flowable Deutschland GmbH in Stuttgart (flowable.com/imprint). That says nothing about how widely the product is used. None of the 470 URLs in the website sitemap sat under /de/ on 29 October 2026. Below, what Flowable documents is marked as documented, what is missing as missing, and what comes from marketing as a marketing claim.

Camunda 7 vs Flowable: what does Flowable cover, and what does it leave out?

Two pages are easy to mix up, and the difference decides what you can quote. One is the Migration Guide in the Enterprise documentation. Camunda appears there twice. The other is the migration guide in the open source documentation. The word Camunda does not appear there at all: “This guide describes the various things that are needed when migrating from Flowable or Activiti v5.x to Flowable V6.”

The Enterprise page is mainly about something else too. Its opening sentence reads: “In this migration section of the documentation we'll look into migrating from Flowable Open Source to a licensed Flowable product version.” Camunda 7 appears on that page only inside brackets. So the Camunda statement sits in a document whose subject is a different migration.

Flowable traces the path to the engines’ shared ancestry. In a post published on 22 October 2019, Flowable places Camunda 7 in the fifth engine generation: “a fork was taken from Activiti to create Camunda (currently version 7, although still based on the 5th generation process engine)”. That is why an engine called “Flowable 5 compatibility” applies.

What the Flowable 5 compatibility engine covers, and what Flowable leaves open

Flowable itself bases the coverage on experience: “The compatibility engine and validation rules have been implemented taking into account those BPMN constructs and patterns which we have seen prevalent at customers.” If you want to check whether your estate falls inside that, there is no list to check against. The section that would hold it is called “Unsupported BPMN Constructs” and consists of exactly two sentences. The first is the one just quoted. The second reads: “In case an incompatibility is discovered that is not shown in the validations or not covered by the compatibility engine, don't hesitate to contact your Flowable representative!” The documented route from an unknown case to an answer runs through your Flowable representative.

For the models, Flowable names the technique “DUAL runtime technology” and hedges its reach with the word “many”: “In many cases, you will not need to adjust your models, as Flowable's DUAL runtime technology can automatically convert many common legacy extensions.”

Why do your models leave the Java question open?

The camunda: namespace is tied to the Java API. On its reference page for Camunda 7.24, Camunda writes: “The following attributes are extension attributes for the camunda namespace http://camunda.org/schema/1.0/bpmn.” The type entries point straight at classes from the Camunda package, such as “org.camunda.bpm.engine.delegate.Expression” (docs.camunda.org, Camunda BPMN Extension Attributes). We counted the sections of that page on 29 October 2026: 53 extension attributes, each with its own block. Camunda gives no total there, so the 53 is our count. For none of these attributes does Flowable say whether or how it is handled.

Flowable says plainly that the models are only part of it: “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”. Flowable gives no frequency for this. How many of your service tasks sit behind a delegate class, only your own count will show.

How long do your instances stay in compatibility mode?

Until you migrate them yourself: “By default, any running instance will be handled by the Flowable 5 compatibility engine. In case you want to force such instances to not use the compatibility engine, you will need to perform process instance migration in Flowable Control, to ensure they use the updated model definition.” Flowable’s own open source page does not use the name “Flowable Control”. Under the heading “Enterprise-ready” it describes the Agentic Case Platform, in Flowable’s words “the enterprise runtime built on this open source foundation”. Among its features it lists: “monitor every detail of the runtime engines, analyze and download reports through our Control dashboard”. Neither page says whether this is the same tool. The migration page does place Flowable Control in the licensed product. Of the ACT_ADM_* tables it says: “This naming pattern is used for the Open Source Admin table and is replaced with the Flowable Control tables in the licensed Flowable product version.” The same page names Flowable Control as the prerequisite for leaving compatibility mode. The open source page does not name it at all. Flowable says nowhere how long the compatibility engine will keep shipping.

Does the history migrate? Here Flowable’s own pages contradict each other

The documentation does not promise it. The sentence on history sits in the introduction to the chapter “Legacy BPM migration steps”. It does not name Camunda and it is explicitly limited: “For some legacy products, the migration can automatically include existing historical data as well as in-flight, active process instances.” Which products are meant, it does not say.

The marketing goes further than the documentation. A blog post by a Flowable co-founder, dated 7 September 2022, puts the promise in capitals: “YOU CAN MIGRATE YOUR CAMUNDA AND ACTIVITI DATA TO FLOWABLE IN-PLACE, INCLUDING ACTIVE PROCESS INSTANCES AND HISTORY”. The Flowable Leap landing page states it without any limit and without naming a source system: “Migrate your BPMN instance to Flowable in-place, including all active processes and history.”

Both are vendor statements, and they carry different weight. The blog and the landing page are marketing texts. The migration documentation is what a project plans against. Base your plan on the documentation and put history on your list of open questions. A closely related question was asked in Flowable’s forum on 10 October 2025. It asked whether Flowable has an equivalent of Camunda’s User Operation Log, because the poster needed to migrate that data. On 29 October 2026 the post is still unanswered.

What Flowable Leap does, and where it stops

To check the models, Flowable offers a tool of its own. The documentation describes Flowable Leap accurately as an analysis tool: “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”. It reports incompatibilities and may suggest changes. Making the changes to your models is your job.

The same documentation states two limits. First: “The online version of Flowable Leap cannot connect to your database to analyze BPMN models.” To analyse a live Camunda 7 estate, you need the offline version. Second, its database drivers: “When using another database than H2, MySQL or PostgreSQL, the JDBC database driver needs to be added to the classpath of the application.” So H2, MySQL and PostgreSQL work as shipped. Oracle, SQL Server and DB2 need their driver added.

On access, the two pages describe different routes. The documentation still says the online version accepts BPMN XML files “without sign-in”. The landing page offers a form: “Fill out the form to get access to both, Flowable LEAP Cloud and the Flowable LEAP App.” The same page then adds: “You can also go directly to the Flowable LEAP Cloud Version.” All three sentences are live on 29 October 2026: the first in the migration documentation, the other two on flowable.com/leap-bpm-migration. The cloud version itself did not load for us that day, so we could not check whether it asks you to sign in.

Camunda 7 to Flowable: the two documented cases in Flowable’s forum

The first case is a thread of three posts from 31 January 2025. On 29 October 2026 the forum counted 527 views. The poster describes it like this: “The application is running on Oracle with Camunda 7.19 Community Edition.” (forum.flowable.org, thread 12032) The reply came the same day from an account the forum API lists as admin, moderator and staff. It is cautious: “Migrating from Camunda 7 to Flowable should be possible. Perhaps something has changed when we did the analysis.” Those are forum roles. The reply speaks in the first person plural (“when we did the analysis”). Either way it is a forum post, and it commits Flowable to nothing.

The path that worked had two steps that no documentation describes: “From what I can see there might be a problem when moving from Camunda 7 to Flowable 7.1.0 due to the removal of Liquibase. Can you please try to migrate to Flowable 7.0.1 first and then move from Flowable 7.0.1 to Flowable 7.1.0.” Flowable’s 7.1.0 release notes (7 October 2024) name the cause: Liquibase was removed from several engines and replaced with manual SQL files. The poster confirmed: “Thank you, that did the trick and worked perfectly!”

The thread does not say which version ran in the end. The advice was to go via Flowable 7.0.1 to 7.1.0, and the confirmation names no version. What the thread shows is a path onto the 7 line. It shows no move to the current major version. Flowable 8.0.0 came out on 27 February 2026. Its release notes set this condition: “Flowable 8 is now based on Spring Framework 7 and Spring Boot 4. There is no support for Spring Boot 3 anymore.” Which Spring version your estate uses is in your own dependency list.

The second case is a thread from 8 April 2025 with two posts, both by the same account. The poster writes: “I am currently trying to migrate from camunda 7 to flowable.” (forum.flowable.org, thread 12186) On PostgreSQL, the script “flowable.postgres.upgradestep.6200.to.6210.common.sql” failed because the table “act_ru_timer_job” was missing. The same day, the poster reported a path that worked: “Seems like it works when I first change camunda dependencies to flowable 6(.8.1) and then update to flowable 7(.1.0)”. This path also ends on the 7 line. No other account replied in the thread.

Two threads give you no success rate, no rule and no expectation. Flowable’s own forum search for the exact phrase “Camunda 7” returns ten topics on 29 October 2026. That finding covers this search on this day and nothing beyond it.

What Flowable Open Source leaves out

The core engines are under Apache 2.0: “They are Apache 2.0 licensed Open Source, with a committed community.” Since Flowable 7.0.0 (21 September 2023), the user interfaces are no longer part of it. The release notes for that version say: “This means that there are no UI applications, no content and form engines and the modules for Mule and some others are removed.” So Cockpit, Tasklist and Admin have no counterpart in Flowable Open Source.

On 29 October 2026 Flowable publishes no price table: the address flowable.com/pricing redirects to the home page. None of the 470 pages in the website sitemap names a price for a Flowable product or a “Community Edition” that day. Support response times are on Flowable’s support page, in a table headed “Flowable Support SLA” with the columns “Silver”, “Gold” and “Platinum”. For a “Severity One Incident” it gives 6 hours, 4 hours and 1 hour. These are response times: the rows are headed “Response Time SLA” (flowable.com/support).

How healthy is the Flowable project?

Solidly healthy, and that belongs in any fair assessment. The repository flowable/flowable-engine is not archived (“archived”: false) and is licensed under Apache 2.0. According to the GitHub API, it was last pushed on 18 October 2026. The same query returned 9,627 stars on 29 October 2026, the raw count for that day. In passing: Flowable’s own open source page still speaks of “more than 5k stars on Github”.

One module matters more than the stars. The documented path depends on org.flowable:flowable5-compatibility, and that module is still shipping. Maven Central carries it up to and including version 8.0.0, last published on 27 February 2026. It also sits in the modules directory of the main branch. The module’s POM file carries the name “Flowable 5 Compatibility” and does not mention Camunda once.

What does this mean for your decision?

The documented half is real. If in-flight process instances are your main worry, Flowable has a named mechanism for them. It names Camunda 7 explicitly and still ships the module in its current major version. We have not counted here what other target systems publish. This article measures Flowable’s own material only.

The undocumented half is your code and your models. How much it weighs depends on your estate. A few delegate classes and little logic in camunda: attributes make a short list. An estate that has grown for many years makes a long one. Neither Flowable nor we publish a figure for the effort or the duration. For Flowable that absence can be shown. There is none in the documentation, on the Leap landing page, in the blog or on the support page.

On timing, here is Camunda’s own sentence from its migration page: “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, checked 29 October 2026.) With an Enterprise subscription on 7.24 LTS, you can decide on Flowable without deadline pressure. If you run the Community Edition of Camunda 7, you have to decide anyway. Camunda 7 Community Edition reached end of life in October 2025 (Camunda forum, post dated 28 February 2025). Even then, Flowable is one of several options. The check we consider sound has three steps, and you can take all three yourself:

1. Count. How many delegate classes and how many camunda: attributes are in your estate?
2. Run your models through Flowable Leap. If your estate runs on an Oracle or SQL Server database, that means the offline version plus your own JDBC driver.
3. Ask Flowable in writing. Ask about exactly the attributes your count turned up. Flowable’s answer is the information that is not public.

Whatever you decide here, if a process is still done by hand, you can have that process automated; two weeks after the kickoff workshop it runs.

If you want to keep the architecture of Camunda 7, compare the forks. Camunda 7 Forks Compared puts CIB seven and Operaton side by side. And if you first want to know what the vendor’s own route means technically, Camunda 7 vs Camunda 8 goes through the documented differences.