Camunda 7 or jBPM: when each one fits a Java process team
If your team runs a Camunda 7 estate and needs a supported path after the Community Edition's final feature release, 7.24, scheduled for October 14, 2025, the question is whether you must keep a vendor support obligation or can accept an open-source project still in incubation. Camunda 7 Enterprise Edition support is the better fit when your auditors, insurers or internal risk policy require a commercial party to patch the engine through April 9, 2030, with paid extended support available through April 2032. jBPM from Apache KIE fits better when you want an Apache-licensed engine with no vendor dependency and can carry the risk of an incubating project. The decision turns on four factors: your support obligations, whether you need DMN and CMMN alongside BPMN, whether your platform is moving toward Quarkus or Spring Boot, and how much incubation status your risk owners will accept.
Start with the support clause, because it decides the rest. Camunda 7 Enterprise Edition keeps the MyBatis-backed relational engine you already operate, so the migration effort is mostly in your own code and your Cockpit and Tasklist usage. jBPM changes the runtime: its 10.2.0 release moved to Quarkus 3.27.2 and Spring Boot 3.5.10, replaced the classic BPMN and DMN editors with a new BPMN editor, and added DMN 1.6 and Java 21 support. Confirm with the Apache KIE project which runtime and editor your models need, then test a representative process, including its DMN decision tables, in a non-production environment before you commit. Ask your Camunda contract owner to confirm the exact Enterprise support terms in writing.
On the incubation question, the Apache KIE site states that incubation does not necessarily reflect the completeness or stability of the code, only that the ASF has not yet fully endorsed the project. Treat that as a governance input, not a verdict on quality. Record which KIE release you would pin, check the release history on the apache/incubator-kie-drools releases page, and write down who on your side will triage a defect in an incubating component. If your process estate needs CMMN case management, verify that jBPM covers the case models you use before choosing it, since this comparison does not establish that from the supplied facts.
Which platform fits which Java process scenario
This table maps common Java process scenarios to the platform that fits each one best, with the condition that drives the choice. Read each row against your own estate, support obligations and roadmap, since the right answer often depends on whether you already run Camunda 7 Java delegates in production.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Regulated bank with a Camunda 7 estate and production support needs | Camunda 7 Enterprise, with a migration plan | Camunda 7 Enterprise end of life was extended to April 9, 2030, with paid extended support to April 2032 (Camunda announcement). Staying on the same engine keeps existing models and operations unchanged, but confirm the support contract and your own exit timeline in writing. |
| New Quarkus service that needs BPMN with DMN | jBPM from Apache KIE | Apache KIE 10.2.0 moved to Quarkus 3.27.2 and added DMN 1.6 support, so the engine matches a Quarkus stack. Confirm your Java 21 and Quarkus versions against the release post before committing. |
| Spring Boot team with existing Camunda 7 Java delegates | Camunda 7 for now, or a compatible fork | Delegates and models carry over with little change only while the engine API stays the same. jBPM uses a different API, so moving delegates means rewriting them. Plan the Spring Boot version against your own baseline, since jBPM 10.2.0 targets Spring Boot 3.5.10. |
| Team that needs CMMN case management | Neither as a default, check Flowable | Camunda 7 supports CMMN and jBPM's CMMN coverage should be checked against your case model before choosing. Flowable supports BPMN, CMMN and DMN under Apache-2.0, so confirm it against your case requirements. |
| Team that wants to avoid a new engine altogether | Camunda 7 Enterprise or a compatible fork | Staying on the existing engine avoids model conversion, retraining and new operational tooling. Choose this path only if your support horizon fits the 2030 or vendor fork timelines you have confirmed. |
| Team building a new process platform with no legacy models | jBPM, if Apache KIE governance fits your risk tolerance | Apache KIE is still in incubation at the ASF, which the KIE site notes does not necessarily reflect completeness or stability. Ask for the project's release and maintenance plan before relying on it for production. |
| Team that needs a vendor-backed support contract for the engine | Neither jBPM nor Camunda 7 Community Edition | Camunda 7 Community Edition received its last feature release in October 2025 with no further security patches. Compare paid options with the vendors directly rather than assuming open-source support is available. |
How Camunda 7 and jBPM are built and embedded
Camunda 7 and jBPM both run process engines inside Java applications, but they differ in how they store state, which tools ship with them, and which framework baselines they target. The cards below cover the parts that drive day-to-day operations, upgrade effort and the staffing each engine needs. Where the supplied facts do not settle a point, the card names what to confirm with the project or in a proof of concept.
Relational persistence through MyBatis
Camunda 7 persists process definitions, instances, tasks and history to a relational database through MyBatis, so the database is the system of record for running processes. For operations, this means the database platform, backup scope, history retention and schema upgrades are part of the engine's lifecycle, and your DBA team needs a say in them. Confirm which database engines and versions jBPM supports, how it manages its schema across upgrades, and whether its persistence layer exposes the same tables your reporting already reads.
Web applications and operator tooling
Camunda 7 ships Tasklist, Cockpit and Admin as web applications, covering human task work, process instance monitoring and user administration. Apache KIE 10.2.0 replaced the legacy GWT-based BPMN tooling with a new BPMN editor and removed the classic BPMN and DMN editors, so the modeling experience has changed recently. Before choosing jBPM, confirm whether it provides equivalents for task inboxes, instance inspection, incident handling and user administration, and whether those tools are shipped or must be built by your team.
Embedded, shared or standalone deployment
Camunda 7 can run embedded inside a Java application, as a shared engine serving several applications, or as a standalone server. The choice changes how releases are coordinated, who owns engine upgrades and where the database connection lives. jBPM is developed under Apache KIE, and its 10.0.0 release moved the projects to Java 17, Jakarta 10, Quarkus and Spring Boot. Confirm which of the three deployment modes jBPM supports for your target framework, and how a shared engine would be upgraded without stopping dependent applications.
REST API surface for integration
Camunda 7 provides REST APIs alongside its Java API, which lets external systems start processes, query tasks and read history without linking against the engine. Integration teams should check how much of that surface their existing clients depend on, since a different REST contract forces client rewrites even when the BPMN models move unchanged. For jBPM, the supplied facts do not describe its REST endpoints, authentication model or versioning policy, so ask the Apache KIE project for the current API reference and test your critical calls against a running instance.
Quarkus and Spring Boot baselines in jBPM 10.2.0
jBPM 10.2.0 moved to Quarkus 3.27.2 and Spring Boot 3.5.10 and added Java 21 support, so the framework versions your platform team standardizes on will decide whether jBPM fits. Teams that already run Spring Boot 4 or require Java 17 only should verify compatibility before planning. The supplied facts do not give Camunda 7's framework baselines for the 7.24 line, so confirm those in its documentation and compare them with your own platform roadmap, including the Java version your security scanners and base images support.
DMN and CMMN coverage
Camunda 7 supports BPMN for workflow, CMMN for case management and DMN for decision management, so one engine family can cover processes, cases and decision tables. jBPM 10.2.0 added DMN 1.6 support, which matters if your decision tables were authored against a specific DMN version. The supplied facts do not confirm CMMN support in jBPM, so if case management is part of your scope, verify CMMN execution, the supported specification version and how decision tables are deployed alongside processes before you commit.
Camunda 7 and jBPM feature and licensing comparison
This table compares license, project status, BPMN, CMMN and DMN coverage, runtime baselines, release cadence and editors for Camunda 7 and jBPM. Where the supplied facts do not settle a row, the cell names what to confirm with the vendor or project. The main takeaway is that Camunda 7 has a fixed end-of-life path, while jBPM's newer releases add Java 21, DMN 1.6 and a new editor but sit in ASF incubation.
| Capability | Camunda 7 | jBPM (Apache KIE) |
|---|---|---|
| License and source status | Apache-2.0 source; repository archived with 7.24.0 as last tag | Apache-2.0 within Apache KIE; project in incubation at the ASF |
| Project status and support | No Community Edition releases or security patches after October 14, 2025; Enterprise support to April 9, 2030 | Community project; incubation does not measure stability. Confirm any commercial support with vendors |
| BPMN coverage | Full BPMN process engine persisting to a relational database through MyBatis | BPMN process engine; confirm element and version coverage with the project |
| CMMN coverage | CMMN case management supported | Not settled by supplied facts; confirm CMMN support with the project |
| DMN coverage | DMN decision management supported; confirm the DMN version your models need | DMN 1.6 support added in 10.2.0, released April 28, 2026 |
| Java and runtime baselines | Confirm the minimum Java version and Spring Boot support for 7.24 in its release notes | Java 21 support added in 10.2.0; moved to Quarkus 3.27.2 and Spring Boot 3.5.10 |
| Release cadence | 7.24 long-term support updates in April and October under Enterprise support through 2030 | Tags 10.0.0 (December 11, 2024), 10.1.0 (July 8, 2025) and 10.2.0 (April 28, 2026) |
| Modeling editor | Ships Tasklist, Cockpit and Admin web applications; confirm the modeling tool you will use | 10.2.0 replaced GWT-based BPMN tooling and removed the classic BPMN and DMN editors |
What each license and edition covers and what is paid for
Camunda 7 is the Java BPMN engine whose source code is licensed under Apache-2.0, so the open-source code can be used, modified and redistributed under that license. The release picture is different from the license picture. Camunda's final Camunda 7 feature release, 7.24, was scheduled for October 14, 2025, and after that no further releases or security patches are made for the Community Edition. The camunda-bpm-platform repository is archived on GitHub, with 7.24.0 as its last tag.
The paid path is the Enterprise Edition. Camunda extended Enterprise end of life to April 9, 2030, and 7.24 is designated as a long-term support release that receives updates twice a year, in April and October. Paid extended support is available from April 2030 through April 2032.
- Apache-2.0 code: The open-source code carries the Apache-2.0 license, but the license does not by itself carry patches after October 2025.
- Community end of releases: No further Community Edition releases or security patches follow 7.24.
- Enterprise end of life: Enterprise support now runs to April 9, 2030, with 7.24 as the long-term support line.
- Biannual updates: 7.24 receives updates in April and October during the Enterprise window.
- Paid extended support: Extended support from April 2030 through April 2032 is a separate paid option.
Confirm with Camunda the exact contract terms, what the Enterprise subscription covers, and the price basis for extended support before you plan around 2032.
jBPM is the process automation project within Apache KIE, and the KIE projects are licensed under the Apache License 2.0. Apache KIE is still in incubation at the Apache Software Foundation. Incubation does not necessarily reflect the completeness or stability of the code. It only means the ASF has not yet fully endorsed the project, so the license is clear while the governance maturity is still developing.
The supplied facts do not describe any paid jBPM edition, subscription or commercial support contract. Do not assume one exists. Treat the open-source release as the baseline and ask the project and any vendor directly what support options, if any, they offer.
- Apache-2.0 license: The KIE projects, including jBPM, are under Apache 2.0.
- Incubation status: Apache KIE remains in incubation, which signals the ASF has not fully endorsed the project.
- Recent release line: Apache KIE 10.2.0 was tagged on April 28, 2026, and moved to Quarkus 3.27.2 and Spring Boot 3.5.10.
- No named paid edition: The supplied facts do not describe a commercial jBPM edition.
- Support gap to close: Commercial support, if any, must be confirmed with the project or a vendor.
Before you commit, ask who will patch jBPM for your release line, what the support path is after a KIE release, and whether a commercial agreement exists in writing.
What drives the running cost of each engine
The largest recurring line for Camunda 7 is the Enterprise Edition subscription, because Community Edition no longer receives releases or security patches after 7.24. Camunda's announcement extends Enterprise end of life to April 9, 2030, with 7.24 as a long-term support release updated in April and October, and paid extended support from April 2030 through April 2032. Ask the vendor for the subscription price per year, whether it is priced per engine, per node or per developer, what it includes for patch turnaround, and whether extended support is quoted now or only when you reach 2030. The jBPM path carries no supplied commercial terms, so ask Apache KIE's community channels and any commercial provider you engage what support, if any, you would pay for, and budget the internal patching work as the cost that replaces a subscription.
Engineering time is the cost most likely to be underestimated. Moving to jBPM means aligning the application with the Java, Spring Boot and Quarkus baselines the project currently documents, including the 10.2.0 move to Quarkus 3.27.2 and Spring Boot 3.5.10 and Java 21 support. Each framework upgrade, the Java upgrade and the Quarkus or Spring Boot version you pick recur across the life of the system, and each one touches delegates, listeners, external task workers and security configuration. Infrastructure for the relational database is also recurring: both engines persist process state to a database, so you pay for database hosting, backups, high availability and the capacity planning that grows with history tables. Confirm how each engine's history and purge settings are configured in your environment before you size that database.
Skills and rework split the cost into one-time and recurring parts. The one-time items are migrating existing BPMN and DMN assets, rewriting Camunda-specific delegates and forms, and testing the cutover, including any in-flight process instances you must carry across. Recurring costs come from keeping BPMN modelers and Java developers in step: business analysts who edit diagrams need a modeling tool and a review process, while developers own the service tasks, deployment pipeline and security patches. Before you accept a quote, ask for a written list of one-time deliverables, the named components each one covers, the upgrade windows assumed, the support terms for each year, and who is responsible for the database and runtime patches after handover.
What moving from Camunda 7 to jBPM would take
The sequence below turns an unscoped migration into a written inventory, a tested proof of concept, a plan for running process instances, and a cutover that can be rolled back. Each step ends with an output a reviewer can check.
Inventory models, delegates and integrations
Your team lists every BPMN and DMN file, every form, every Java delegate, external task worker, execution and task listener, script task, and REST or Java API call that touches the Camunda 7 engine. Map each item to one of three buckets: carried over as is, carried over with edits, or rebuilt. The output is a signed inventory with counts per bucket and an owner for each process. Confirm the bucket for Camunda-specific forms and web tooling early, because Cockpit, Tasklist and the Camunda forms engine have no direct one to one replacement in jBPM and must be rebuilt or replaced.
Compare persistence and history models
Engineers compare how Camunda 7 persists runtime and history data through its relational schema with how jBPM stores process instances, tasks, variables and audit history. Check which history levels your reports depend on, which custom queries read the Camunda tables directly, and how your reporting and audit consumers read history today. The output is a written data map that names every table, view or API your reports depend on and states whether jBPM provides the same data, provides it differently, or does not provide it. Do not assume in-place data carry over; treat it as a question to answer with the jBPM project and a test.
Verify in-place migration claims independently
Flowable published a 2022 engineering post stating that Camunda 7 and Activiti data can be migrated to Flowable in place, including active instances and history, and it offers its own free LEAP report. That is a claim from a vendor with a commercial interest in the move, not an independent test of jBPM. Ask jBPM's maintainers and any integrator you consider for documented evidence on Camunda 7 data, and run your own check against a copy of production data. The output is a short written finding stating what was verified, on which versions, and what remained unverified.
Build a proof of concept with representative processes
Pick a small set of processes that cover the hard cases: a long-running process with timers and boundary events, a process with a multi-instance subprocess, a DMN decision table in use, and a process with a human task and a form. Rebuild each on jBPM in a non-production environment, deployed the way production will run it, whether embedded in Spring Boot or Quarkus. Compare behavior, performance under realistic load, and the effort each process took. The output is a written test report with pass or fail for each case and a list of the rebuilt Java and form components.
Plan the treatment of active instances and history
Decide, for each process family, whether running instances finish on Camunda 7 while new instances start on jBPM, whether instances are migrated, or whether history is archived and read from a separate store. Migrating active instances requires a mapping of activity IDs, variables and token positions, and it needs a dry run against a copy of production data. Record the rollback rule for each family. The output is an approved migration plan that names the instance count, the migration method, the verification query and the person who signs off the result.
Rebuild integrations and test operations
Replace Camunda-specific listeners, external task clients and REST calls with jBPM equivalents, and rebuild monitoring, alerting and runbooks for the new engine. Test backups and restores, upgrade paths, and access control for the process administration tools you will use instead of Cockpit and Admin. The output is a tested runbook and a list of operational gaps with an owner and a plan for each.
Run the cutover and keep a rollback path
Choose a cutover window agreed with the business owners, freeze deployments of Camunda 7 process changes during that window, route new instances to jBPM, and monitor queues, failed jobs and error rates. Keep Camunda 7 running in read-only or drained mode until the agreed exit criteria are met. The output is a signed cutover record with the criteria that were met, the rollback decision point, and the date the Camunda 7 runtime was retired.
Where Camunda 7 and jBPM projects usually run long
Most overruns come from the cutover, not the initial build. A jBPM or Camunda 7 deployment that works in a test environment can still stall when process instances already running on the old engine must continue on the new one. Before any cutover date is set, count the active instances, the timers and the human tasks in flight, and decide whether they finish on the old runtime or migrate. Camunda 7 persists its state through MyBatis into a relational schema, so schema compatibility, history tables and job executor behavior need to be tested with real instance data, not a sample. Ask whether the target runs against the same database and whether any migration tooling has been tested against a copy of production data.
Custom Java listeners, task listeners, service task delegates and customized Cockpit or Tasklist equivalents tend to consume the most effort. Each one is code your team owns after go-live, and each must be retested when Spring Boot or Quarkus moves to a new major line. jBPM 10.2.0 moved to Quarkus 3.27.2 and Spring Boot 3.5.10 and requires Java 21 for that line, so the framework baseline you pick now determines the Java upgrade you schedule later. Inventory every listener and delegate, map each to its target API, and assign an owner before estimating the work. Identity and single sign-on for the monitoring and task consoles also belong in that inventory, since each console needs its own integration with your identity provider.
Editor retraining and the support boundary are the two overruns teams most often underestimate. jBPM 10.2.0 replaced the legacy GWT-based BPMN tooling with a new editor and removed the classic BPMN and DMN editors, so modelers trained on Camunda 7 tooling will need time on the new interface. Apache KIE is still in incubation at the Apache Software Foundation, and the KIE site notes that incubation does not necessarily reflect the completeness or stability of the code. Confirm in writing who fixes a defect, what release line receives patches, and whether your CI and test process logic works against the version you intend to run. Those answers set the risk you carry, and they belong in the scope agreement before work starts.
Questions buyers ask before choosing between Camunda 7 and jBPM
What drives the cost of moving from Camunda 7 to jBPM?
The cost is driven by how much of your Camunda 7 estate has to change, not by the engine license, since both engines are Apache-2.0 licensed. Cost components include the assessment of your process models, rewriting Java delegates and listeners against the jBPM and KIE APIs, replacing Camunda 7 REST calls and Cockpit or Tasklist workflows, retesting, and retiring any custom web tooling. The main recurring costs are your own engineers' time and any retainer for upgrades and support. Ask any firm for a fixed-scope quote that lists the process count, the custom Java code, the DMN tables and the integrations in writing before work starts. Most engagements are fixed-scope, so the agreed deliverables define the price.
How long does a Camunda 7 to jBPM move or support decision usually take?
No supplied fact gives a duration for this move, so confirm timing against your own inventory rather than a generic estimate. The duration is set by the number of active process instances you must keep running, how many process definitions are affected, how much custom Java code depends on the Camunda 7 API, and whether the team must retain an audit history. Your Camunda 7 Enterprise support runs through April 9, 2030, with extended paid support available through April 2032, so the deadline is not forcing an immediate move. Use that window to decide the target before you schedule the cutover.
What does the internal team need to provide during the move?
Your team needs to own the process knowledge, the business rules and the acceptance criteria, because an outside partner cannot judge whether a converted process behaves correctly without them. Engineers must supply access to the source repositories, the Camunda 7 runtime configuration, the database, and test environments. Expect a named architect to approve the target design and a tester who can run regression scenarios against both versions. Confirm these responsibilities in the written scope so each side knows what it delivers.
Can our Java team run jBPM in production without an outside partner?
A team with strong Java and Spring Boot experience can run jBPM without a partner, provided it accepts the operating responsibilities. jBPM is embedded in your application and runs on Quarkus or Spring Boot, so your team owns the upgrades, database migrations, monitoring and incident response. Apache KIE 10.2.0 moved to Quarkus 3.27.2 and Spring Boot 3.5.10 and supports Java 21, so plan the runtime baseline before you commit. If the team lacks capacity for these tasks, an outside partner can take on a retainer for upgrades and continuous support.
Does jBPM's incubation status change the support plan?
Incubation does not automatically change the support plan, but it changes the risk you should document. The Apache KIE site states that incubation does not necessarily reflect the completeness or stability of the code, only that the ASF has not yet fully endorsed the project. Apache KIE 10.0.0 was tagged on December 11, 2024, 10.1.0 on July 8, 2025 and 10.2.0 on April 28, 2026, so there is a visible release cadence to review. Your support plan should name who fixes defects, how security patches are delivered and which release line you will pin to, whichever vendor or partner you choose.
Which jBPM features will our engineers need to learn first?
Your engineers should learn the new BPMN editor, which replaced the legacy GWT-based tooling in Apache KIE 10.2.0, along with DMN 1.6 support. The classic BPMN and DMN editors were removed in that release, so models built with older tooling may need to be opened and saved in the new editor. Engineers also need to understand the KIE runtime APIs and how jBPM connects to Quarkus or Spring Boot. Check these items against your current Camunda 7 usage before scoping the training.
Does Camunda 7 Community Edition's end of life affect our choice?
Yes, it affects the decision for Community Edition users, but not for Enterprise customers. Camunda's final Camunda 7 feature release, 7.24, was scheduled for October 14, 2025, after which no further releases or security patches are made for Camunda 7 Community Edition. Enterprise customers have maintenance to April 9, 2030 on 7.24 as a long-term support release, which gives time to compare jBPM with other paths. Confirm your edition and entitlement with Camunda before you decide.
How DeployOpen helps choose, implement or migrate Java process engines
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Camunda 7 vs jBPM decision, we start with the process models, the runtime and the licensing position you must defend, then write down what each path would involve before any build work begins.
How we scope
- Inventory the BPMN, DMN and CMMN artifacts, custom listeners and REST clients your Camunda 7 estate actually uses.
- Agree in writing which runtime options are evaluated, such as Spring Boot or Quarkus embedding, and what is out of scope.
- Confirm with your vendors the current support terms, editions and end-of-life dates before committing to a path.
How we build
- Build a proof of concept that runs representative processes on the candidate engine, backed by your database and identity setup.
- Test process behavior, human task flows, decision tables and persistence against the same scenarios on each option.
- Convert or port a bounded set of models so the effort of moving between the engines is measured, not estimated from documentation.
How we hand over
- Deliver architecture notes, deployment runbooks, backup and upgrade procedures and the migration plan in documented form.
- Record the decisions made, the open risks and the items your team or the vendor must confirm before production use.
- Walk your platform and development teams through the handover so they can operate and extend the chosen engine.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Keep the upgrade path to newer engine releases documented and tested against your own process models.
- Prepare system documentation and evidence for compliance assessments, while independent auditors issue any formal reports.
