Camunda 8 vs CIB seven: which to choose

Camunda 8 vs CIB seven: which fits your Camunda estate

If your renewal, licensing change after Camunda 8.6, or Camunda 7 end of life is forcing a decision, start with the architecture you want to keep. Camunda 8 fits teams choosing a remote Zeebe platform with an Enterprise license for production, while CIB seven fits teams that want to keep an embedded Java engine running inside their own applications. The two paths lead to very different work, so the choice should be made before any migration plan is written. Camunda 8 Self-Managed may run without a commercial license only for non-production purposes under the Camunda Self-Managed Non-Production license, so production use means buying the Self-Managed Enterprise Edition. Confirm those terms with Camunda directly in the Camunda 8 Self-Managed licenses documentation before you commit.

The decision turns on three questions. First, how large is your current Camunda 7 footprint? Count the BPMN models, Java delegates, custom listeners, scripts, and database schemas that depend on the engine. A small estate with few embedded calls may move to a new platform with modest code rework, while a large estate built around in-process transactions usually favors a fork that keeps the same programming model. Second, what does production licensing cost you in both paths? CIB seven's Community edition is Apache-2.0 licensed and free for commercial software at least for its core functions, but its paid Community+, LTS and Enterprise editions add security patches and hotfixes, and the vendor's FAQ recommends LTS for high-volume or regulated environments. Ask CIB for the current edition terms in writing. Third, how much Java engine operations can your team carry? CIB seven runs inside your JVM, so your team owns upgrades, database tuning and clustering. Camunda 8 moves that work to a Kubernetes-based cluster, which brings its own operating skills.

Which option fits which scenario

This table maps common situations to the option that usually fits better, based on licensing, engine architecture and editions. Read each row as a starting point: confirm the license terms and support scope against your own environment and with each vendor before you commit.

Scenario	Better fit	Reason
New BPMN program with no Camunda history	Camunda 8	Camunda 8 is built around Zeebe on Kubernetes and includes Operate and Tasklist. CIB seven is a Camunda 7 fork with an embedded engine, so it adds little if you have no Camunda 7 code to keep. Note that production self-managed use of Camunda 8.6 and later requires an Enterprise license.
Camunda 7 application with embedded Java delegates	CIB seven	CIB seven keeps the embedded JVM engine, Java delegates and the Camunda 7 data model, with an OpenRewrite script for imports and artifacts. Camunda 8 runs the engine remotely, so delegates would need rework.
Team with strong Kubernetes operations skill	Camunda 8 (with an Enterprise license)	Self-managed Camunda 8 is designed for Kubernetes deployment. CIB seven also supports Docker and Kubernetes, with Helm charts still in preparation, so confirm the chart status before relying on it.
Regulated buyer that requires paid long-term support	CIB seven LTS or Enterprise	CIB seven's FAQ recommends the LTS edition for high-volume or regulated environments and describes security patches every 4 to 8 weeks. Ask CIB for the support duration per edition, since the FAQ does not state one.
Team that needs production use without a Camunda license	CIB seven (Apache-2.0)	CIB seven's source is Apache-2.0 and its FAQ says the core may be used free of charge in commercial software. Camunda 8 production use needs a commercial Camunda license under the Camunda License 1.0 terms.
Team that wants a BPMN engine with embedded mode and an Apache-2.0 base	CIB seven or Operaton	Both keep the in-process Java model from Camunda 7. Choose CIB seven if you want its own user interface and paid LTS options, and Operaton if you want a community-governed fork.
Team that depends on Camunda Tasklist and Cockpit	Camunda 8 or a fork that ships its own UI	Camunda 8 includes Operate and Tasklist. CIB seven ships its own task list, monitoring and user management UI from version 2.0, so review its features against your current Camunda 7 usage.

How a remote Zeebe cluster differs from an embedded Java engine

Camunda 8 runs process execution in a separate Zeebe cluster that your applications reach over the network, while CIB seven runs its BPMN engine inside the same Java Virtual Machine as your application. That single architectural difference changes who operates the engine, where transaction boundaries sit, and how you find out what went wrong. In Camunda 8, your code does not call the engine directly. It registers job workers that poll or stream jobs from the cluster, completes them, and reports failures back. In CIB seven, the engine is a library: a service task can call a Java delegate in the same thread, and that call can commit or roll back in the same database transaction as your own service code.

