Camunda 7 CE End of Life: Your Options (and Why Almost All of Them Are the Same Engine)

Camunda 7 Community Edition is gone. A look at 20 years of jBPM, Activiti, Camunda and Flowable forks, what the old architecture got right and wrong, and where to go next.

On October 14, 2025 Camunda shipped 7.24, the last Community Edition release of Camunda 7. The repository is archived, and CE gets no more patches, not even security fixes. Enterprise customers keep receiving patches until April 2030, and a paid extended-support option runs to April 2032 (Camunda announcement).

If you are on Camunda 7 CE, a year has passed since that release and you are running an unpatched engine. The usual "Camunda 7 alternatives" post lists Operaton, CIB seven, Flowable, Camunda 8 and maybe jBPM, and treats them as five separate products.

They aren't. Most of that list is one engine that has been forked over and over for twenty years. Before you pick a lineage for the next ten years, it helps to know that history.

Disclosure: I build QuantumBPM, a BPMN + DMN engine that is not part of that family tree. I will cover the options fairly, including where ours falls short, and you can decide for yourself.

---

The family tree

2003  jBPM (Tom Baeyens)
2004   └─ joins JBoss (later Red Hat)
       │
2009   ├─ Drools Flow (Kris Verlaenen, written from scratch on the rules engine)
2010   │    └─ rebranded as jBPM 5 ── jBPM 6/7 ── Kogito ── Apache KIE / IBM BAMOE
       │
2010   └─ Baeyens + Joram Barrez leave for Alfresco
            └─ Activiti 5.0  (new codebase, jBPM 1-4 experience, version number continues)
                 │
2013             ├─ FORK: camunda BPM  ─── Camunda 7 ─── CE EOL Oct 2025
                 │                            │
2024-25          │                            ├─ FORK: Operaton   (community)
                 │                            ├─ FORK: CIB seven  (CIB software)
                 │                            └─ FORK: EximeeBPMS (Consdata)
                 │
2016             ├─ FORK: Flowable  (Barrez, Tijs Rademakers + team)
                 │
                 └─ Activiti 6/7/8+ (Alfresco, now Hyland)

2017+ Zeebe ── Camunda 8   (new engine, clean break, not a fork)

A few key moments in BPM space:

2003-2010: jBPM. Tom Baeyens starts jBPM, and it joins JBoss with version 2.0 in 2004. Through jBPM 4 it is the default open-source Java workflow engine: a library you embed in your app, with process state kept in relational tables.

2010: Activiti. Baeyens and Joram Barrez leave Red Hat and start Activiti at Alfresco. It is a new codebase, but its first version is 5.0, a deliberate signal that it continues jBPM 1-4 (Wikipedia). Red Hat, meanwhile, turns Drools Flow into jBPM 5, so the jBPM name continues on a completely different engine.

2013: Camunda forks Activiti. Camunda had been an Activiti consulting partner and a major contributor. By 2013 Baeyens was on his way out of Alfresco, and Camunda worried that Activiti would bend toward Alfresco document-centric workflow, so it forked (Column 2). Open a Camunda 7 database today and the tables are still named ACT_RU_EXECUTION, ACT_HI_PROCINST, ACT_RE_PROCDEF. That ACT_ stands for Activiti.

2016: Flowable forks Activiti. Barrez and Tijs Rademakers, described at the time as "the heart and soul" of Activiti, leave Alfresco and fork it as Flowable (Column 2). Activiti itself continues under Alfresco and later Hyland, and still ships releases, but most of the original core team left with the forks.

2017-2022: Camunda leaves its own lineage. Instead of evolving the Activiti-derived engine, Camunda builds Zeebe, a new event-streamed broker, and launches it as Camunda 8 in 2022. In October 2024, Camunda 8.6 starts requiring a paid license for self-managed production use (Camunda). In 2025, Camunda 7 CE reaches end of life.

2024-2025: Camunda 7 is forked again. Operaton (community-run, modernizing the codebase), CIB seven (CIB software, 1.0 in November 2024) and EximeeBPMS (Consdata) all pick up the CE code.

The result: if you choose Operaton, CIB seven, EximeeBPMS, Flowable or Activiti in 2026, you are choosing a descendant of a 2010 codebase built on ideas from 2003. That isn't automatically bad. It is simply a fact you should be aware of.

---

Why the same design keeps getting forked

Every fork kept the architecture because the architecture is what users are locked into:

