Flowable und Camunda 7: was die Kompatibilitäts-Engine wirklich abdeckt

Flowable dokumentiert für Camunda 7 genau eine Sache, und sie ist eng umrissen: laufende Prozessinstanzen. Der Satz steht im Schritt „Step Two: Migrate database“ und lautet: „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.“ Direkt danach folgt die einzige Nennung von Camunda 7 in dieser Dokumentation: „This works for any Flowable 5 equivalent engine (such as Activiti 5 and Camunda 7).“ (documentation.flowable.com, Migration Guide)

Für den anderen Teil eines Camunda-7-Bestands, also für den Java-Code gegen org.camunda.bpm.engine und für den camunda:-Erweiterungsnamensraum in den Modellen, veröffentlicht Flowable keinen Migrationsleitfaden. Das haben wir ausgezählt: Am 2. September 2026 haben wir jede URL aus Flowables drei eigenen Sitemaps abgerufen, 726 aus der Enterprise-Dokumentation, 42 der 43 aus der Open-Source-Dokumentation und 464 von der Website. Die Zeichenkette „org.camunda“ kommt auf keiner dieser Seiten vor, „camunda:“ auf keiner der 726 Seiten der Enterprise-Dokumentation. Die Kurzfassung dieses Befunds steht in unserem Überblick zum Wartungsende je Camunda-7-Version; hier ist er ausgezählt.

Flowable ist eine Workflow-Engine, und ihr Hersteller sitzt im deutschsprachigen Raum. Die Flowable AG hat ihren Sitz an der Baslerstrasse 60 in Zürich, eingetragen unter „Registration number: CHE-105.136.021“, und nennt im selben Impressum die Flowable Deutschland GmbH in Stuttgart (flowable.com/imprint). Über die Verbreitung des Produkts sagt das nichts, und keine der 464 URLs der Website-Sitemap lag am 2. September 2026 unterhalb von /de/. Was Flowable dokumentiert, ist unten als dokumentiert ausgewiesen; was fehlt, als fehlend; und was aus dem Marketing stammt, als Marketingaussage.

Camunda 7 vs. Flowable: was deckt Flowable ab und was nicht?

Zwei Seiten lassen sich leicht verwechseln, und der Unterschied entscheidet, was Sie zitieren dürfen. Die eine ist der Migration Guide der Enterprise-Dokumentation; dort kommt Camunda vor, zweimal. Die andere ist der Migrationsleitfaden der Open-Source-Dokumentation; dort kommt Camunda kein einziges Mal vor: „This guide describes the various things that are needed when migrating from Flowable or Activiti v5.x to Flowable V6.“

Auch die Enterprise-Seite handelt nicht in erster Linie von Camunda. Der Einleitungssatz lautet: „In this migration section of the documentation we'll look into migrating from Flowable Open Source to a licensed Flowable product version.“ Camunda 7 kommt auf dieser Seite nur in einer Klammer vor. Die Camunda-Aussage steht also in einem Dokument, dessen Thema ein anderes ist.

Dass es den Weg technisch überhaupt gibt, erklärt Flowable mit der gemeinsamen Herkunft. In einem Beitrag vom 22. Oktober 2019 ordnet Flowable Camunda 7 der fünften Engine-Generation zu: „a fork was taken from Activiti to create Camunda (currently version 7, although still based on the 5th generation process engine)“. Deshalb greift eine Engine, die „Flowable 5 compatibility“ heißt.

Was die Flowable-5-Kompatibilitäts-Engine abdeckt, und was Flowable offenlässt

Flowable beschreibt die Abdeckung selbst über Erfahrung: „The compatibility engine and validation rules have been implemented taking into account those BPMN constructs and patterns which we have seen prevalent at customers.“ Wer prüfen will, ob sein Bestand darunterfällt, findet keine Liste dafür. Der Abschnitt, der sie enthalten müsste, heißt „Unsupported BPMN Constructs“ und besteht aus genau zwei Sätzen. Der erste ist der eben zitierte. Der zweite lautet: „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!“ Der dokumentierte Weg vom unbekannten Fall zur Antwort führt über den Vertrieb.

Für die Modelle nennt Flowable die Technik „DUAL runtime technology“ und umschreibt ihre Reichweite mit einem Mengenwort: „In many cases, you will not need to adjust your models, as Flowable's DUAL runtime technology can automatically convert many common legacy extensions.“ Eine Zusage für alle Erweiterungen ist das nicht.

