Camunda 7 am Ende? Operaton, CIB seven und Fluxnova im Vergleich

Camunda 7 im Einsatz und die Frage, wie es weitergeht? Für die Anwendungen um die Engine, also Java-Stand, Datenbank, Container und Betrieb, bietet WZ-IT die Modernisierung von Legacy-Software und den Betrieb auf Kubernetes. Kostenloses Erstgespräch vereinbaren

Wer Fachverfahren oder Prozessautomatisierung auf Camunda 7 betreibt, hört seit Monaten widersprüchliche Aussagen: Camunda 7 sei am Ende, laufe aber bis 2030, die Community Edition sei tot, aber Forks gebe es genug. Beides stimmt, je nach Edition. Die Community Edition hat seit dem 14. Oktober 2025 keinen Release mehr, die Enterprise Edition wird laut Camunda bis April 2030 gepflegt. Dazwischen liegen vier Wege: Enterprise verlängern, zu Camunda 8 wechseln, auf einen Fork der Community Edition umsteigen oder auf eine andere Engine wie Flowable gehen.

Dieser Beitrag legt die Optionen nebeneinander, mit Datum, Lizenz, Träger und dem dokumentierten Migrationsweg. Alle Angaben Stand 15. Oktober 2026 und mit Quelle am Satz. Wo es Herstellerbehauptung ist und nicht geprüft, steht es dabei.

Inhaltsverzeichnis

• Kurz beantwortet: was endet wann
• Zeitleiste: Community, Enterprise und LTS
• Die Optionen im Vergleich
• Die drei Forks im Detail
• Camunda 8 und Flowable: was sich ändert
• Entscheidungshilfe nach Ausgangslage
• Migration zu einem Fork: die dokumentierten Schritte
• Bestandsaufnahme der Prozesslandschaft
• Verbreitete Irrtümer
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Kurz beantwortet: was endet wann

• Community Edition: Endgültig beendet. Der letzte Release ist 7.24 vom 14. Oktober 2025, das GitHub-Repository ist archiviert. Es gibt danach keine Releases mehr, auch keine Sicherheitspatches (Camunda-Blog).
• Enterprise Edition: Camunda hat das EoL von April 2027 auf April 2030 verlängert, mit zwei Environment-Update-Releases pro Jahr (April und Oktober). Erweiterter Support gegen Aufpreis ist bis April 2032 vorgesehen.
• Die Software läuft weiter. EoL heißt: keine Korrekturen mehr, nicht: Abschaltung. Der Handlungsdruck ergibt sich aus Sicherheit, Java- und Spring-Boot-Stand und Auditvorgaben, nicht aus einem Stichtag.

Zeitleiste: Community, Enterprise und LTS

Auch Enterprise-Kunden betrifft das: Mit dem Oktober-Release 2026 endet der Support für Spring Boot 3.5 und Java 11 in Camunda 7.24. Wer Camunda 7 Enterprise bis 2030 nutzt, muss Spring Boot 4 trotzdem nachziehen.

Die Optionen im Vergleich

Quellen: Camunda 7 Enterprise, Camunda-8-Lizenzen, Operaton, CIB seven Preise, Fluxnova FAQ, Flowable. Die Lizenzen der drei Forks sind direkt in den Repositories geprüft: Operaton, CIB seven, Fluxnova.

Die drei Forks im Detail

Operaton

Operaton entstand im Oktober 2024 als Fork der Camunda-7-Community-Edition und wird von einer Community ohne einzelne Firma gepflegt. Die Lizenz ist Apache 2.0, kostenpflichtigen Support bieten unabhängige Dienstleister, darunter mehrere aus Deutschland. Das Versionsschema laut Roadmap:

• 1.x ist die Linie mit Funktionsparität zu Camunda 7.24 (Spring Boot 3.5.x). Der Support für 1.1 ist laut Roadmap im August 2026 ausgelaufen.
• 2.x bringt Spring Boot 4 und Jakarta EE 11 (Release 2.0, März 2026) als Basis. Anwendungen auf Spring Boot 3 müssen für 2.x entsprechend angepasst werden.
• 2.1.5 ist der aktuelle Stand (Release vom 18.09.2026). 2.2.0-RC1 ist ein Release Candidate und nicht für die Produktion gedacht. Die Roadmap plant 2.2 für Oktober 2026.
• Java 17, 21 und 25 werden getestet. Ein eigener Modeler ist in Entwicklung, bis dahin gilt der Camunda Modeler laut FAQ als kompatibel (Herstellerangabe).