• An embedded Java library. The engine runs inside your JVM, often inside your Spring Boot app, and shares your transaction.
• Relational tables as the source of truth. Runtime state, history, jobs and variables all live in ACT_* tables in your database.
• A polling job executor. Timers, async continuations and retries are rows that executor threads poll and lock.
• Java delegates. Service tasks are camunda:class="com.acme.ChargeCardDelegate" or ${chargeCard.execute(execution)}, so your business code runs on the engine classpath and threads.
• JUEL expressions. Conditions, assignments and listeners use Java EL, the expression language from JSP.

Replacing any of these would break every existing deployment, so each fork keeps all of them. Forks differ in maintainers, packaging, Spring Boot versions and license stewardship, not in design.

What that design got right

This lineage is the most successful open-source BPM architecture ever built, and for good reasons:

• Simple to operate. One JVM and one relational database. No brokers, no search cluster.
• Transactional with your app. Process state and business data commit in the same transaction, a real advantage that later distributed engines had to give up.
• The most complete BPMN coverage in open source. Camunda 7 still supports constructs (transaction sub-processes, for example) that Camunda 8 never shipped.
• An enormous ecosystem. Ten-plus years of Stack Overflow answers, forum threads, consultants, plugins and people who know it well. This is a genuine asset.
• Embeddable. For a Java shop, adding a workflow engine is just adding a dependency.

Where it shows its age

• JVM-only in practice. External tasks exist, but the natural model is Java delegates on the engine classpath. Polyglot teams end up second-class.
• The database is the ceiling. Job acquisition, history writes and runtime state all hit one RDBMS. Scaling means tuning the job executor, partitioning history and cleaning ACT_HI_* tables that grow without bound.
• Tight coupling. Business code shares threads, transactions and classloaders with the engine. A slow delegate holds engine resources, and an engine upgrade forces a dependency upgrade in your app.
• JUEL, not FEEL. Camunda 7 DMN support was bolted on. It scores 80.85% on the DMN TCK and passes 0 of 18 lambda tests and 0 of 5 function-definition tests (DMN TCK). Flowable has no FEEL at all: its DMN is decision tables with JUEL.
• Versioning and migration are left to you. Engines support instance migration, but the tooling around it is thin compared to what operators need.
• Fork fragmentation. The Camunda 7 community is now split three ways, each fork with a much smaller maintainer team than Camunda had. Security response time is now a question you have to ask each fork separately.

---

Your options

1. Stay on Camunda 7 Enterprise

Pros: zero migration, vendor patches until 2030 (2032 with paid extended support).
Cons: you pay for a platform its vendor has said is ending, and it only delays the decision. Makes sense if you have a plan and need time.

2. Move to a Camunda 7 fork (Operaton, CIB seven, EximeeBPMS)

Pros: as close to drop-in as you will get. Same APIs, same schema, same delegates. Operaton in particular is modernizing the codebase (newer Java and Spring Boot) rather than just renaming it.
Cons: you keep every architectural limit listed above. Each fork is young, with a small team, and you are betting on which one survives. It is the right call when "change nothing" matters more than anything else.

3. Move to Flowable

Pros: actively developed by the original Activiti authors, mature, broader scope and a real company behind it.
Cons: it is a sibling fork, so the architecture is the same generation, and it is still a migration (APIs, schema and extensions differ from Camunda 7). No FEEL. The line between the open-source engine and the commercial Flowable Work/Engage products confuses people.

4. Move to Camunda 8

Pros: the vendor's official path, a modern horizontally scaling engine, a strong modeler, a large company behind it.
Cons: it is not an upgrade, it is a re-platform. Java delegates become job workers, JUEL becomes FEEL, the embedded engine becomes a remote cluster, and you lose the shared transaction. Self-managed production needs a paid license since 8.6. Operations mean a Zeebe cluster plus the Operate, Tasklist, Identity and Optimize components and their secondary storage (Elasticsearch or OpenSearch historically). It also still lacks some BPMN constructs Camunda 7 had, such as standard loops, link events and executable ad-hoc sub-processes (Camunda 8 BPMN coverage).

5. jBPM / Apache KIE / IBM BAMOE

Pros: the strongest DMN engine in the Java world (Drools scores 99.91% on the TCK). The other branch of the tree, with separate DNA.
Cons: years of product churn: BRMS, BPM Suite, PAM, Kogito, then the move to IBM BAMOE on the commercial side and Apache KIE on the community side. Migrating from Camunda 7 is a full rewrite.

6. Drop BPMN, go code-first (Temporal and friends)