Warum die Modelle Ihnen die Java-Frage nicht abnehmen

Der camunda:-Namensraum ist mit der Java-API verschränkt. Camunda schreibt auf der Referenzseite von Camunda 7.24: „The following attributes are extension attributes for the camunda namespace http://camunda.org/schema/1.0/bpmn.“ Die Typangaben verweisen direkt auf Klassen aus dem Camunda-Paket, etwa „org.camunda.bpm.engine.delegate.Expression“ (docs.camunda.org, Camunda BPMN Extension Attributes). Wir haben die Abschnitte dieser Seite am 2. September 2026 ausgezählt: 53 Erweiterungsattribute, jedes mit eigenem Block. Camunda nennt dort keine Gesamtzahl, die 53 sind unsere Auszählung. Zu keinem dieser Attribute sagt Flowable, ob und wie es umgesetzt wird.

Dass es beim Modell nicht bleibt, sagt Flowable deutlich: „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“. Eine Häufigkeit nennt Flowable dazu nicht; wie viele Ihrer Service Tasks hinter einer Delegate-Klasse liegen, ergibt erst Ihre eigene Auszählung.

Wie lange Ihre Instanzen im Kompatibilitätsmodus bleiben

Standardmäßig unbegrenzt: „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.“ Den Namen „Flowable Control“ nennt Flowables eigene Open-Source-Seite nicht. Unter der Überschrift „Enterprise-ready“ beschreibt sie die kommerzielle Case Platform und führt dort als Leistung auf: „monitor every detail of the runtime engines, analyze and download reports through our Control dashboard“. Ob das dasselbe Werkzeug ist, sagt keine der beiden Seiten. Sicher ist nur, wo der Name steht: in der Migrationsdokumentation als Voraussetzung für den Schritt aus dem Kompatibilitätsmodus heraus, und auf der Open-Source-Seite gar nicht. Wie lange die Kompatibilitäts-Engine mitgeliefert wird, sagt Flowable nirgends.

Migriert die Historie mit? Hier widersprechen sich Flowables eigene Seiten

Die Dokumentation sagt es nicht zu. Der Satz zur Historie steht in der Einleitung des Kapitels „Legacy BPM migration steps“, nennt Camunda nicht und ist ausdrücklich eingeschränkt: „For some legacy products, the migration can automatically include existing historical data as well as in-flight, active process instances.“ Welche Produkte gemeint sind, steht nicht dabei.

Das Marketing geht weiter als die Dokumentation. Ein Blogbeitrag eines Mitgründers von Flowable, datiert auf den 7. September 2022, setzt die Zusage in Großbuchstaben: „YOU CAN MIGRATE YOUR CAMUNDA AND ACTIVITI DATA TO FLOWABLE IN-PLACE, INCLUDING ACTIVE PROCESS INSTANCES AND HISTORY“. Auf der Landingpage zu Flowable Leap steht sie ohne Einschränkung und ohne Nennung eines Quellsystems: „Migrate your BPMN instance to Flowable in-place, including all active processes and history.“

Beides sind Herstelleraussagen, aber sie haben nicht dasselbe Gewicht. Blog und Landingpage sind Marketingtexte; die Migrationsdokumentation ist das, woran sich ein Projekt orientiert. Legen Sie die Dokumentation zugrunde und nehmen Sie die Historie als offene Frage in die Prüfung auf. Genau diese hat am 10. Oktober 2025 jemand in Flowables Forum gestellt, weil er Camunda-Daten aus dem User Operation Log migrieren wollte. Der Beitrag steht am 2. September 2026 unbeantwortet da.

Was Flowable Leap kann und was nicht

Für die Prüfung der Modelle bietet Flowable ein eigenes Werkzeug an. Die Dokumentation beschreibt Flowable Leap zutreffend als Analysewerkzeug: „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“. Es findet Inkompatibilitäten. Es beseitigt keine.

Zwei Einschränkungen stehen in derselben Dokumentation. Erstens: „The online version of Flowable Leap cannot connect to your database to analyze BPMN models.“ Für einen realen Bestand brauchen Sie die Offline-Version. Zweitens deren Treiberumfang: „When using another database than H2, MySQL or PostgreSQL, the JDBC database driver needs to be added to the classpath of the application.“ Mitgeliefert sind H2, MySQL und PostgreSQL; Oracle, SQL Server und DB2 sind nicht dabei.