For operations, the difference is in what you run. A Camunda 8 Self-Managed deployment is a set of components on Kubernetes, including the Zeebe broker cluster, Operate, Tasklist and Identity, with their own storage, upgrades and monitoring. Your application team owns the workers, their scaling and their retry behavior, while the platform team owns the cluster. With CIB seven, the engine ships in your application's deployable and its database schema lives beside your application's tables. Scaling means running more application instances against the same database, and capacity planning focuses on that database. Confirm with your architects which team will own each part before you compare the two platforms on cost.

Debugging also changes shape. In an embedded engine, a failed delegate usually shows up as a stack trace in the application log, and it can be reproduced in a unit test that runs the engine in-process. Camunda 8 moves that investigation to the cluster's exported history and to the worker logs, so you need to correlate job keys, process instance keys and worker logs across systems. Embedded delegates and JUEL expressions are not part of Camunda 8: expression-based logic and Java delegate classes from a Camunda 7 model must be rewritten as job workers or connectors before they run. Before committing to either path, list every delegate, listener and expression in your current models and decide whether each one is an in-process call that depends on shared transactions.

Where data lives and who operates the platform

Camunda 8 and CIB seven differ less in features than in who runs the engine, where process data sits and who answers for backups and evidence. The cards below cover the questions a buyer should settle before comparing costs, so the operating model is clear from the start.

Data location in self-managed deployments

With Camunda 8 Self-Managed, Zeebe, Operate, Tasklist and their supporting stores run in your Kubernetes clusters, so process variables and history stay where you place them. CIB seven runs inside your own Java applications, so its engine state lives in the relational database your application already uses. Confirm which data classes (variables, audit history, documents, user records) each option writes, and where backups of each copy are kept.

Hosting model and operator

Camunda 8 is offered as Camunda SaaS or Self-Managed on Kubernetes, and the Self-Managed path makes your team responsible for the cluster, the storage and the upgrades. CIB seven has no vendor-hosted option: the engine is a library or service in your application, deployed on Spring Boot, Quarkus, Docker or Kubernetes, and your delivery team operates it. Decide who will own the runtime on call before you choose.

Identity integration

Camunda 8 manages users, groups and roles through its Identity component and connects them to your identity provider using OIDC, while Operate and Tasklist depend on that configuration. CIB seven ships its own interface for task lists, monitoring and user and rights management, independent of the Camunda web applications. Check how each option maps your directory groups to process permissions, and how leavers are removed from running tasks.

Audit and compliance evidence

A regulated buyer must produce evidence of who changed a process model, who acted on a task and when, and this trail must survive an audit. Camunda 8 keeps history through exporters to Elasticsearch, OpenSearch or a relational database that you operate, and CIB seven records history in its database tables. Neither option certifies your controls, so ask an independent assessor which logs, retention periods and access reviews will be tested.

Database and backup responsibility

In a Self-Managed Camunda 8 cluster, your team owns the backup and restore plan for Zeebe data, the exporter stores and the Identity database. With CIB seven, the backup of the process database is usually part of the application's existing database operations, which covers engine tables, history and the CIB seven user tables together. Agree the recovery point and recovery time targets in writing, then test a restore of running instances.

What licensing means for development, testing and production

Development, testing and evaluation are where Camunda 8 Self-Managed is most accessible. The Camunda Self-Managed Non-Production license allows the software to run without a commercial license for these purposes, and the Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation. The boundary is the environment, not the team, so a staging system that carries real customer data or serves business users is a question to settle with Camunda before it goes live.

Permitted scope: development, testing and evaluation environments run without a production license.
Environment boundary: the license turns on whether the system is production, so classify each environment in writing.
Pilot systems: a pilot that business users depend on may count as production, so confirm this with Camunda first.
CIB seven on non-production: the Apache-2.0 core carries no such restriction, so teams can build and test freely on the Community edition.
Evaluation of paid editions: trial access to paid CIB seven editions should be confirmed directly with CIB software.

