Operaton vs CIB seven

Operaton vs CIB seven by scenario: which fork fits which team

This table maps common team profiles to the Camunda 7 fork that fits each one better, with the condition that would flip the choice. Read each row as a starting point, then confirm the support and edition details with each project before you commit.

How Operaton and CIB seven are built and deployed

Both forks start from the same Camunda 7 code and aim to run the same BPMN models, so the differences show up in what each one is pinned to, how it is packaged, and which parts of the operator experience come with it. The cards below cover the decisions that shape upgrades, runtime support and day-two work.

Operaton vs CIB seven feature by feature

This table compares the two Camunda 7 forks on license, governance, release rhythm, paid editions, compatibility, databases, Java support, user interface and identity integration. Read each row as a question to put to both projects, and treat the gaps marked for confirmation as items to verify before you commit.

What is free and what is paid in each fork

What drives the running cost of each fork

Switching between Operaton and CIB seven later

This sequence moves a Camunda 7 based deployment from one fork to the other without changing the process models themselves. Each step ends with a check that tells the team whether the move is complete or needs another pass.

1. Confirm the Camunda 7 baseline of the running system

   The platform engineering lead or the application owner records the exact Camunda 7 version the current deployment runs, along with the Java version, database engine and any custom Java delegates, listeners or scripts. This matters because CIB seven's migration guide says projects on older Camunda versions must first update to the matching Camunda baseline before migrating. Operaton 2.1 is API-compatible with Camunda 7 CE 7.24 and keeps database schema version 7.24, so the team should confirm whether its current baseline lines up with that. The step is done when the team has a written baseline document that names the source version, the target fork version and any gap that must be closed first. If the source is older than the baseline the target fork expects, the team should plan that upgrade as a separate change, and it should be confirmed with the chosen fork's documentation before work begins.

2. Run the matching migration recipe or script

   The developer responsible for the codebase runs the migration tool that matches the direction of travel. For Operaton, the project provides an OpenRewrite recipe for migrating from Camunda 7. For CIB seven, the manual describes an OpenRewrite-based migration script that updates Maven versions, artifact names and imports. Run the tool on a branch, not on the main line, and commit its output separately so that the changes can be reviewed on their own. The step is done when the build compiles against the target fork and the recipe's change report lists every file it touched. Teams moving in either direction should confirm the current recipe version and its documented scope in the relevant repository before running it.

3. Update Maven artifacts and Java imports

   The developer checks that every Maven dependency points to the target fork's coordinates and that no Camunda artifact remains on the classpath alongside the new engine. CIB seven changes Java imports from org.camunda to org.cibseven, while Operaton changes its package namespace to org.operaton. Mixed dependencies cause classloading conflicts that often surface only at runtime, so the team should run a dependency tree check as well as a compile. The step is done when the dependency tree shows only target fork artifacts, the application starts against an empty test database, and the unit and integration test suite passes. Any import that the recipe skipped should be listed in the migration ticket for manual correction.

4. Change the Liquibase changelog path

   The database owner or the developer updates the Liquibase changelog location that the engine reads at startup. CIB seven's migration guide says the path changes from org/camunda to org/cibseven, so a configuration that still points to the old path will fail or silently skip schema work. Confirm the new path against the target fork's manual before editing the configuration, and keep the change in version control with the other configuration files. The step is done when a fresh database created from scratch reaches the expected schema version and the Liquibase change log table records the target fork's changesets. Operaton is documented as keeping the Camunda 7 database schema, so teams moving to it should confirm the path and changelog expectations in its own release notes.

5. Review stored objects that reference old class names

   The engine developer and a business analyst review what the database and the process models hold, because the migration guide warns that objects already stored in the database are not renamed automatically. Typical examples include script tasks, variables that serialize org.camunda classes, and deployed definitions that refer to old listener or delegate classes. Export the list of deployed process definitions, search stored variables and script definitions for old package names, and fix each one with a tested change. The step is done when a search of the production-like database returns no references to the old namespace that the target fork cannot resolve, and each remaining reference has a documented reason. This is the step most likely to need human judgment and cannot be fully delegated to a script.

6. Decide on namespace compatibility properties

   The platform owner decides whether to enable the namespace compatibility properties that CIB seven offers for scripting and reflection. The migration guide says these properties are disabled by default, so a team that does not set them must make sure every scripting and reflection reference has been corrected in the previous step. Enabling them can keep older references working, but it also means the namespace work is deferred rather than finished, and the team should record that as a known risk with an owner and a removal plan. The step is done when the configuration file or deployment template states the decision and the reason for it, and a test run exercises a script task and a reflective lookup in the migrated environment.

7. Test, cut over and plan the reverse path

   The release manager runs the full regression suite, a performance test that reflects expected load, and a rollback rehearsal against a copy of production data before cutover. Because the namespace changes apply in both directions, the team should record the same steps in reverse, including which references were corrected and which compatibility properties were enabled. A switch later repeats the namespace work in reverse, so keeping the recipe, the change list and the review notes in version control reduces the effort of that future move. The step is done when the rehearsal completes with no open high-severity defects, the rollback procedure has been executed once, and the reverse-path runbook is stored with the migration record.

Where Camunda 7 fork migrations usually run long

Questions buyers ask before choosing Operaton or CIB seven