Which Camunda 7 path fits your situation
If your Camunda 7 process applications need to keep running past the Community Edition end of life, the choice is between three paths that all keep the Camunda 7 API and BPMN, DMN and CMMN models: Camunda 7 Enterprise, the community-governed Operaton fork, or the vendor-backed CIB seven fork. Camunda 7 Enterprise fits teams that need a vendor-supported line, with 7.24 receiving updates in April and October through April 9, 2030 and paid extended support available through April 2032, per Camunda's announcement. Operaton fits teams that want an open, community-governed fork with no commercial edition, where each release is supported for six months until the next one ships. CIB seven fits teams that want a vendor-backed fork with paid LTS and Enterprise editions and a documented migration path from the Camunda 7.23 and 7.24 baselines.
Because all three share the same API and model, the decision is mostly about support model and exit path, not about rewriting process logic. Ask each vendor or community what they will patch, for how long, and how urgent security fixes reach your production environment. Check that your database and Java runtime are on each platform's supported list, since the version floors differ: Operaton 2.1 requires Java 17 and minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, while CIB seven 2.2 lists Java 17 and 21 with PostgreSQL 15 to 18. Confirm these against the current release notes before you commit.
Plan the exit path now. If you may later move to Camunda 8, a non-BPMN engine or another fork, record which org.camunda references, scripts and custom classes live in your database, because objects already stored there are not renamed automatically by the CIB seven migration. Verify whether your team can own patching if you choose the community route, and get written scope and support terms from any commercial provider before the Camunda 7 Enterprise or CIB seven contract is signed.
Which platform fits which scenario
This table matches common Camunda 7 scenarios to the platform that fits best and the condition that makes it so. Read each row as a starting point, then confirm the condition against your own support contracts, database and upgrade capacity. The main takeaway is that the choice turns less on features, which all three share at the engine level, and more on who you want to hold accountable for support and how much upgrade cadence your team can absorb.
| Scenario | Best fit | Condition that makes it the fit |
|---|---|---|
| Regulated bank that needs a contractual support party and a fixed lifecycle | Camunda 7 Enterprise | Your procurement requires a single commercial vendor with maintenance dates contracted to April 9, 2030, and paid extended support to April 2032 is acceptable. |
| Regulated organization that wants a vendor fork with paid LTS and security patch cadence | CIB seven (LTS or Enterprise edition) | You want a named vendor behind a fork, and confirm in writing the support duration per edition, since the FAQ gives no fixed duration. |
| Team that wants no vendor lock-in and can absorb a six-month upgrade cadence | Operaton | Your engineers can test and deploy a feature release every April and October, because each version is supported for six months and there is no LTS line. |
| Team with an existing Camunda 7 codebase that needs API and schema compatibility with minimal code change | Operaton or CIB seven | Your application can move to the org.operaton or org.cibseven package names with the OpenRewrite recipe or script, and you test stored objects that still reference org.camunda classes. |
| Team that needs its own web UI for task lists and process monitoring without Camunda Tasklist, Cockpit or Admin | CIB seven 2.x | You accept the web UI shipped from version 2.0 and confirm it covers your user and rights management needs. |
| Team that must run on a newer database or Java baseline, such as PostgreSQL 18 or Java 21 | CIB seven 2.2 or Operaton 2.1 | Confirm your target database version against each supported environments list, since CIB seven lists PostgreSQL 15 to 18 and Operaton lists PostgreSQL 14 as the minimum. |
| Team planning to move to Camunda 8 within a few years | Camunda 7 Enterprise to 2030, then Camunda 8 | You plan the rework separately, because the Diagram Converter covers BPMN, DMN and forms but not code and API changes, and Camunda 8 production use requires a commercial license under the Camunda License 1.0. |
| Team that wants to move away from BPMN modeling toward code-defined workflows | Neither fork (evaluate Temporal) | Your process logic is best expressed in general-purpose code, and the forks would only extend the life of a BPMN model you plan to retire. |
What each platform licenses and charges for
Camunda 7 remains Apache-2.0 licensed in its source history, but the paid path is Camunda 7 Enterprise Edition, which Camunda extended to an end of life of April 9, 2030. Camunda's announcement says 7.24 is the long-term support release, receiving updates twice a year in April and October. Paid extended support is available from April 2030 through April 2032. The Community Edition receives no further releases or security patches after its final feature release, 7.24, which was scheduled for October 14, 2025. Your subscription therefore buys patches and support for the codebase you already run, not new features.
- Paid: the Enterprise subscription, which covers the maintenance window and any extended support you buy beyond April 2030.
- Not paid, but unpatched: the Community Edition, which no longer gets security fixes, so staying on it leaves you carrying the patch risk yourself.
- Recurring: the subscription fee for each year of coverage, with the extended support term billed separately.
- Ask in writing: whether the April and October updates apply to 7.24 only, what the response times are, and what happens to pricing if you need support beyond April 2032.
Confirm the subscription terms and the scope of extended support directly with Camunda, since neither the license fee nor the renewal structure is set out in the facts supplied here.
Operaton is an Apache-2.0 licensed BPMN 2.0 engine derived from the Camunda 7 codebase. Its repository describes it as having no open-core model and no commercial editions, so there is no paid tier that unlocks features. Professional support and consulting come from several independent service providers rather than from one vendor. The project is maintained by an open-source community, and its FAQ says governance is still forming, with plans for a non-profit organization to manage key decisions.
- Not paid: the software itself, including the engine, REST API and deployable BPMN and DMN models.
- Paid, from outside parties: professional support, consulting and migration help, contracted separately from any independent provider you choose.
- Recurring: support contracts, if you buy them, and the internal effort to apply half-yearly and monthly patch releases.
- Ask in writing: which provider will cover security response, what their response commitments are, and whether they will support releases that are only six months old.
Because there is no vendor contract, the warranty, indemnity and roadmap terms in your agreement will come from whichever service provider you hire, so check those terms with each candidate.
CIB seven's source files are Apache License 2.0, and its FAQ says the software may be used free of charge in commercial software, at least for its core functions. A free Community edition is available. The paid editions are Community+, LTS and Enterprise, which add security patches and hotfixes. CIB's FAQ recommends the LTS edition for high-volume or regulated environments, and says CIB seven Enterprise includes all Camunda 7 Enterprise features starting with version 2.1.2. For the paid distributions, security patches and hotfixes are released every 4 to 8 weeks, with urgent fixes made as needed for major security issues. The FAQ does not give a fixed support duration per edition.
- Free: the Community edition, which you can use under Apache-2.0 without a contract.
- Paid: Community+, LTS and Enterprise, each priced separately and each adding patches and hotfixes.
- Recurring: the subscription for the paid edition you choose, plus your own testing of each patch drop.
- Ask in writing: the support end date for each edition and whether the 4 to 8 week patch cadence is contractual or a target.
The FAQ gives no fixed support duration, so ask CIB for the support term in writing before you commit to LTS or Enterprise.
What drives the running cost of each path
Each path shifts cost between a paid support contract, internal upgrade labor and a one-time migration project. The cards below separate what recurs from what is paid once, and what to ask for before you commit to one path.
Support subscription and who is paid
Camunda 7 Enterprise is a paid subscription from Camunda, and its support runs to April 9, 2030, with paid extended support from April 2030 through April 2032. CIB seven's LTS and Enterprise editions are paid through CIB software, and Operaton has no commercial edition, so you buy support from independent service providers if you want it. Ask each vendor what the subscription covers, whether it recurs per instance, per node or per user, and what happens to price at renewal.
Upgrade effort per release cycle
Operaton ships feature releases in April and October with monthly patches, and each version is supported for six months with no LTS line, so your team must upgrade about twice a year to stay supported. CIB seven's paid distributions receive security patches and hotfixes every four to eight weeks, and the LTS edition is recommended for high-volume or regulated environments. The recurring labor cost depends on how often you apply those releases and how much regression testing each one needs.
Database and Java baseline upgrades
Operaton 2.1 requires Java 17, is tested on Java 17, 21 and 25, and sets minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4. CIB seven 2.2 supports Java 17 and 21 with PostgreSQL 15 to 18 and MySQL 8.0. Each platform bump can force a JDK, driver, container image or database engine change across every environment, so the cost rises with the number of stacks you run. Ask which versions your own databases and runtimes will need within your support window.
Migration project from 7.24 or 7.23
Operaton keeps database schema version 7.24 and offers an OpenRewrite recipe for the package rename, so the one-time work centers on dependency changes, testing and the cutover plan. CIB seven documents a migration from the 7.23 and 7.24 baselines, with an OpenRewrite script for Maven versions, artifact names and imports, but objects already stored in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically. Budget for reviewing those stored objects and for any projects still on older Camunda versions that must first move to the matching baseline.
Exit cost if you leave later
Each path leaves a different exit. Operaton and CIB seven both start from the Camunda 7 API and schema, so moving between them or back toward Camunda is mostly a package and dependency change, but any renamed class references in stored data still need attention. Moving to Camunda 8 is a larger rework that the Diagram Converter covers only in part. Ask each vendor whether it will support a schema export or a data handover, and price that work into your five-year plan before you pick a path.
How the migration from Camunda 7.24 works for each fork
The Operaton path is the shorter one because Operaton keeps the Camunda 7 database schema at version 7.24, so the database does not need a schema migration. The work centers on the application: run the OpenRewrite recipe from the operaton/migrate-from-camunda-recipe repository to update Maven coordinates and Java imports, then accept the rename from the org.camunda package namespace to org.operaton. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, so confirm your runtime and any Spring Boot or application server pins before you change the dependency. Your own test suite is the main check, because the release notes describe API compatibility with Camunda 7 CE 7.24 but your custom listeners, scripts and connectors still need to run against the new package names.
The CIB seven path has an extra precondition. CIB seven's migration guide says the 2.1 backend is based on Camunda 7.24.0 and the 2.0 backend on 7.23.0, and that projects on older Camunda versions must first move to the matching Camunda baseline. Only then apply the OpenRewrite migration script, which updates Maven versions, artifact names and imports. The script changes Java imports from org.camunda to org.cibseven and the Liquibase changelog path from org/camunda to org/cibseven, so review any custom Liquibase changelogs and deployment scripts that reference the old path.
The stored objects are the step most often missed. Script tasks, variables and other data already in the database that reference org.camunda classes are not renamed automatically by either route, so inventory them before cutover. CIB seven offers namespace compatibility properties for scripting and reflection, but they are disabled by default, so decide deliberately whether to enable them for a transition period and test that the stored definitions still execute. Ask CIB seven or Operaton which of these objects their tooling does not touch, and plan a test that runs every long-lived process instance and script path.
What implementing each path involves
This sequence takes a team from an inventory of its Camunda 7 process estate to a documented decision on support, upgrades and exit terms. Most steps are shared across all three paths, and the fork-specific steps are the ones that change the code, the database and the support contract.
Inventory the process estate
List every BPMN process, DMN decision table, CMMN case and form in use, along with the Java classes, scripts, listeners, connectors and custom REST clients that call the engine. Record which items reference org.camunda packages directly, since those are the items that need attention on any path. Your own engineers or an implementation partner can do this, and the step is complete when every artifact has an owner and a path recorded in a shared inventory. (Shared step.)
Confirm Java and database baselines
Check the current Java runtime, application server and relational database against the supported matrix of each candidate. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, with minimum database versions listed in its release notes. CIB seven 2.2 lists Java 17 and 21, with its own database and container matrix. Where a platform version falls outside a matrix, record the upgrade it needs as a separate work item. The step closes with a signed-off compatibility table per candidate. (Shared check, fork-specific matrices.)
Confirm the migration baseline for the fork
Establish which Camunda 7 version your engine currently runs. CIB seven's migration guide says its 2.1 backend is based on Camunda 7.24.0 and its 2.0 backend on 7.23.0, and that older Camunda versions must first move to the matching baseline. Operaton 2.1 is API-compatible with 7.24 and keeps the 7.24 schema version. Document the gap, if any, and the order of upgrades the gap requires. (Fork-specific.)
Run the migration tooling in a non-production environment
Apply the chosen tooling to a copy of the application and database. For Operaton, that is the OpenRewrite recipe in the migrate-from-camunda recipe repository. For CIB seven, it is the OpenRewrite-based script that updates Maven versions, artifact names and imports, plus the Liquibase changelog path change. Build, run the automated tests and compare results against the Camunda 7 baseline. The step closes when the build passes on the target runtime and the test results match, or each difference is logged with a fix. (Fork-specific tooling, shared test approach.)
Verify stored objects, scripts and variables
Check what the migration does not change automatically. CIB seven's guide notes that objects already in the database, such as script tasks or variables that reference org.camunda classes, are not renamed, and its namespace compatibility properties are disabled by default. Operaton changes its package namespace to org.operaton, so the same review applies there. Run in-flight and history data through a representative set of process instances and confirm that scripts, listeners and variables resolve. The output is a list of stored items reviewed, with each exception resolved or accepted in writing. (Shared review, fork-specific namespace risks.)
Plan the release cadence and patch windows
Write down how each option ships releases and patches, then map that to your change control. Operaton ships feature releases in April and October with monthly patch releases, and each version is supported for six months until the next one ships, with no traditional LTS line. CIB seven's paid distributions receive security patches and hotfixes every four to eight weeks, and its FAQ recommends the LTS edition for high-volume or regulated environments. Camunda 7 Enterprise receives updates on a twice-yearly schedule on 7.24 LTS. Agree a planned upgrade slot and a test cycle for each option. (Fork-specific.)
Confirm support and exit terms in writing
Before production cutover, obtain the support scope, response commitments, edition features and end dates in writing from the vendor, the independent support providers or the fork's maintainers. Ask for the exit path in the contract, including data export and the migration tooling available if you later move to another engine. Operaton's governance is still forming and it plans a non-profit to manage key decisions, so ask how decisions and maintainer continuity will be handled. The step closes with a signed support document and a named owner for each renewal date. (Fork-specific, with shared exit questions.)
Questions buyers ask before choosing a Camunda 7 path
What does it cost to stay on Camunda 7 Enterprise compared with a fork?
Camunda 7 Enterprise is a paid subscription from Camunda, while Operaton has no commercial edition and CIB seven offers free Community and paid Community+, LTS and Enterprise editions. The recurring cost on the Camunda path is the subscription itself. On the fork paths, the license is free, so the cost is the support you choose to buy, the people who run the platform, and the upgrade work. Ask Camunda for its subscription terms in writing, and ask CIB seven which edition covers your environment and what it includes. Compare quotes on the same scope: production support, patch delivery, the database and runtime versions you run, and the hours your team needs to operate the platform.
How long does a migration from Camunda 7.24 take, and what drives it?
The duration depends mostly on the path you choose and on what your process applications contain. Moving to Operaton is designed to keep the REST API, database schema and deployable BPMN and DMN models, and it offers an OpenRewrite recipe for migrating from Camunda 7. CIB seven documents an OpenRewrite-based script that updates Maven versions, artifact names and imports, and it notes that projects on older Camunda versions must first update to the matching baseline. The drivers are the number of applications, custom scripts or classes that reference org.camunda packages, the database and Java versions you must move to, and your test coverage. No timeline is supplied here, so ask the vendor or a partner for an estimate based on an inventory of your applications.
Can an in-house team run Operaton or CIB seven without a partner?
Yes, a capable in-house team can run either fork, but the answer depends on the support you need and the skills you have. Operaton is maintained by an open-source community with no single company in control, and its repository points to professional support from several independent service providers. CIB seven is backed by CIB software GmbH, which offers paid LTS and Enterprise editions with security patches and hotfixes. Your team will still need to own database administration, Java runtime upgrades, deployment on Docker or Kubernetes, and incident response. Check whether your staff can handle these tasks on your own schedule and whether your audit or regulatory commitments require a contracted support path.
How often does each path require upgrades?
Each path sets a different upgrade rhythm, and that rhythm drives your operating load. Operaton ships feature releases in April and October with monthly patch releases, and each major or minor version is supported for six months until the next one ships, with no traditional LTS line. That means you must plan to upgrade roughly twice a year to stay supported. CIB seven's paid distributions receive security patches and hotfixes every four to eight weeks, and its LTS edition is recommended for high-volume or regulated environments. Camunda 7 Enterprise keeps 7.24 as a long-term support release with updates twice a year, in April and October, through April 9, 2030, with paid extended support through April 2032. Confirm the exact support terms for your edition before you commit.
Is Camunda 8 a required exit from Camunda 7?
No. Camunda 8 is one option, not a requirement. Camunda 7 Enterprise is supported to April 2030, and both Operaton and CIB seven keep the Camunda 7 API and database schema, so you can stay on a compatible path without moving to Zeebe. Camunda 8 changes the architecture and the licensing: its Zeebe, Operate and Tasklist source files fall under the Camunda License 1.0, which limits use to non-production environments unless you hold a commercial license. If you later decide to move, Camunda's Diagram Converter analyzes Camunda 7 BPMN, DMN and form files and lists migration tasks. Staying on a fork keeps that decision open and gives you time to evaluate it, but it does not remove the eventual cost of moving.
What does a fixed-scope engagement need from our side?
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. To scope a migration or platform implementation, DeployOpen needs an inventory of your process applications, the BPMN, DMN and form files, custom Java classes and scripts, the database and Java versions in use, and the environments where the platform runs, including any air-gapped or regulated constraints. You also need named owners for approvals, test data and cutover decisions. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope, so the more complete your inventory, the more precise the quote.
What should we check before choosing a fork's edition or support level?
Start with the platform versions your applications need, then compare the support terms in writing. Confirm that the target fork supports your Java runtime, your database version and your application server or framework, since Operaton 2.1 requires Java 17 and CIB seven 2.2 lists Java 17 and 21. Check the minimum database versions against your current estate, because the supported lists differ between the two forks. Ask each provider how security fixes are delivered, how long a release line is supported, and what happens to your deployment if you fall behind the current release. Document these answers so your architecture, compliance and procurement reviews work from the same facts.
Which exit path each option leaves open
The three options leave different exits open, and the difference matters most if you expect to leave Camunda 7 again within a few years. Camunda 7 Enterprise keeps the 7.24 line supported until April 9, 2030, and its exit is Camunda 8, which runs on a different engine (Zeebe) under the Camunda License 1.0. Camunda's Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, lists migration tasks and converts them to the Camunda 8 format, and an AI agent skill orchestrates the wider migration. Treat that tooling as a starting inventory, not a finished migration: Camunda 8 production use requires a commercial license, and the work of rewriting Java delegates, listeners and API calls sits with your team. Ask Camunda what it will export from your 7.24 engine, in which format, and how it supports active process instances and history during cutover.
Operaton and CIB seven both keep the 7.24 database schema and API, so the exit they leave open is a later move on the same data. Operaton states that its REST API, database schema and deployable BPMN and DMN models are compatible with Camunda 7 CE, and it publishes an OpenRewrite recipe for the migration. CIB seven migrates from its documented Camunda 7.23 and 7.24 baselines, changes org.camunda imports to org.cibseven and the Liquibase changelog path, and warns that stored objects such as script tasks or variables referencing org.camunda classes are not renamed automatically. Either fork can therefore return to Camunda 7 or move to another engine, but the stored data is what you must check. Before committing, confirm with each fork how it handles database export, and whether a future Camunda 7 Enterprise migration path is supported from it.
Support continuity is the exit risk that vendor documentation does not settle. Operaton is community governed with no single company in control, and it supports each release for six months with no LTS line, so you must plan a regular upgrade cadence or accept a period on an unsupported release. CIB seven's paid LTS and Enterprise editions depend on CIB software GmbH, and the FAQ gives no fixed support duration per edition, so ask for the written support end date and the escalation path before you sign. For each option, confirm in writing: the export format for process definitions and history, the last date you can receive security patches, the Java and database versions your environment will need when you leave, and whether the vendor will assist with a data export if the fork is discontinued.
How DeployOpen helps choose and implement a Camunda 7 path
DeployOpen starts by confirming which Camunda 7 path fits your process estate, support obligations and exit options, then plans the work in writing before any change is made. We plan, implement, customize, integrate, harden, back up, upgrade, document and support self-hosted open-source platforms inside your own infrastructure, so the choice between staying on Camunda 7 Enterprise, Operaton and CIB seven is tested against your environment.
How we scope
- Inventory your Camunda 7 process applications, BPMN, DMN and CMMN models, custom code and database vendor before choosing a path.
- Confirm your current Camunda 7 baseline, such as 7.24, and which Java, database and application server versions you run.
- Agree the scope in writing, covering deliverables, timelines and the exit path you want to keep open.
How we build
- Run a trial migration of a representative process application into a non-production environment on the chosen fork.
- Check API calls, Java imports, scripts and stored objects that still reference org.camunda classes after the move.
- Test process behavior, upgrades and rollback against the database and runtime your team will actually operate.
How we hand over
- Document the chosen path, the migration steps taken, configuration decisions and known gaps for your engineers.
- Provide runbooks for upgrades, patching, backups and restores tied to the vendor or community release cadence you selected.
- Walk your platform and security teams through the evidence and controls that support your internal review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial engagement.
- Confirm with each support provider which release lines, patch windows and extended support terms apply to your edition.
- Revisit the path when the vendor or community publishes a new release line, so the exit option stays documented.