Beim Zugang widersprechen sich die beiden Seiten. Die Dokumentation schreibt weiterhin, die Online-Version nehme BPMN-XML-Dateien „without sign-in“ entgegen; die Landingpage verlangt das Ausfüllen eines Formulars: „Fill out the form to get access to both, Flowable LEAP Cloud and the Flowable LEAP App.“ Beide Sätze sind am 2. September 2026 live: der erste in der Migrationsdokumentation, der zweite auf flowable.com/leap-bpm-migration. Die Landingpage wirbt an dieser Stelle; als Planungsgrundlage ist der Satz aus der Dokumentation belastbarer.

Camunda 7 zu Flowable: der eine dokumentierte Fall in Flowables Forum

Der Fall steht in einem Thread mit drei Beiträgen vom 31. Januar 2025; am 2. September 2026 zählte das Forum dort 480 Aufrufe. Der Fragesteller beschreibt ihn so: „The application is running on Oracle with Camunda 7.19 Community Edition.“ (forum.flowable.org, Thread 12032) Die Antwort kam am selben Tag von einem Konto, das in der Forum-API als admin, moderator und staff geführt wird, und sie ist vorsichtig formuliert: „Migrating from Camunda 7 to Flowable should be possible. Perhaps something has changed when we did the analysis.“ Das sind Rollen im Forum; ob dahinter ein Angestellter von Flowable steht, sagt keine der von uns abgerufenen Seiten. Ein Forumsbeitrag bleibt sie ohnehin und keine Zusage.

Der funktionierende Weg bestand aus zwei Schritten, die in keiner Dokumentation stehen: „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.“ Die Ursache benennen Flowables Release Notes zu 7.1.0 vom 7. Oktober 2024: Liquibase wurde aus mehreren Engines entfernt und durch manuelle SQL-Dateien ersetzt. Der Fragesteller bestätigte: „Thank you, that did the trick and worked perfectly!“

Welche Version am Ende lief, sagt der Thread nicht: Der Rat lautete, über Flowable 7.0.1 nach 7.1.0 zu gehen, und die Bestätigung nennt keine Version. Belegt ist ein Weg auf die 7er-Linie, nicht auf die aktuelle Hauptversion. Flowable 8.0.0 erschien am 27. Februar 2026 und setzt laut Release Notes voraus: „Flowable 8 is now based on Spring Framework 7 and Spring Boot 4. There is no support for Spring Boot 3 anymore.“ Welche Spring-Version Ihr Bestand benutzt, steht in Ihrer eigenen Abhängigkeitsliste.

Was dieser Fall nicht belegt: eine Erfolgsquote, eine Regel oder eine Erwartung. Es ist ein Thread. Flowables eigene Forumssuche nach der exakten Phrase „Camunda 7“ liefert am 2. September 2026 zehn Themen, und die Suchschnittstelle begrenzt ihre Antwort ohnehin auf 50 Treffer. Das ist eine Aussage über diese Suche an diesem Tag, nicht über das Internet.

Was Sie in Flowable Open Source nicht bekommen

Die Kern-Engines stehen unter Apache 2.0: „They are Apache 2.0 licensed Open Source, with a committed community.“ Die Oberflächen gehören seit Flowable 7.0.0 vom 21. September 2023 nicht mehr dazu. Die Release Notes zu dieser Version schreiben: „This means that there are no UI applications, no content and form engines and the modules for Mule and some others are removed.“ Cockpit, Tasklist und Admin haben in Flowable Open Source also kein Gegenstück.

Für Flowables eigene Community Edition, die nicht mit der Camunda 7 Community Edition zu verwechseln ist, markiert die Preistabelle Hochverfügbarkeit und Skalierung als „Unsupported“. Lesen Sie „Unsupported“ genau: Es sagt, dass Flowable die Stufe kommerziell nicht unterstützt, nicht, dass die Apache-2.0-Engine beides technisch nicht könnte. Einen Preis veröffentlicht Flowable für keine kommerzielle Stufe: Die Preiszeile zeigt für die beiden kommerziellen Stufen „Users, RCPI and Agent Packages“ und „Users and RCPI Packages“, für die kostenlose „Free“; „RCPI“ wird auf keiner von uns gelesenen Seite aufgelöst. In der Zeile „Support Level“ trägt die Preistabelle für die kostenlose Stufe „Only community“ ein, und die drei Reaktionszeiten stehen in einer zweiten Tabelle unter der Überschrift „Flowable Support SLA“, deren Spalten „Silver“, „Gold“ und „Platinum“ heißen. Für „Severity One Incident“ stehen dort 6 Stunden, 4 Stunden und 1 Stunde. Das sind Reaktionszeiten, keine Lösungszeiten (flowable.com/pricing).

