Camunda 7 end of life: Operaton, CIB seven and Fluxnova compared

Running Camunda 7 and unsure what comes next? For the applications around the engine, meaning Java version, database, containers and operations, WZ-IT offers legacy software modernisation and operations on Kubernetes. Book a free initial consultation

Anyone running specialist applications or process automation on Camunda 7 has heard contradictory statements for months: Camunda 7 is finished, yet it runs until 2030; the Community Edition is dead, yet there are plenty of forks. Both are true, depending on the edition. The Community Edition has had no release since 14 October 2025, while Camunda maintains the Enterprise Edition until April 2030. In between there are four routes: extend Enterprise, move to Camunda 8, switch to a fork of the Community Edition, or move to another engine such as Flowable.

This article puts the options side by side, with date, licence, steward and the documented migration path. All data as of 15 October 2026, with the source on the sentence. Where something is a vendor claim we have not verified, it says so.

Table of contents

• In short: what ends when
• Timeline: Community, Enterprise and LTS
• The options compared
• The three forks in detail
• Camunda 8 and Flowable: what changes
• Decision guide by starting point
• Migrating to a fork: the documented steps
• Inventory of the process landscape
• Common misconceptions
• Status and methodology
• Our approach at WZ-IT
• Further guides

In short: what ends when

• Community Edition: Ended. The last release is 7.24 of 14 October 2025 and the GitHub repository is archived. There are no further releases afterwards, including no security patches (Camunda blog).
• Enterprise Edition: Camunda extended end of life from April 2027 to April 2030, with two environment update releases a year (April and October). Extended support for an additional fee runs to April 2032.
• The software keeps running. End of life means no more fixes, not a shutdown. The pressure comes from security, Java and Spring Boot versions and audit requirements, not from a cut-off date.

Timeline: Community, Enterprise and LTS

This affects Enterprise customers too: with the October 2026 release, support for Spring Boot 3.5 and Java 11 ends in Camunda 7.24. Anyone on Camunda 7 Enterprise until 2030 still has to move to Spring Boot 4.

The options compared

Sources: Camunda 7 Enterprise, Camunda 8 licences, Operaton, CIB seven pricing, Fluxnova FAQ, Flowable. The licences of the three forks were checked directly in the repositories: Operaton, CIB seven, Fluxnova.

The three forks in detail

Operaton

Operaton began in October 2024 as a fork of the Camunda 7 Community Edition and is maintained by a community without a single company. The licence is Apache 2.0; paid support comes from independent service providers, several of them in Germany. The version scheme according to the roadmap:

• 1.x is the line with feature parity to Camunda 7.24 (Spring Boot 3.5.x). Support for 1.1 ended in August 2026 according to the roadmap.
• 2.x brings Spring Boot 4 and Jakarta EE 11 (release 2.0, March 2026) as its baseline. Applications on Spring Boot 3 have to be adapted for 2.x.
• 2.1.5 is the current version (release of 18 Sep 2026). 2.2.0-RC1 is a release candidate and not meant for production. The roadmap plans 2.2 for October 2026.
• Java 17, 21 and 25 are tested. A dedicated modeler is in development; until then the Camunda Modeler is described as compatible in the FAQ (vendor statement).

Important for specialist applications: Operaton supports each minor version for only six months. Anyone who rarely updates has to build that rhythm into operations planning.

CIB seven

CIB seven has been a fork of the Community Edition since November 2024, maintained by CIB software GmbH. The source code is under Apache 2.0. There are also four editions: Community, Community+ (security patches), LTS (hotfixes, long-term support) and Enterprise (all Camunda 7 Enterprise features according to the vendor), as the pricing page shows. The page lists no amounts.

• Current: The Community version 2.2.0 was released on 1 Jun 2026 with a Spring Boot 4 distribution, Tomcat 11 and WildFly 40. The documentation lists patch releases up to 2.2.3.
• Java: 17 and 21.
• Roadmap: CIB seven 3.0 is planned for November 2026, with Java 25, Spring Boot 4.1 and removal of the legacy web applications (roadmap). Anyone who built Cockpit extensions should plan for that.
• Vendor statements: "all Camunda 7 Enterprise features" and "migration time under 30 minutes" are claims on the project site that we have not verified.