Ask Camunda and CIB software to confirm in writing which environments each license covers before you provision them.

What each option costs to own, component by component

Total cost depends less on the license line than on who carries each component: the subscription, the edition, the hosting, the operations, the upgrades and the code changes. The cards below separate one-time migration effort from costs that recur every year, so you can ask each vendor and partner for the same breakdown.

Camunda 8 subscription or SaaS fees

Running Camunda 8 in production requires a commercial agreement. Camunda's licensing documentation says production use of Self-Managed requires the Enterprise Edition, and the Camunda License 1.0 limits use to non-production environments without a commercial license. The fee is recurring, so it grows with the contract term and the scope you negotiate. Ask for the price basis in writing, whether it covers SaaS or Self-Managed, which components are included, and what happens to production rights if you stop renewing.

CIB seven edition and support

CIB seven's core is Apache-2.0 licensed and free of charge for commercial use, at least for its core functions. The paid Community+, LTS and Enterprise editions add security patches and hotfixes, which CIB releases every 4 to 8 weeks, with urgent fixes as needed. The FAQ recommends LTS for high-volume or regulated environments. Subscription cost is recurring, and the choice of edition is the main lever. Confirm the support duration per edition, since the FAQ does not state one.

Infrastructure and database hosting

Camunda 8 runs as a cluster of components on Kubernetes, with Elasticsearch or OpenSearch as a dependency for visibility, so you pay for nodes, storage and backups in your own cloud or data center. CIB seven runs inside a Java application on a supported relational database, which usually means fewer moving parts. Both costs recur monthly. Estimate them from your peak instance volume and retention needs, and check whether your database edition is on the supported list, such as PostgreSQL 15 to 18 or Oracle 19c and 23ai.

Platform operations and monitoring

Operations covers on-call coverage, certificate and secret rotation, database maintenance, backups and restore tests, and capacity planning. Camunda 8 adds Kubernetes and the component fleet to that list, while CIB seven shifts more work onto your Java application servers such as Tomcat, JBoss EAP or WildFly. This is largely an internal staffing cost that recurs. Ask whether your team already runs these platforms, and whether a retainer for monitoring and patch support would cover the gap.

Upgrades and security patching

Each platform has its own upgrade cadence, and every cadence is a recurring cost. Camunda 8 publishes frequent patch and minor releases, and CIB seven publishes its own 2.x releases, so you must test and deploy both on your own schedule. Budget for regression testing of BPMN models, custom delegates and database changes at each step. Confirm with the vendor which versions receive security fixes and for how long, and whether those fixes need a paid edition.

Migration engineering for Camunda 7 code

This is the one-time cost for teams moving from Camunda 7. CIB seven requires you to first match the Camunda baseline (2.1 is based on 7.24.0), then run the OpenRewrite script for imports and Maven artifacts, rename the Liquibase path, and fix stored scripts and variables that still reference org.camunda classes. Effort rises with the number of custom scripts, plugins and in-flight processes. Ask a partner for a written inventory of these items before quoting, since the script alone does not fix stored objects.

What a Camunda 7 to CIB seven move involves

The sequence moves a Camunda 7 application onto CIB seven's Apache-2.0 fork in an order that keeps the Camunda baseline, build configuration, database changes and stored code consistent, so the application can be tested on a supported stack before any cutover.