Wie gesund ist das Flowable-Projekt?

Belastbar gesund, und das gehört in jede faire Bewertung. Das Repository flowable/flowable-engine ist nicht archiviert („archived“: false), steht unter Apache 2.0 und wurde laut GitHub-API am 1. September 2026 zuletzt bewegt; dieselbe Abfrage meldete am 2. September 2026 9.507 Sterne, den Rohwert des Abruftages und keine Reichweitenaussage. Am Rande: Flowables eigene Open-Source-Seite spricht noch von „more than 5k stars on Github“.

Wichtiger als die Sterne ist ein Modul. Der dokumentierte Weg hängt an org.flowable:flowable5-compatibility, und dieses Modul wird weiter ausgeliefert: Auf Maven Central steht es bis einschließlich Version 8.0.0, zuletzt veröffentlicht am 27. Februar 2026, und im Verzeichnis modules des main-Branches liegt es ebenfalls. Die POM-Datei des Moduls trägt den Namen „Flowable 5 Compatibility“ und erwähnt Camunda mit keinem Wort.

Was das für Ihre Entscheidung heißt

Die dokumentierte Hälfte ist echt: Wenn Ihnen vor allem die laufenden Prozessinstanzen Sorge machen, hat Flowable dafür einen benannten Mechanismus, nennt Camunda 7 ausdrücklich und liefert das Modul in der aktuellen Hauptversion weiter aus. Was andere Zielsysteme veröffentlichen, haben wir hier nicht ausgezählt; dieser Artikel misst nur Flowables eigenes Material.

Die undokumentierte Hälfte ist Ihr Code und Ihre Modelle. Wie schwer sie wiegt, hängt an Ihrem Bestand, nicht an Flowable: Wenige Delegate-Klassen und wenig camunda:-Sonderlogik ergeben eine kurze Liste, ein über zehn Jahre gewachsener Bestand eine lange. Weder Flowable noch wir veröffentlichen dazu eine Aufwands- oder Dauerangabe, und bei Flowable ist dieses Fehlen belegbar: weder in der Dokumentation noch auf der Landingpage zu Leap noch im Blog noch auf der Preisseite steht eine.

Und weil in dieser Diskussion schnell Dringlichkeit mitschwingt, sei Camundas eigener Satz von der Migrationsseite zitiert: „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, geprüft am 2. September 2026.) Wer eine Enterprise-Subscription auf 7.24 LTS hat, entscheidet über Flowable ohne Termindruck. Wer die Community Edition von Camunda 7 betreibt, muss ohnehin entscheiden: Die Camunda 7 Community Edition erreichte im Oktober 2025 das End of Life (Camunda-Forum, Beitrag vom 28. Februar 2025). Auch dann ist Flowable eine von mehreren Möglichkeiten. Die Prüfung, die wir für belastbar halten, hat drei Schritte, und alle drei können Sie selbst gehen:

1. Zählen Sie aus. Wie viele Delegate-Klassen und wie viele camunda:-Attribute stehen in Ihrem Bestand?
2. Lassen Sie Ihre Modelle durch Flowable Leap laufen. Läuft Ihr Bestand auf einer Oracle- oder SQL-Server-Datenbank, heißt das: Offline-Version plus eigener JDBC-Treiber.
3. Fragen Sie Flowable schriftlich. Und zwar nach genau den Attributen, die Ihre Auszählung ergeben hat. Was Flowable darauf antwortet, ist die Information, die es öffentlich nicht gibt.

Wenn Sie die Bauform von Camunda 7 behalten wollen, sind die Forks der näherliegende Vergleich: Camunda-7-Forks im Vergleich stellt CIB seven und Operaton nebeneinander. Und wenn Sie zuerst wissen wollen, was der Weg des Herstellers technisch bedeutet: Camunda 7 vs. Camunda 8 geht die dokumentierten Unterschiede durch.