Wichtig für Fachverfahren: Operaton unterstützt jede Minor-Version nur sechs Monate. Wer selten aktualisiert, muss den Rhythmus in die Betriebsplanung aufnehmen.

CIB seven

CIB seven ist seit November 2024 ein Fork der Community Edition, gepflegt von der CIB software GmbH. Der Quellcode steht unter Apache 2.0. Daneben gibt es vier Editionen: Community, Community+ (Sicherheitspatches), LTS (Hotfixes, Langzeitsupport) und Enterprise (alle Camunda-7-Enterprise-Funktionen laut Hersteller), wie die Preisseite zeigt. Beträge nennt die Seite nicht.

• Aktuell: Die Community-Version 2.2.0 erschien am 01.06.2026 mit Spring-Boot-4-Distribution, Tomcat 11 und WildFly 40. Die Dokumentation führt Patch-Releases bis 2.2.3.
• Java: 17 und 21.
• Roadmap: CIB seven 3.0 ist für November 2026 geplant, mit Java 25, Spring Boot 4.1 und dem Entfernen der alten Webanwendungen (Roadmap). Wer Cockpit-Erweiterungen gebaut hat, plant das ein.
• Herstellerangaben: "alle Camunda-7-Enterprise-Funktionen" und "Migrationszeit unter 30 Minuten" sind Aussagen auf der Projektseite, von uns nicht nachgeprüft.

Fluxnova

Fluxnova ist ein Open-Source-BPM-Projekt unter dem Dach der FINOS (Linux Foundation), Lizenz Apache 2.0. Laut FAQ bauen die Entwickler auf der Camunda-7-Engine auf, Beiträge kommen unter anderem von Fidelity, NatWest Group, Capital One, Deutsche Bank und BMO. Die Governance ist öffentlich mit Maintainer-Rollen und CLA.

• Aktuell: 3.1.0 vom 14.10.2026 und 3.0.0 vom 17.07.2026. Version 3.0 hebt Spring Boot von 3.5.5 auf 4.0.5, Spring Framework auf 7.0.7 und Jakarta EE auf 11.
• Eigene Wege: Das Control Center ersetzt das alte Cockpit, dazu kommen eingeschränkte Variablen für personenbezogene Daten und Ad-hoc-Subprozesse. Fluxnova entfernt sich damit schrittweise von Camunda 7.
• Migrator: Das Migrationswerkzeug benennt Pakete um, passt Imports an, konvertiert BPMN- und DMN-Modelle und ersetzt Abhängigkeiten. Laufende Instanzen bleiben laut Hersteller erhalten (Herstellerangabe).
• Offen: Eine feste Supportdauer je Version nennt die Projektseite nicht.

Camunda 8 und Flowable: was sich ändert

Camunda 8 ist laut Migrationsleitfaden "not a drop-in replacement": Es genügt nicht, eine Bibliothek zu tauschen. Die konzeptionellen Unterschiede:

• Die Engine Zeebe ist immer ein Remote-Dienst, der eingebettete Betrieb entfällt. Gemeinsame ACID-Transaktionen zwischen Anwendungscode und Engine gibt es nicht mehr.
• Prozessvariablen sind nur noch einfache Typen oder JSON, keine serialisierten Java-Objekte. Camunda Spin entfällt.
• Ausdrücke laufen in FEEL statt JUEL und greifen nicht mehr auf Beans zu.
• Mandantenfähigkeit funktioniert über eine Tenant-ID, eine Engine je Mandant ist nicht möglich.

Camunda stellt Migrationswerkzeuge bereit (Data Migrator, Code-Konvertierung, Diagram Converter). Für selbst betriebene Produktivsysteme verlangt Camunda die Self-Managed Enterprise Edition; ohne Lizenz ist die Nutzung auf Entwicklung und Test beschränkt.

Flowable ist kein Camunda-Fork, sondern eine eigenständige Engine für BPMN, CMMN und DMN unter Apache 2.0. Flowable 8.0.0 vom 27.02.2026 setzt Spring Framework 7 und Spring Boot 4 voraus und entfernt JUnit-3/4-Unterstützung. Der Umstieg von Camunda 7 ist ein Umbau der Prozessanwendungen. Ein dokumentierter Direktweg ist uns nicht bekannt. Flowable lohnt sich vor allem, wenn ohnehin neu gebaut wird oder Case-Management (CMMN) gebraucht wird.