Confirm the Camunda 7 baseline version
Your team checks which Camunda 7 version the application runs on and compares it with the baseline CIB seven targets: the CIB seven 2.1 backend is based on Camunda 7.24.0 and 2.0 on Camunda 7.23.0. If you are on an older Camunda 7 release, you first update to the matching Camunda baseline and test that step on its own. The output is a written baseline version and a target CIB seven release, agreed by the application owner and the engineering lead.
Run the OpenRewrite migration script
Developers run the OpenRewrite-based script that CIB seven provides in its Camunda migration guide. It updates Maven versions, artifact names and Java imports from org.camunda to org.cibseven. The output is a branch with a clean build diff that a reviewer can read, so every automated change is visible before it is merged.
Rename the Liquibase changelog path
The Liquibase changelog path changes from org/camunda to org/cibseven, so the engine's schema scripts load from the new location. Your database or platform engineer reviews the change against a copy of the production schema and confirms that no changelog entries are duplicated. The check is a successful schema upgrade run against a non-production database that matches your production engine.
Find stored scripts and variables that reference org.camunda
The migration guide warns that objects already stored in the database are not renamed automatically. Script tasks, serialized variables and other stored content that reference org.camunda classes must be found and updated, usually by querying the process definitions and variable tables and reviewing the results with the process owners. The output is a documented list of each affected object, its owner and the fix applied.
Enable namespace compatibility properties only where needed
CIB seven offers namespace compatibility properties for scripting and reflection, and they are disabled by default. Enable a property only when the inventory from the previous step shows code that still needs the old namespace, and record which property is on and why. The output is a configuration file in which each enabled setting has a named reason, so it can be removed later once the stored content has been fixed.
Test on the supported database and application server
Run the full test suite and a migration rehearsal on a combination listed in CIB seven's supported environments page, such as a supported Java version, database and Apache Tomcat, JBoss EAP or WildFly release. Confirm that deployed models run, that jobs and external tasks complete, and that the cockpit and task list behave as expected. Record the tested combination in your change record. Confirm the current support matrix in the CIB seven manual before you choose the stack, because it changes between releases.

When moving a Camunda 8 estate to CIB seven is not a simple import

Moving a Camunda 8 estate to CIB seven is a re-architecture project, not a library swap. CIB seven is a Camunda 7 fork with an embedded Java engine that persists to a relational database through MyBatis, while Camunda 8 runs its engine as a remote Zeebe cluster and executes work through job workers that poll or stream from that cluster. The Java delegates, Zeebe workers and Kubernetes-hosted cluster that carry your Camunda 8 logic have no direct counterpart in CIB seven, so each service task needs a decision: rebuild it as an in-process Java delegate, keep it as an external worker that talks to CIB seven's REST API, or retire it in favor of a different mechanism. Expression languages, connectors and variable handling also differ, so the BPMN models themselves need review after conversion.

Camunda's own tooling is aimed at the Camunda 7 to Camunda 8 direction. Its Diagram Converter analyzes Camunda 7 BPMN, DMN and form files and converts them to the Camunda 8 format, and its Data Migrator copies running Camunda 7 process instances into Camunda 8 with their state preserved. For a team starting from Camunda 8, neither tool moves work the other way. Camunda documents runtime migration as production ready with Camunda 8.8, and history migration as experimental, so Camunda 8 to CIB seven export of in-flight instances is not a supported path you can plan around. Confirm with CIB seven and your own engineers which running instances can be drained or restarted, and which must finish in Camunda 8 first.

Before any estimate, ask for a written inventory of the estate: every BPMN and DMN model, every job worker and its language, every connector, and every place where process data is read from the Zeebe exporter or Operate. Then plan a parallel run on the CIB seven stack in a non-production environment, with the supported Java and database versions listed in CIB seven's environment page. Expect the largest effort to sit in worker re-implementation and operational replacements for Operate and Tasklist, not in the diagrams. Ask for the drain plan for in-flight instances as a separate line item, because it determines the cutover window and the duration of dual running.

Questions buyers ask before choosing CIB seven or Camunda 8

What does it cost to move from Camunda 7 to CIB seven or Camunda 8?

The cost is driven by the work, not by a published price, and no supplied figure sets the total. Moving to CIB seven is mostly a change of namespace, Maven artifacts and stored objects, plus testing, so the one-time effort depends on how much custom Java, scripting and database content you have. Moving to Camunda 8 is a re-platform: BPMN models are converted with the Diagram Converter, but job workers, delegates and the remote Zeebe architecture need redesign. Recurring costs include infrastructure, a paid support plan if you need one, and staff time for upgrades. For CIB seven, ask whether a quote covers the paid Community+, LTS or Enterprise edition, and for Camunda 8, whether it covers a Self-Managed Enterprise license. Request both as separate line items in a written scope.

How long does a Camunda 7 migration take?