Fluxnova

Fluxnova is an open-source BPM project under FINOS (Linux Foundation), licensed under Apache 2.0. According to the FAQ it builds on the Camunda 7 engine, with contributions from Fidelity, NatWest Group, Capital One, Deutsche Bank and BMO, among others. Governance is public, with maintainer roles and a CLA.

• Current: 3.1.0 of 14 Oct 2026 and 3.0.0 of 17 Jul 2026. Version 3.0 raises Spring Boot from 3.5.5 to 4.0.5, Spring Framework to 7.0.7 and Jakarta EE to 11.
• Own path: The Control Center replaces the legacy Cockpit, alongside restricted variables for personal data and ad hoc subprocesses. Fluxnova is gradually moving away from Camunda 7.
• Migrator: The migration tool renames packages, updates imports, converts BPMN and DMN models and replaces dependencies. Running instances are preserved according to the vendor (vendor statement).
• Open: The project site names no fixed support period per version.

Camunda 8 and Flowable: what changes

Camunda 8 is, per its migration guide, "not a drop-in replacement": swapping a library is not enough. The conceptual differences:

• The engine Zeebe is always a remote service; embedded operation is gone. Shared ACID transactions between application code and engine no longer exist.
• Process variables are only primitive types or JSON, not serialised Java objects. Camunda Spin is not available.
• Expressions use FEEL instead of JUEL and no longer access beans.
• Multi-tenancy works through a tenant identifier; one engine per tenant is not possible.

Camunda provides migration tooling (data migrator, code conversion, diagram converter). For self-managed production systems, Camunda requires the Self-Managed Enterprise Edition; without a licence, use is limited to development and testing.

Flowable is not a Camunda fork but an independent engine for BPMN, CMMN and DMN under Apache 2.0. Flowable 8.0.0 of 27 Feb 2026 requires Spring Framework 7 and Spring Boot 4 and removes JUnit 3/4 support. Moving from Camunda 7 means rebuilding the process applications. We know of no documented direct path. Flowable is mainly worth considering when a rebuild is planned anyway or case management (CMMN) is needed.

Decision guide by starting point

This is orientation, not a recommendation for a specific case. Version level, number of process applications and support requirements decide.

Migrating to a fork: the documented steps

The steps coincide for Operaton and CIB seven. Both documentations give the same order:

1. Update to Camunda 7.24. Operaton requires this explicitly (migration guide); CIB seven does the same for version 2.1 (Camunda migration).
2. Back up the database. Operaton lists the backup as a mandatory step before the switch.
3. Convert the code with OpenRewrite. Operaton: recipe org.operaton.rewrite.MigrateFromCamunda, for Spring Boot MigrateSpringBootApplication. CIB seven: org.cibseven.ReplaceCamundaWithCIBSeven. Both replace dependencies and rename org.camunda packages.
4. Start against the same database. Operaton: the schema matches that of Camunda 7.24, tables keep the ACT_ prefix, no schema scripts are needed. Already deployed models keep working; the engine accepts both operaton: and camunda: namespaces.
5. Test and review the diff. The recipes change files in place. Known issue at Operaton: renamed ServiceLoader files need their contents checked.

Fluxnova describes a similar flow: prepare (backup), transform (migrator), validate, switch. The migrator supports Camunda 7 Community Edition as the source.

Not documented and therefore to be checked case by case: proprietary Enterprise features that a fork re-implements (batch operations, process instance migration), and custom plugins against internal engine classes.

Inventory of the process landscape

An inventory helps before any decision. These points decide effort and risk:

• Engines and versions: Where does which Camunda version run, embedded in Spring Boot, as a shared engine on Tomcat or as standalone? Is any engine below 7.24?
• Java and framework: Java version, Spring Boot version, application server. Forks require Java 17 or later.
• Database: Vendor and version (PostgreSQL, Oracle, SQL Server). Supported versions differ per engine and must be reconciled before the switch.
• External tasks and workers: Which clients call the REST API? Operaton regards the REST API as compatible; moving to Camunda 8 it is not.
• Custom plugins and delegates: Process engine plugins, listeners, Cockpit extensions, use of Spin and Connect. They are the most likely source of extra effort with Camunda 8 and Fluxnova 3.x.
• Running instances and history: Number, runtime, retention periods. For Operaton the database schema is identical to 7.24 according to the migration guide, so no schema scripts are needed.
• Operations: Backup, monitoring, clustering, authentication (LDAP, OIDC), deployment pipeline.
• Support and procurement requirements: Does the specialist application need vendor support, a service provider contract, or is community operation enough?

Common misconceptions

• "Camunda 7 end of life means the engine shuts down." No, only maintenance ends. The software keeps running, but vulnerabilities stay unpatched unless there is Enterprise or fork support.
• "The end affects all Camunda 7 users in 2025." Only the Community Edition. Enterprise runs until April 2030 according to Camunda.
• "Camunda 8 is the update to Camunda 7." Camunda itself calls it not a drop-in replacement. It is a new architecture.
• "Camunda 8 is free to use like Camunda 7." Self-managed in production needs an Enterprise licence.
• "A fork just means swapping dependencies." Packages, namespaces and configuration change. Testing follows. Spring Boot 4 and Jakarta EE 11 come on top for the 2.x lines of the forks.
• "Fluxnova is only for banks." Contributions come from the financial sector, but the licence is Apache 2.0 and participation is open according to the project site.

Status and methodology

All data as of 15 October 2026. Versions and release dates come from the GitHub releases and project sites, licences from the repositories, support periods from the vendors' pages. What we did not verify ourselves is marked as a vendor statement: feature parity with Camunda 7 Enterprise at CIB seven, migration duration, preserved running instances at Fluxnova. The vendors do not publish prices for CIB seven, Camunda 7 Enterprise and Camunda 8, so the article contains none. We did not compare the engines in a practical test.

Our approach at WZ-IT

WZ-IT does not offer support for a specific BPMN engine as a product. We work on the application and the operations around it:

• Inventory: We record engines, Java and Spring versions, databases and dependencies, assess risks and prioritise, as part of legacy software modernisation with a code and infrastructure audit.
• Modernising the process application: Java 17 or later, Spring Boot, containerisation, CI/CD pipeline, database migration (for example Oracle to PostgreSQL), see application modernisation on Kubernetes.
• Operations: Running Java applications with their database on Kubernetes and in Managed Operations with monitoring, backups and updates.
• Migration without a big bang: Parallel running and step-by-step cut-over instead of a switch on a fixed date, with a fallback path.

The choice of engine and vendor support stay with you. We help plan which variant fits your estate.

Further guides

• Open-source licence changes: the chronicle and what operators must do
• k3s, k0s, RKE2 or Talos: Kubernetes distributions compared 2026
• Confluence Data Center End of Life 2029: Migrating to open-source wikis
• Business process automation with self-hosted n8n
• Modernising legacy software
• Kubernetes operations by WZ-IT

Camunda 7 in your estate: what stays, what goes, what does the move cost? We record your process applications, clarify Java, Spring and database versions, and plan modernisation and operations before you commit to an engine. Book a call

Sources

• 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 (archived)
• Camunda 8: Licenses
• Camunda 8: Migrating from Camunda 7
• Camunda 8: Conceptual differences
• GitHub: camunda-7-to-8-migration-tooling
• Operaton: FAQ
• Operaton: Roadmap and compatibility matrix
• Operaton: Release 2.1.5 and 2.2.0-RC1
• Operaton: Service providers
• Operaton docs: Camunda to Operaton migration
• GitHub: operaton/operaton
• GitHub: operaton/operaton-helm
• CIB seven: project site
• CIB seven: editions
• CIB seven: roadmap
• CIB seven docs: Supported environments
• CIB seven docs: Camunda migration
• GitHub: cibseven/cibseven
• Fluxnova: project site
• Fluxnova: FAQ
• Fluxnova: governance
• Fluxnova: migration
• GitHub: Fluxnova 3.0.0 release notes
• Flowable: open source
• GitHub: Flowable 8.0.0