Entscheidungshilfe nach Ausgangslage

Das ist eine Orientierung, keine Empfehlung für einen konkreten Fall. Entscheidend sind Versionsstand, Zahl der Prozessanwendungen und Supportanforderungen.

Migration zu einem Fork: die dokumentierten Schritte

Die Schritte decken sich bei Operaton und CIB seven. Beide Dokumentationen nennen dieselbe Reihenfolge:

1. Auf Camunda 7.24 aktualisieren. Operaton verlangt das ausdrücklich (Migrationsleitfaden), CIB seven für die Version 2.1 ebenfalls (Camunda Migration).
2. Datenbank sichern. Operaton nennt das Backup als Pflichtschritt vor dem Wechsel.
3. Code per OpenRewrite umstellen. Operaton: Rezept org.operaton.rewrite.MigrateFromCamunda, für Spring Boot MigrateSpringBootApplication. CIB seven: org.cibseven.ReplaceCamundaWithCIBSeven. Beide ersetzen Abhängigkeiten und benennen org.camunda-Pakete um.
4. Gegen dieselbe Datenbank starten. Operaton: Das Schema entspricht dem von Camunda 7.24, Tabellen behalten das Präfix ACT_, es sind keine Schema-Skripte nötig. Bereits deployte Modelle laufen weiter, die Engine akzeptiert operaton:- und camunda:-Namensräume.
5. Testen und Diff prüfen. Die Rezepte ändern Dateien direkt. Bekanntes Problem bei Operaton: umbenannte ServiceLoader-Dateien müssen inhaltlich kontrolliert werden.

Fluxnova beschreibt einen ähnlichen Ablauf: Vorbereiten (Backup), Transformieren (Migrator), Validieren, Umschalten. Der Migrator unterstützt als Quelle die Camunda 7 Community Edition.

Nicht dokumentiert und deshalb im Einzelfall zu prüfen: proprietäre Enterprise-Funktionen, die ein Fork nachbaut (Batch-Operationen, Prozessinstanz-Migration), und eigene Plugins gegen interne Engine-Klassen.

Bestandsaufnahme der Prozesslandschaft

Vor jeder Entscheidung hilft eine Inventur. Diese Punkte entscheiden über Aufwand und Risiko:

• Engines und Versionen: Wo läuft welche Camunda-Version, eingebettet in Spring Boot, als Shared Engine auf Tomcat oder als Standalone? Liegt eine Engine noch unter 7.24?
• Java und Framework: Java-Version, Spring-Boot-Version, Application Server. Forks setzen Java 17 oder neuer voraus.
• Datenbank: Hersteller und Version (PostgreSQL, Oracle, SQL Server). Die unterstützten Versionen unterscheiden sich je Engine und müssen vor dem Wechsel abgeglichen werden.
• External Tasks und Worker: Welche Clients sprechen die REST-API an? Die REST-API gilt bei Operaton als kompatibel, bei Zielwechsel zu Camunda 8 nicht.
• Eigene Plugins und Delegates: Process-Engine-Plugins, Listener, Cockpit-Erweiterungen, Spin- und Connect-Nutzung. Sie führen bei Camunda 8 und bei Fluxnova 3.x am ehesten zu Mehraufwand.
• Laufende Instanzen und Historie: Anzahl, Laufzeit, Aufbewahrungsfristen. Bei Operaton ist das Datenbankschema laut Migrationsanleitung identisch mit 7.24, Schemaskripte entfallen.
• Betrieb: Backup, Monitoring, Clusterbetrieb, Authentifizierung (LDAP, OIDC), Deployment-Pipeline.
• Support- und Vergabevorgaben: Braucht die Fachanwendung einen Herstellersupport, einen Dienstleistervertrag oder reicht der Community-Betrieb?

Verbreitete Irrtümer

• "Camunda 7 EoL heißt, die Engine schaltet sich ab." Nein, es endet nur die Wartung. Die Software läuft weiter, Schwachstellen bleiben aber ungepatcht, sofern kein Enterprise- oder Fork-Support besteht.
• "Das Ende betrifft alle Camunda-7-Nutzer 2025." Nur die Community Edition. Enterprise läuft laut Camunda bis April 2030.
• "Camunda 8 ist das Update von Camunda 7." Camunda nennt es selbst keinen Drop-in-Ersatz. Es ist eine neue Architektur.
• "Camunda 8 ist wie Camunda 7 frei nutzbar." Self-managed in Produktion braucht eine Enterprise-Lizenz.
• "Ein Fork heißt nur Dependencies tauschen." Pakete, Namensräume und Konfiguration ändern sich. Danach muss getestet werden. Spring Boot 4 und Jakarta EE 11 kommen bei den 2.x-Linien der Forks dazu.
• "Fluxnova ist nur für Banken." Beiträge kommen aus dem Finanzsektor, die Lizenz ist Apache 2.0 und die Teilnahme laut Projektseite offen.