No supplied source gives a duration, so the timeline depends on your code base. The main variables are the number of custom Java delegates, listeners and scripts, how many stored scripts and variables reference org.camunda classes, and whether you have running instances that must finish in place. CIB seven's migration guide requires projects on older Camunda versions to first update to the matching Camunda baseline (7.23.0 for CIB seven 2.0, 7.24.0 for CIB seven 2.1), which adds a step if you are behind. Ask any provider for a written inventory of these items before agreeing a timeline, and for a test plan that covers in-flight instances.

Can our own team migrate the process engine without outside help?

Yes, a capable Java team can migrate to CIB seven, because the core change is well documented. The CIB seven manual describes an OpenRewrite-based script that updates Maven versions, artifact names and imports, and the Liquibase changelog path change is a known step. Teams with limited experience of Liquibase, database upgrades, or Camunda 8's remote architecture may find the work harder. Consider a fixed-scope engagement for the parts you have not done before, such as testing in-flight instances or redesigning workers for Camunda 8. DeployOpen plans, implements and documents this kind of work in the client's own infrastructure, with scope and deliverables agreed in writing before work starts.

What skills does the team need for a CIB seven or Camunda 8 move?

The skills depend on the target. CIB seven keeps the embedded Java model, so the team needs Java, Maven, Spring Boot or Quarkus if used, and relational database administration. The CIB seven 2.2 supported environments list Java 17 and 21 and databases including PostgreSQL 15 to 18, MySQL 8.0, MariaDB, Oracle, SQL Server and DB2. Camunda 8 adds Kubernetes and Helm for Self-Managed, plus Zeebe client work for workers, and it runs the engine as a remote cluster instead of inside your application. Confirm internally whether you have Kubernetes operators and a database team for each target before you choose.

Are CIB seven's paid support windows defined?

The supplied sources do not give a fixed support duration per CIB seven edition. The CIB seven FAQ describes paid Community+, LTS and Enterprise editions with security patches and hotfixes, and says security patches and hotfixes for the paid distributions are released every 4 to 8 weeks, with urgent fixes as needed for major security issues. It recommends the LTS edition for high-volume or regulated environments and says CIB seven Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2. Before signing, ask CIB software in writing for the support end date of each edition and the process for urgent patches.

Can Camunda 8 run in production without a license?

No. According to Camunda's licensing documentation, Camunda 8 Self-Managed may be used without a commercial license only for non-production purposes under the Camunda Self-Managed Non-Production license. From Camunda 8.6, production use of Self-Managed requires buying the Self-Managed Enterprise Edition. The Camunda License 1.0 limits use to development, testing and evaluation. Read the current terms yourself, since licensing can change between releases, and get the production entitlement in writing before you go live.

Does CIB seven still need Camunda 7 Enterprise or a Camunda license?

CIB seven is a separate Apache-2.0 project, and its FAQ says it may be used free of charge in commercial software, at least for its core functions. The free Community edition does not need a Camunda license. Paid CIB seven editions are sold by CIB software, not Camunda. Check the exact features you rely on against the Community edition, since some Camunda 7 Enterprise features arrive only in paid CIB seven editions. Ask your legal team to review the license text for any extensions you plan to use.

How DeployOpen helps evaluate, implement and migrate

DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Camunda 8 vs CIB seven, we start from your process models, your Camunda version and your licensing position, then agree the work in writing before any build starts.

How we scope

We inventory your BPMN models, Java delegates, workers, scripts and database vendor before recommending either option.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm whether your production needs fall under the Camunda 8 Enterprise license or a CIB seven edition, and document the reasoning.

How we build

We stand up CIB seven on your target runtime, such as Spring Boot or Quarkus, using the supported Java and database versions you choose.
Where you move from Camunda 7, we match the Camunda baseline, apply the migration script and check stored scripts and variables for org.camunda references.
We test process paths, retries, timers and user tasks in a staging environment that mirrors your production database.

How we hand over

You receive configuration, deployment and runbook documentation for the engine, the task list and the cockpit in your environment.
We document the cutover plan, rollback steps and how in-flight instances are handled, so your operations team can run them.
Knowledge transfer sessions cover upgrades, backups and how to apply CIB seven security patches and hotfixes in your change process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retainers can cover tracking the CIB seven patch and hotfix cadence and testing each release against your process models.
We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any formal opinion.

Camunda 8 vs CIB seven