Pros: excellent durability and scale, write workflows as code in your language.
Cons: no diagrams, no DMN, no operator UI for business people. If your processes are owned by engineers, this is a great answer. If business and compliance people read your models, you give that up.

7. QuantumBPM

This is ours, so here are the pros and the cons.

---

What QuantumBPM brings to the table

QuantumBPM is not a fork of anything. It is a BPMN 2.0 + DMN 1.5 engine written in Go and built on top of Temporal: every process instance is a Temporal workflow. We took a different approach to the problems the Activiti lineage has had for twenty years:

Old-lineage problem	What we do instead
RDBMS job executor is the scaling ceiling	Durable execution by Temporal: event-sourced history, timers and retries handled by a platform Uber, Stripe and others run at scale
Business code on the engine classpath	Service tasks are dispatched to external workers over an HTTP poll API. Workers can be in any language, with SDKs for JS/TS, Python, Java and Go
JUEL expressions, bolted-on DMN	FEEL everywhere: gateways, mappings, scripts and decisions share one language. 99.32% DMN TCK, full DMN 1.5 boxed expressions, decimal arithmetic
History tables to prune and tune	Postgres for platform data, Temporal for execution history. No Elasticsearch
Thin operator tooling	One UI for modeling, running instances, incidents, replay scrubbing through an instance history, token insert/cancel, and version migration plans
Compensation stops at boundaries	Compensation propagates into called processes and runs their own handlers, so a saga rollback actually completes (details)

Compared to Camunda 8, the closest like-for-like, we also run standard loops, link events and executable ad-hoc sub-processes, and we ship one product with one OpenAPI spec instead of five components with separate APIs.

What "full DMN 1.5" actually buys you

"DMN support" on a feature list usually means decision tables. The Activiti lineage stopped there: Flowable DMN is tables with JUEL, and Camunda 7 added FEEL later as a plugin. Full DMN 1.5 at Conformance Level 3 is a different thing, and it matters to two groups of people.

For architects, it turns decisions into a real architectural layer instead of a lookup table:

• Decisions are composable. Business knowledge models are reusable functions, invocations call them with bound parameters, and boxed contexts break a big decision into named, testable steps. Rules stop being copy-pasted across ten tables.
• Decision services give the decision layer an interface. A decision service exposes part of the decision graph with declared inputs and outputs, so callers depend on a contract rather than the model internals. Camunda 8 doesn't offer them at all.
• Conformance is your exit ticket. Anyone reading this post is paying the price of being locked into an engine. DMN is an OMG standard, and a 99.32% pass rate on the official TCK means a model behaves the way the spec says, not the way one interpreter happens to. That is what makes your decision models portable to any other conformant engine, including ones that aren't ours.
• Decimal arithmetic end to end. 0.1 + 0.2 = 0.3 is true. Money-shaped rules don't pick up floating-point drift.
• Typed contracts. Item definitions type every input and output, so a malformed payload fails loudly at the boundary instead of quietly taking the wrong branch.
• One expression language across BPMN and DMN. Gateway conditions, I/O mappings, scripts and decisions all run on the same FEEL implementation. There is no JUEL-here, FEEL-there split where the two languages treat nulls and dates differently.
• Versioned and audited by default. Every saved model is an immutable version you can pin from a business-rule task, and every evaluation stores its inputs, outputs and per-decision results. "Why was this claim rejected in March?" becomes a query, not a log hunt.

For the people who write the rules, it means logic that used to be pushed into a Java delegate can now stay in the model. Iteration, filtering and quantifiers over collections are part of the language:

some line in claim.lines satisfies line.amount > claim.limit    // true
claim.lines[amount > claim.limit].id                            // ["L2"]
sum(for line in claim.lines return line.amount)                 // 950

Add the conditional, filter, list and relation boxed expressions, every hit policy on decision tables, and a quick-evaluate button in the editor that pre-fills example inputs, and a business analyst can build and test a decision without filing a ticket with the Java team. You can try the exact production FEEL engine in the browser on the FEEL playground, no account needed.

A UX designed from scratch

The Activiti-lineage tooling grew around the engine over time: a desktop modeler, then an admin webapp, then Tasklist, then a separate analytics product. We started from the other end and asked what a team working in 2026 expects from a tool like this.

