Camunda 7 CE end of life: what teams still running it must decide
If your production workloads still run on Camunda 7 Community Edition, the constraint is simple: no further releases or security patches follow 7.24, which was scheduled for October 14, 2025, and the repository was archived on November 4, 2025. The realistic paths are four. You can license Camunda 8 under an Enterprise agreement, stay on Camunda 7 Enterprise, whose end of life was extended to April 9, 2030 with paid extended support through April 2032, or move to an Apache-2.0 option such as Operaton or CIB seven, or to Flowable. The choice turns on three things: how much of your Java code and Camunda APIs you can change, whether your database schema can stay put, and what kind of support contract your security and audit teams will accept.
Start with the code and database inventory before you compare prices. Count the Java delegates, listeners, scripts, custom forms and REST clients that depend on the org.camunda namespace, and list the database platform and version behind the engine. Operaton keeps the Camunda 7 REST API, database schema and deployable BPMN and DMN models, so it is the lowest-change path for an embedded engine. CIB seven also stays in the embedded model but changes Java imports to org.cibseven and requires you to first match the Camunda baseline version. Camunda 8 replaces the engine with a remote Zeebe cluster, which is a re-platform rather than an upgrade. Confirm each fork's current supported database and Java versions against its own documentation, since they differ from your present stack.
What the end of Camunda 7 CE requires you to keep running safely
Camunda 7 Community Edition no longer receives releases or security patches, so every option on this page has to be judged on the same four points: a supported engine, a compatible database schema, a Java runtime the engine supports, and a license that allows production use. The cards below set out what each point means and what to verify before you commit.
A supported engine with security patches
After 7.24, Camunda 7 CE gets no further releases or security patches, so a team that stays put carries that risk alone. Check each option's release cadence and patch policy in writing. Operaton ships half-yearly feature releases with monthly patches, but each version is supported only until the next one ships, so you must plan for regular upgrades. CIB seven's paid LTS and Enterprise editions carry security patches and hotfixes every 4 to 8 weeks, and the vendor's FAQ does not state a fixed support duration per edition, so ask for it.
A compatible database schema
Your running process instances, history and custom tables sit in the engine schema, so the schema decides how much code and data must change. Operaton keeps database schema version 7.24 and states full API compatibility with Camunda 7 CE 7.24, which means a move does not start with a data rewrite. CIB seven's migration guide says objects already stored in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically. Inventory those stored artifacts before you choose a path.
A Java runtime the option supports
Each engine lists the Java versions and application servers it is tested on, and a mismatch will block an upgrade even when the engine itself is sound. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. CIB seven 2.2 lists Java 17 and 21 with Apache Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0. Confirm your application server, JDK and any frameworks against the current matrix, and check whether your build and dependency tooling already runs on a supported version.
A license that fits production use
Camunda 8 Self-Managed in production requires a purchased Enterprise Edition, and the Camunda License 1.0 limits use to non-production environments without one. Operaton is Apache-2.0 and states it has no open-core model and no commercial editions, though its governance is still forming. CIB seven's source is Apache-2.0 and its FAQ says the core functions may be used free of charge in commercial software. Have counsel confirm the license text for the exact artifacts you deploy, including any paid distributions, support contracts or add-ons.
A migration path for running instances
Data Migrator moves Camunda 7 instances to Camunda 8 with state preserved, but runtime migration is production ready only from Camunda 8.8 and history migration is experimental. Flowable describes in-place migration of Camunda 7 data, including history, and offers a free LEAP assessment to report the work ahead of time. Operaton and CIB seven avoid the re-platform by keeping the engine model. Ask each vendor which instances, history and custom code your environment would carry across, and test with a copy of production data.
How Camunda 8, Camunda 7 Enterprise, Operaton, CIB seven and Flowable compare
This table compares the five paths open to a Camunda 7 Community team on licensing, code and database impact, and support. Read each row as a question to put to the vendor, since terms can change and the figures here reflect the published sources at the time of writing. The main takeaway is that the licensing and support models differ far more than the engines do, so confirm current terms before you commit.
| Option | Patch and licensing position | Code and database impact | Support model |
|---|---|---|---|
| Camunda 8 Self-Managed | Core components are source-available under the Camunda License v1 from 8.6. Production use requires a Self-Managed Enterprise Edition license; the non-production license covers development and testing only. | Moves to a remote Zeebe engine with BPMN and DMN models. Embedded Java delegates and JUEL expressions are dropped, and Camunda 7 instances need the Data Migrator. | Commercial support under the Enterprise subscription. Confirm the scope and terms directly with Camunda. |
| Camunda 8 SaaS | Camunda operates the platform, so the production use question is answered through the commercial agreement. Confirm the terms and data location with Camunda. | Same remote engine model and migration path as Self-Managed. Your team does not run the cluster. | Provided by Camunda under its commercial agreement. Confirm service levels in writing. |
| Camunda 7 Enterprise | Enterprise end of life extended to April 9, 2030, per Camunda's February 2025 announcement. Patches continue on the long-term support line, with paid extended support from April 2030 through April 2032. | No code or database change needed in the short term, so this is the lowest-change path. Each later move still needs a plan. | Paid by subscription from Camunda. Ask for the patch cadence and the fee for extended support. |
| Operaton | Apache-2.0 fork of the Camunda 7 CE codebase. No open-core model and no commercial editions. Governance is still forming, and a non-profit organization is planned. | Fully compatible REST API, database schema and deployable BPMN and DMN models, with an OpenRewrite recipe for migration. Java 17 is required. | No vendor support. Professional support comes from multiple independent service providers. Releases are half-yearly with monthly patches and no LTS line, so plan upgrades every six months. |
| CIB seven | Apache-2.0 source. The Community edition is free, and paid Community+, LTS and Enterprise editions add security patches and hotfixes every 4 to 8 weeks. | Changes imports from org.camunda to org.cibseven and the Liquibase path. Stored scripts and variables referencing org.camunda classes need manual fixes. | Community is unsupported. Paid editions come from CIB software, and the FAQ recommends LTS for regulated or high-volume use. Ask for the support window per edition. |
| Flowable | Apache-2.0 Java engine supporting BPMN, CMMN and DMN. Commercial editions are also sold by Flowable, so confirm which features sit in each edition. | Can run embedded or standalone with REST APIs. Flowable says Camunda 7 data, including running instances and history, can migrate in place, and offers the LEAP assessment to plan the work. | Commercial support is available from Flowable. The community engine has no vendor SLA, so ask for the support terms in writing. |
Re-platform to Camunda 8 or keep the Camunda 7 model?
This path fits teams that want a centrally operated orchestration service, a vendor-supported roadmap and BPMN models that business analysts can review in one shared environment. Camunda 8 runs the process engine as a remote cluster, so the application talks to it through job workers and APIs instead of calling an engine embedded in its own process. From Camunda 8.6, the core components (Zeebe, Operate, Tasklist, Identity and Optimize) are under the Camunda License v1, and the Camunda documentation states that production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. The Camunda Self-Managed Non-Production license covers development and testing only.
- Production licensing: Budget for an Enterprise license before go-live. Confirm the scope, term and what it includes with Camunda.
- Kubernetes operating model: Zeebe is a cluster you run on Kubernetes, with its own storage, upgrades and monitoring.
- Worker code changes: Camunda 7 Java delegates and JUEL expressions need to become job workers or other patterns.
- Data Migrator: Runtime migration of running instances is production ready from 8.8, while history migration is experimental.
- Skills and ownership: Name who operates the cluster after launch.
Ask Camunda and your integrator which Camunda 8 version your roadmap targets and what the Enterprise license covers before you commit.
This path fits organizations with large Java applications that embed the process engine, call it in the same transaction as their own database work, and rely on JUEL expressions and Java delegates. Camunda 8 drops embedded mode, so moving these applications means redesigning transaction boundaries, rewriting delegates and testing every expression. Operaton keeps the Camunda 7 API, database schema and deployable BPMN and DMN models, and CIB seven states that it is an embedded Java engine built on the Camunda 7 Community Edition baseline. Flowable also offers an embedded mode, which is a different engine with its own migration path.
- Transaction behavior: An embedded engine shares the application's transaction, which a remote cluster does not.
- Delegate rewrite scope: Count Java delegates, listeners and JUEL expressions before estimating the work.
- Schema and database support: Operaton 2.1 keeps database schema version 7.24 and lists minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 versions.
- Support path: Operaton relies on multiple independent service providers, while CIB seven offers paid LTS and Enterprise editions.
- Java runtime: Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25.
Before choosing a fork, run your own test suite against a candidate engine and confirm which scripting and reflection behavior your applications rely on.
This path fits teams that cannot move production in the near term but need to stop depending on an unsupported Community Edition. Camunda 7 CE received its last feature release, 7.24, on October 14, 2025, with no further releases or security patches afterward. A bridge means moving to a fork that keeps the Camunda 7 model with minimal code change, then planning the longer decision with less pressure. Camunda 7 Enterprise is another bridge, with its end of life extended to April 9, 2030 and paid extended support from April 2030 through April 2032.
- Enterprise bridge: Camunda 7 Enterprise has a stated end of life date, which makes it a fixed-length option.
- Fork bridge: Operaton and CIB seven both start from the Camunda 7 code, so the change set is smaller than a re-platform.
- Release cadence: Operaton ships half-yearly feature releases with monthly patches and no LTS line, so plan upgrades as recurring work.
- Security exposure: The Community Edition gets no patches, so any bridge needs a dated plan to leave it.
- Exit cost: A bridge still needs a second migration later, so price both steps.
Ask each vendor or fork maintainer for its support window and patch commitments in writing before you sign a bridge plan.
How to move a Camunda 7 CE estate onto a supported, self-hosted engine
This sequence turns an unsupported Camunda 7 Community Edition estate into a documented, tested deployment on a fork that still receives patches, with the target chosen and the migration work known before any code changes.
Inventory custom code, scripts and database objects
The engineering lead and a database administrator list every Java delegate, listener, plugin, custom REST client, script task, form, Liquibase changelog and stored script or variable that references org.camunda classes. Export the list of deployed BPMN and DMN files and the database schema version in use. This inventory is the baseline for every later step, and it is done when each item has an owner and a note on whether it must change, be replaced or be retired.
Choose the target engine and license path
Decide between Camunda 8 with a Self-Managed Enterprise license, staying on Camunda 7 Enterprise, or a Camunda 7 fork such as Operaton or CIB seven. Camunda 8 is a different architecture with a remote engine, so it is a re-platform rather than a dependency swap. Confirm the Camunda License terms for production and the support windows with each vendor in writing. The output is a signed decision record that names the target and the reasons for it.
Match the Camunda baseline version
If the target is CIB seven, first update the estate to the Camunda baseline that the target release is built on, as its migration guide requires. The CIB seven 2.1 backend is based on Camunda 7.24.0, so estates on older Camunda versions must move to the matching baseline first. Run the existing test suite on the baseline and fix failures before any namespace change. Done means the application runs and passes its tests on the matching Camunda baseline.
Run the OpenRewrite migration recipe
For Operaton, apply the migrate-from-camunda OpenRewrite recipe published by the Operaton project. For CIB seven, run its OpenRewrite-based script, which updates Maven versions, artifact names and Java imports. Review the diff in version control rather than accepting it wholesale, because custom code in the inventory may need manual edits. Done means the project compiles against the target artifacts and the diff has been reviewed line by line.
Rename Liquibase paths and fix stored references
For CIB seven, change the Liquibase changelog path from org/camunda to org/cibseven. Then fix objects already in the database that still reference org.camunda classes, such as script tasks and variables, because the migration does not rename them automatically. Where needed, consider the namespace compatibility properties for scripting and reflection, which are disabled by default, and plan their removal once references are fixed. Done means a query of stored definitions and variables returns no org.camunda references you have not accounted for.
Test on supported database and Java versions
Build a test environment that matches the production database engine and version, the Java version and the application server. The Operaton 2.1 release notes list Java 17, 21 and 25 and minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4. The CIB seven 2.2 page lists Java 17 and 21 with PostgreSQL 15 to 18. Run restored production data through upgrade, in-flight instance and history tests. Done means the test report is signed by the business owner and the database versions match the vendor's supported list.
Deploy on Docker or Kubernetes
Package the engine and application as container images and deploy them with Docker or Kubernetes. Operaton publishes official Docker images and Helm charts, while CIB seven lists Docker and Kubernetes setups with Helm charts still in preparation, so confirm the current chart status before you plan around it. Keep the database, secrets and ingress in your own infrastructure and record the deployment in infrastructure as code. Done means the staging deployment reproduces the test results and the runbook is stored with the code.
Set a patch and upgrade routine
Agree a written routine for security patches, minor upgrades and deprecation checks with whoever will own the engine after go-live. Operaton's stated cadence is half-yearly feature releases with monthly patches and six months of support per version, with no traditional LTS line, so plan upgrades accordingly. CIB seven's paid editions say patches come every four to eight weeks, and its LTS edition is recommended for regulated environments. Confirm support terms and who answers a security incident before go-live. Done means the routine is in the operations calendar with named owners.
Questions buyers ask before choosing a Camunda 7 successor
What does it cost to move off Camunda 7 Community Edition?
The cost is driven by components rather than a single license fee. Camunda 7 CE is Apache-2.0, so the engine itself carries no license charge, but the successor path decides who gets paid. Moving to Camunda 8 for production means a Self-Managed Enterprise license under the Camunda License v1, which is quoted by Camunda. Staying on a fork means choosing between community support and paid editions from CIB seven or independent support providers for Operaton. Recurring items include support contracts, infrastructure, patching and Java and database upgrades. One-time items include migration analysis, code changes and testing. Ask each vendor or provider for a written quote that separates these lines, and confirm what the support contract covers.
How long does a Camunda 7 migration take?
The timeline depends on the number of applications, custom code, Camunda-specific plugins, stored scripts and the database used, and no supplied source gives a standard duration. For a fork, the main steps are matching the Camunda baseline, running the migration tooling for imports and artifacts, and fixing references that are not renamed automatically. For Camunda 8, the work includes model conversion, rewriting Java delegates into job workers and replacing the Camunda 7 web applications. Camunda documents runtime migration with the Data Migrator as production ready from Camunda 8.8, while history migration is experimental, so plan history handling separately. Run a scoping assessment on a representative application before agreeing on a date.
What does the migration need from our internal team?
Expect the work to need developers who know your Camunda 7 code, a database administrator for schema and data work, and an operations owner for the new runtime. For Camunda 8, you also need Kubernetes skills and an exporter strategy for history. For a fork, the team must be ready to change Java imports from org.camunda to the new namespace and rename the Liquibase changelog path. Business analysts or process owners should confirm that models still behave as expected. Testing ownership should be agreed early, including regression tests for every process that has running instances. Ask the implementation partner to list these roles in the written scope so gaps are visible before work starts.
Can our internal team run the migration without outside help?
Yes, many teams do this in-house, especially when the codebase is small and the team has Camunda 7 experience. The fork route is usually the lower-effort path for embedded Java applications because Operaton keeps a compatible REST API, database schema and deployable BPMN and DMN models, and CIB seven provides an OpenRewrite-based script. The Camunda 8 route involves more new architecture, so the skill gap is larger. Be realistic about the testing and production cutover work, which often takes longer than the code changes. An outside team can take on defined parts, such as the assessment, data migration or hardening, under a written scope while your staff keep ownership of the business logic.
Can running process instances move to the new platform?
Running instances can move in some paths, but the answer depends on the target. Camunda documents runtime migration with the Data Migrator as production ready from Camunda 8.8, and copies running Camunda 7 instances with their state preserved, while history migration remains experimental. Flowable states that Camunda 7 and Activiti data can be migrated in place, including active process instances and history, and offers the free LEAP tool to report what a migration involves. Forks keep the Camunda 7 database schema, so instances usually stay where they are. Whatever route you choose, test in-flight instances against the target version and agree a rollback plan before cutover.
How do we judge the governance of an open-source fork?
Look at who controls releases, how decisions are made and what commercial support exists. Operaton states that it has no single company in control, that governance is still forming, and that a non-profit organization is planned. It has no open-core model and no commercial editions, with support from several independent providers. CIB seven is a key strategic product of CIB software GmbH, which provides paid Community+, LTS and Enterprise editions with security patches and hotfixes every 4 to 8 weeks for paid distributions. Check release cadence, the support window for each version, the patch process for security issues and whether a provider would take responsibility for your version. Ask for these commitments in writing.
Can DeployOpen run the migration under a fixed-scope written agreement?
Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A migration assessment, the code and data work, test support, and hardening can each be a defined scope item. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so request a quote based on your written scope, which should list applications, databases, Camunda plugins, in-flight instances and acceptance criteria. DeployOpen does not issue audit reports or certifications.
Evidence auditors and security reviewers ask for after the migration
Auditors and security reviewers rarely accept a statement that the platform is supported. They want dated records that show which engine runs where, under which license, on which database and Java versions, and who patches it. The six items below are what to collect whichever path you choose, whether Camunda 8, Camunda 7 Enterprise, Operaton, CIB seven or Flowable.
Engine version and patch inventory
List every running engine, its exact version, the environment it runs in and the date of its last patch. For Camunda 7 Community, the last feature release was 7.24, scheduled for October 14, 2025, and no security patches follow it. Record which deployments still run that version, because each one now has a known end date for fixes. Keep the inventory current as part of change control, not as a one-off spreadsheet.
License position for each component
Write down the license of every component you ship, not only the platform. Camunda 8 Self-Managed source for Zeebe, Operate, Tasklist, Identity and Optimize falls under the Camunda License v1 from 8.6, and production use needs an Enterprise license. Operaton and Flowable core engines are Apache-2.0, while CIB seven core functions are Apache-2.0 with paid editions for LTS and support. Confirm each license with the vendor and keep the file or link on record.
Database and Java version matrix
Document the database, its version and the Java runtime for each environment, and compare them against the vendor's supported environments page. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, with minimum PostgreSQL 14, MariaDB 10.11 and MySQL 8.4. CIB seven 2.2 lists Java 17 and 21 with different database and application server versions. Mark any combination that falls outside the list as a risk to resolve before go-live.
Change records for code and schema work
Keep a record of each automated change, including the OpenRewrite recipe run, the Maven artifact and import changes, and any Liquibase changelog path renamed. Operaton keeps the Camunda 7 database schema, but CIB seven changes the Java namespace from org.camunda to org.cibseven and moves the changelog path. Record stored script tasks and variables that still reference old class names, since those are not renamed automatically and can fail at runtime.
Test results for migrated instances
Show that running and completed process instances behave the same after the move. Collect the test plan, the instances sampled from production, and the results of replaying them on the target engine, including timers, message correlations and external task retries. If you move to Camunda 8, record which instances used the Data Migrator runtime path, since Camunda documents runtime migration as production ready from 8.8 while history migration is experimental. Keep signed test sign-offs with the change records.
Patch and support contract on file
Store the signed support agreement for the platform you run, with its patch cadence, severity response terms and end-of-life date. Camunda 7 Enterprise end of life moved to April 9, 2030, with paid extended support from April 2030 through April 2032. Operaton ships monthly patches with each release supported for six months and no LTS line, so it depends on your own upgrade cycle. CIB seven paid editions release security patches every 4 to 8 weeks, but the FAQ gives no fixed support duration per edition, so ask for it in writing.
What changes for your developers and operators
The first decision for developers is whether the process engine stays inside your application. Camunda 7 runs as a Java engine that persists to a relational database through MyBatis, and its REST APIs, Java delegates and embedded deployment model are what most Camunda 7 code depends on. Operaton is built from the Camunda 7 codebase and states a fully compatible REST API, database schema and deployable BPMN and DMN models, so the existing Java delegates and the engine's embedded mode carry over with the least change. CIB seven is also a native BPMN 2.0 engine running inside the Java Virtual Machine, but its migration changes Java imports from org.camunda to org.cibseven and the Liquibase changelog path, and stored script tasks or variables that reference org.camunda classes are not renamed automatically. Your team should search the database and the codebase for those references before choosing a fork. Moving to Camunda 8 changes the operating model more than the code. The engine becomes a remote Zeebe cluster on Kubernetes, so application teams own job workers, network paths, cluster sizing and upgrades. Operators who run Camunda 7 today on a shared relational database need to confirm whether they have the skills and monitoring for a distributed cluster, and whether the Camunda 8 licensing terms for production are acceptable before they start that work.
Operations differ most in the user interfaces and the release rhythm. CIB seven ships its own task list, process monitoring and user and rights management from version 2.0, so teams that rely on Tasklist, Cockpit and Admin need to plan how those screens are replaced or retained. Operaton ships feature releases in April and October with monthly patch releases, and each version receives support for six months until the next one ships, with no traditional LTS line. That cadence means an Operaton deployment needs a standing upgrade routine. CIB seven offers paid LTS and Enterprise editions with security patches released every 4 to 8 weeks, so the support window and patch cadence should be confirmed in writing before you commit. Ask each vendor for its supported database versions and Java versions, then test your own workload on them.
How DeployOpen moves Camunda 7 workloads onto a self-hosted engine
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Camunda 7 Community Edition end of life, that means working through the engine choice, the database and the application code in your environment, with the work agreed in writing before it starts.
How we scope
- Inventory the Camunda 7 engine version, database, BPMN, DMN and CMMN models, Java delegates and custom REST clients in use.
- Confirm which target is in view: Camunda 8 with an Enterprise license, Camunda 7 Enterprise, Operaton, CIB seven or Flowable.
- Agree the scope, deliverables and timeline in writing; engagements are fixed-scope, and ongoing support is available as a retainer.
How we build
- Stand up the chosen engine in your own infrastructure, including database, application server and Kubernetes or Java runtime where needed.
- Port application code, scripts and stored variables that still reference org.camunda classes, and test them against your processes.
- Run the engine's migration tooling in a non-production copy, then verify running instances and history before any cutover.
How we hand over
- Document the target architecture, configuration, upgrade path and the rollback steps for the cutover window.
- Provide hardening and backup and recovery setup, with evidence that supports your own internal or compliance review.
- Hand over runbooks and train your operators so the platform is run by your team after the engagement closes.
How we support
- Offer retainers covering upgrades, patch application, monitoring follow-up and continuous security testing as agreed in scope.
- Track each engine's release and support window so your team plans upgrades before a version leaves support.
- Ask any independent auditor or certification body for their own assessment; DeployOpen prepares systems and evidence but does not issue attestations.