Stand und Methodik

Alle Angaben Stand 15. Oktober 2026. Versionen und Releasedaten stammen aus den GitHub-Releases und Projektseiten, Lizenzen aus den Repositories, Supportzeiträume aus den Seiten der Hersteller. Als Herstellerangabe gekennzeichnet ist, was wir nicht selbst geprüft haben: Funktionsparität zu Camunda 7 Enterprise bei CIB seven, Migrationsdauer, erhaltene laufende Instanzen bei Fluxnova. Preise von CIB seven, Camunda 7 Enterprise und Camunda 8 nennen die Hersteller nicht öffentlich, daher enthält der Beitrag keine. Wir haben keine der Engines in einem Praxistest verglichen.

Unser Vorgehen bei WZ-IT

WZ-IT bietet keinen Support für eine bestimmte BPMN-Engine als Produkt an. Wir arbeiten an der Anwendung und dem Betrieb drumherum:

• Bestandsaufnahme: Wir erfassen Engines, Java- und Spring-Stände, Datenbanken und Abhängigkeiten, bewerten Risiken und priorisieren, im Rahmen der Modernisierung von Legacy-Software mit Code- und Infrastruktur-Audit.
• Modernisierung der Prozessanwendung: Java 17 oder neuer, Spring Boot, Containerisierung, CI/CD-Pipeline, Datenbank-Migration (zum Beispiel von Oracle auf PostgreSQL), siehe Modernisierung von Anwendungen auf Kubernetes.
• Betrieb: Betrieb von Java-Anwendungen mit ihrer Datenbank auf Kubernetes und in Managed Operations mit Monitoring, Sicherung und Updates.
• Umstieg ohne Big Bang: Parallelbetrieb und schrittweise Umstellung statt Stichtagswechsel, mit Rückfallweg.

Die Wahl der Engine und der Herstellersupport bleiben bei Ihnen. Wir planen mit, welche Variante zu Ihrem Bestand passt.

Weiterführende Guides

• Open-Source-Lizenzwechsel: die Chronik und was Betreiber tun müssen
• k3s, k0s, RKE2 oder Talos: Kubernetes-Distributionen im Vergleich 2026
• Confluence Data Center End of Life 2029: Migration zu Open-Source-Wikis
• Geschäftsprozesse automatisieren mit self-hosted n8n
• Legacy-Software modernisieren
• Kubernetes-Betrieb durch WZ-IT

Camunda 7 im Bestand: Was bleibt, was geht, was kostet der Umstieg? Wir erfassen Ihre Prozessanwendungen, klären Java-, Spring- und Datenbankstand und planen die Modernisierung und den Betrieb, bevor Sie sich auf eine Engine festlegen. Termin vereinbaren

Quellen

• Camunda-Forum: Camunda 7 Community Edition End of Life
• Camunda-Blog: Camunda 7 Enterprise End of Life Extension
• Camunda-Docs: Support Announcements
• GitHub: camunda-bpm-platform (archiviert)
• Camunda 8: Lizenzen
• Camunda 8: Migration von Camunda 7
• Camunda 8: Konzeptionelle Unterschiede
• GitHub: camunda-7-to-8-migration-tooling
• Operaton: FAQ
• Operaton: Roadmap und Kompatibilitätsmatrix
• Operaton: Release 2.1.5 und 2.2.0-RC1
• Operaton: Service Provider
• Operaton-Docs: Camunda to Operaton Migration
• GitHub: operaton/operaton
• GitHub: operaton/operaton-helm
• CIB seven: Projektseite
• CIB seven: Editionen
• CIB seven: Roadmap
• CIB seven Docs: Supported Environments
• CIB seven Docs: Camunda Migration
• GitHub: cibseven/cibseven
• Fluxnova: Projektseite
• Fluxnova: FAQ
• Fluxnova: Governance
• Fluxnova: Migration
• GitHub: Fluxnova 3.0.0 Release Notes
• Flowable: Open Source
• GitHub: Flowable 8.0.0