• One browser app for the whole lifecycle. Model BPMN and DMN, deploy, run, operate and analyze in the same UI. There's no desktop install and no switching between Modeler, Operate, Tasklist and Optimize.
• An editor that behaves like an IDE. FEEL fields are backed by a language server: autocomplete over the variables actually in scope, hover docs, function signatures and inline errors before you save. Validation runs on every save and points at the element ID with the problem, using the same checks the engine runs before it will deploy.
• Run it where you model it. Press Run, give the starting variables as JSON, and watch the active elements light up on the canvas as the instance progresses. Click a call activity to follow the token into the child instance.
• Operations built for debugging, not just monitoring. A replay slider scrubs through an instance's history one event at a time. Incidents can be retried with adjusted input. Messages and signals can be sent from the UI. And running instances are searchable with FEEL: amount > 50000 and customer.vip finds exactly the instances you mean.
• Analytics in the same place. See where time goes, which branches and routes instances take, and compare segments, without standing up a separate analytics product.
• API-first, polyglot by default. Everything the UI does is an endpoint in one OpenAPI spec, with first-party SDKs for JS/TS, Python, Java and Go. Workers in any language poll for jobs over HTTP.
• Ready for AI coding agents. Enterprise customers get an MCP server that plugs into Claude Code, Cursor and other agent tools. It embeds the same DMN and FEEL engine the platform runs, so an agent can validate models, evaluate expressions, run decision tests and dry-run a BPMN process through the real interpreter before anything is deployed. The agent checks its own work against production semantics instead of guessing. Want to try it? Email [e-mail] and we'll set you up.
• Fits into your stack, not the other way around. Single sign-on with any OIDC provider, project-level RBAC, OpenTelemetry and Prometheus metrics, docker compose up locally and a Helm chart for Kubernetes.

Where we fall short

• Community size. We are new and small. You will not find ten years of Stack Overflow answers. But our support is here to help.
• Not open source. QuantumBPM is a commercial product with a free developer tier, a SaaS offering and a self-hosted Enterprise edition with fair and clear licensing.
• Camunda 7 models don't run unchanged. The BPMN diagrams are portable, but camunda: extensions are not read, JUEL ${...} expressions need to become FEEL, and Java delegates need to become external workers. That's the same kind of work a Camunda 8 migration requires, but it is work.
• No transaction sub-process. Camunda 7 has it, we don't (neither does Camunda 8).
• Temporal is a dependency. You operate Postgres + Temporal (or use Temporal Cloud). That's lighter than Zeebe + Elasticsearch, but heavier than "one JVM and a database".

What the migration looks like

A typical Camunda 7 service task and gateway:

<bpmn:serviceTask id="charge" name="Charge card"
    camunda:class="com.acme.ChargeCardDelegate" />

<bpmn:sequenceFlow id="toReview" sourceRef="gw" targetRef="review">
  <bpmn:conditionExpression>${amount > 1000}</bpmn:conditionExpression>
</bpmn:sequenceFlow>

The same in QuantumBPM:

<bpmn:serviceTask id="charge" name="Charge card">
  <bpmn:extensionElements>
    <quantum:taskDefinition type="charge-card" />
  </bpmn:extensionElements>
</bpmn:serviceTask>

<bpmn:sequenceFlow id="toReview" sourceRef="gw" targetRef="review">
  <bpmn:conditionExpression>amount > 1000</bpmn:conditionExpression>
</bpmn:sequenceFlow>

The body of ChargeCardDelegate moves into a worker that polls for charge-card jobs. It can stay in Java, or move to whatever language the team that owns it prefers. The engine no longer runs your code, and your code no longer ships with the engine.

---

A decision shortcut

• You need zero change and time to think → Camunda 7 Enterprise, or a fork. Pick the fork whose maintainers you trust most, and check how they handle security patches.
• You are committed to the Java BPM ecosystem and want a company behind it → Flowable or Camunda 8. Budget for Camunda 8 being a re-platform and for its license.
• Your processes are really engineering workflows → consider plain Temporal.
• You are re-platforming anyway, want real DMN/FEEL, polyglot workers and durable execution without running Elasticsearch → try QuantumBPM.

Whichever you choose, keep in mind that Camunda 7 CE end of life forces a decision whose result you will live with for the next decade. Picking the fourth fork of a 2010 codebase is a valid choice. Just make it deliberately, not because the migration guide looked shortest.

---

QuantumBPM is at quantumbpm.com. You can run it locally with the dev-server Docker image or use free developer tier. Camunda comparison goes deeper on the architecture and I'm happy to answer migration questions in the comments. If you would like to try the MCP server with your own coding agent, or want help planning a Camunda 7 migration, write to [e-mail].