Flowable vs CIB seven: which to choose

Flowable vs CIB seven: which fits a Camunda 7 exit

If your team runs Camunda 7 and needs a path forward after Community Edition stopped receiving releases with 7.24 in October 2025, the first question is whether you must keep the Camunda 7 API and database schema. CIB seven is a Camunda 7 fork, built from the Camunda 7 Community Edition code and maintained by CIB software GmbH, so it is the closer option when your Java code, scripts and tables already depend on org.camunda classes and you want to change as little as possible. Flowable is a different engine, with its own BPMN, CMMN and DMN implementation, Java and REST APIs and Apache-2.0 license. It suits teams willing to re-platform the engine layer in exchange for a codebase that is not tied to the Camunda 7 lineage.

CIB seven's migration path is mostly a namespace and dependency change: its migration guide describes an OpenRewrite-based script that updates Maven versions, artifact names and imports, and it warns that objects already stored in the database, such as script tasks or variables referencing org.camunda classes, are not renamed automatically. Confirm the Camunda baseline your project is on, because the guide says older Camunda versions must first move to the matching baseline. Flowable's migration is a different exercise, so ask its team to show, against your own process models, what changes in your APIs, history data and scripts.

The decision also turns on support. CIB seven's FAQ describes a free Community edition and paid Community+, LTS and Enterprise editions, and recommends the LTS edition for high-volume or regulated environments. Ask CIB for the support window and patch commitments for each edition in writing, since the FAQ gives no fixed duration per edition. Flowable's open-source engines are free, with a community forum, while professional services and partner support are sold separately, so price that work into your scope before you choose.

Which scenario favors which platform

This table maps common Flowable and CIB seven decision scenarios to the platform that fits better and the condition that makes it matter. Read each row against your own Camunda 7 footprint, Java stack and regulatory obligations, since most of the choice depends on those conditions rather than on engine features alone.

Scenario	Better fit	Condition that makes it matter
Keeping existing Camunda 7 code with minimal change	CIB seven	CIB seven keeps the org.camunda API lineage and its migration guide describes a namespace change to org.cibseven plus an OpenRewrite script. Confirm the scope of the rename and the handling of stored objects that still reference org.camunda classes.
Moving to a Spring Boot 4 stack	Flowable	Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3. CIB seven's documented setups include Spring Boot, so confirm its Spring Boot 4 compatibility with CIB seven before committing.
Needing a vendor LTS line for regulated workloads	CIB seven	CIB seven offers paid LTS and Enterprise editions and its FAQ recommends the LTS edition for high-volume or regulated environments. Ask CIB seven for the support duration per edition, since the FAQ gives no fixed period.
Needing DMN and CMMN alongside BPMN	Flowable	Flowable's engines cover BPMN, CMMN and DMN and include a dedicated CMMN and DMN engine. CIB seven's sources center on the Camunda 7 BPMN lineage, so confirm DMN and CMMN coverage against your required feature list.
Needing an embedded engine inside a Java application	Either, depending on the existing code	Flowable embeds as a JAR in Java SE, servlet containers, Spring and Java EE servers. Teams already running Camunda 7 embedded should favor CIB seven for minimal change, while greenfield Java teams should compare both against their application server.
Needing a REST service that other systems call over HTTP	Flowable	Flowable exposes a REST application alongside its Java API. CIB seven ships its own user interface for task lists and monitoring, so confirm whether its REST surface matches the services your integrations already call.
Running on Oracle, SQL Server or DB2 databases	Confirm for both	CIB seven's 2.2 supported environments list Oracle 19c and 23ai, SQL Server 2017 to 2022 and IBM DB2 11.5. Flowable's configuration docs list the same database families, so verify the exact versions you run.
Needing Camunda 7 history and schema continuity	CIB seven	CIB seven keeps the Camunda 7 database schema lineage, which reduces data conversion work. Flowable requires an in-place migration path, so plan a test migration against a copy of production data before choosing.

How Flowable and CIB seven are built and deployed

Both platforms run the same kind of BPMN engine at their core, but they reach production in different ways. Flowable is a library you embed or a REST service you run, while CIB seven is a Camunda 7 backend with its own operator tooling. The cards below cover the deployment choices, database locking, and the operational work each path creates.

Embedded engine or REST service

Flowable can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications and Java EE servers, or used over HTTP through the Flowable REST application. Embedding ties engine upgrades to your application release train, while the REST service separates the engine lifecycle from calling systems. Decide early which model fits your teams, and confirm how the REST application's security settings will be configured in your environment before you commit.

Async executor lock handling

The Flowable async executor runs timers and asynchronous jobs from a thread pool. When several nodes share one database, they coordinate through lock owners and lock expiration times stored in that database. Expired locks are recovered, so jobs claimed by a failed node can be picked up by another. Your operations team should verify lock timeout settings, database connection pool sizing, and node failover behavior in a test cluster.

Spring Boot starters and actuator

Flowable provides Spring Boot starters for all engines, for REST, and for the individual process, CMMN and DMN engines, with support for Spring Boot 4.x. An actuator endpoint at /actuator/flowable exposes running process information for monitoring. Spring Boot version alignment matters here, because the 8.0.0 line dropped Spring Boot 3 support. Check the starter versions against your current Spring Boot baseline before planning an upgrade.

CIB seven as a Camunda 7 backend

CIB seven's 2.1 backend is based on Camunda 7.24.0, so existing Camunda 7 process models, APIs and database schema carry over with a namespace change. Projects on older Camunda versions must first move to the matching Camunda baseline. Engineers should plan the package rename from org.camunda to org.cibseven and check stored objects, such as script tasks and variables, that the migration does not rename automatically.

Own user interface from version 2.0

From version 2.0, CIB seven ships its own user interface for task lists, process monitoring and user and rights management, independent of the Camunda Tasklist, Cockpit and Admin modules. Operations teams gain a self-contained console, but they also take on its access control, identity wiring and upgrade cadence. Confirm which user directories and role mappings the console supports before you retire any existing Camunda tooling.

Spring Boot, Quarkus, Docker and Kubernetes

CIB seven documents setups for Spring Boot, Quarkus, Docker and Kubernetes, with Helm charts still in preparation. Container and Kubernetes packaging shifts patching and scaling work onto your platform team, while the Helm charts remain unfinished. If you plan to run on Kubernetes, ask CIB which chart version and supported database and application server combinations apply to your target release, and test them in a staging cluster.

Which databases and application servers each supports

Flowable's configuration documentation lists the database types the engines support. The list covers H2 for development and testing, along with MySQL, Oracle, PostgreSQL, IBM DB2 and Microsoft SQL Server for production use. The engines store process definitions, runtime state, history and the async executor's lock data in these databases, so the choice of database affects backup, replication and how the lock recovery behaves across nodes.

Production databases: MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server are all listed in the configuration documentation.
Development database: H2 is listed, which suits local development and tests rather than production workloads.
MySQL precision: The documentation notes that MySQL versions below 5.6.4 lack millisecond precision, which matters for timers and job timing.
Lock coordination: The async executor relies on lock owners and lock expiration times in the database, so the database must be reachable and consistent for every node.
Version pinning: The documentation names database types, not specific versions for each release line.

Confirm the exact database versions your Flowable release supports with Flowable's current documentation and your own test results before you commit to a database standard.

Side-by-side capability and fit

This table compares the two engines on standards coverage, APIs, Spring versions, identity, monitoring, Camunda 7 compatibility and license. Read the CIB seven column with its FAQ and supported-environment page in hand, because CMMN and DMN scope for CIB seven is not confirmed by the facts available here. The main takeaway is that both are Apache-2.0 Java engines, and the choice turns on your Spring version, your identity model and whether you need Camunda 7 API compatibility.

Capability	Flowable	CIB seven
BPMN, CMMN and DMN coverage	Compact engines for BPMN execution, CMMN case management and DMN decision rules	BPMN engine inherited from Camunda 7; confirm CMMN and DMN scope for your chosen release
Java and REST APIs	Java and REST APIs; REST application available for HTTP access	Java API inherited from Camunda 7; confirm REST API coverage in the 2.2 manual
Spring Boot and Spring Framework	Version 8.0.0 uses Spring Framework 7 and Spring Boot 4; Spring Boot 3 is not supported	Backend based on Camunda 7.24.0 (2.1) and 7.23.0 (2.0); confirm Spring Boot versions in the 2.2 docs
Identity integration	Identity service can be replaced by overriding or implementing the IdmIdentityService interface; LDAP reference implementation provided	Ships its own user interface and user and rights management, independent of Camunda Tasklist, Cockpit and Admin
Monitoring endpoints	Spring Boot starters expose an actuator endpoint at /actuator/flowable for running processes	Ships its own process monitoring interface from version 2.0; confirm exposed metrics endpoints
Camunda 7 API and schema compatibility	Requires migration of Java imports and process data to Flowable's own model and tools	Keeps the Camunda 7 API with imports moved from org.camunda to org.cibseven; objects already stored need manual review
License	Apache-2.0 open-source engines; commercial platform sold separately	Apache-2.0 source; paid Community+, LTS and Enterprise editions for security patches and hotfixes

What is free and what is paid on each side

Flowable's BPMN, CMMN and DMN engines are licensed under Apache-2.0, so you can embed them in your own Java or Spring services and run them without a license fee for the engines themselves. The company sells a separate commercial platform built on the same engines, including Flowable Work, Engage, Orchestrate and Design. According to the Flowable open source page, those products add low-code modeling, visual debugging, security controls, monitoring and governance.

Free engines: BPMN, CMMN and DMN engines with Java and REST APIs, under Apache-2.0.
Commercial platform: Flowable Work, Engage, Orchestrate and Design, sold separately and built on the same engines.
Community forum: open source users get access to a community forum for questions.
Professional services: implementation help and partner work are offered separately and priced by scope.
Support boundary: the community forum is not a contracted support commitment, so confirm what response terms, if any, you need.

Confirm with Flowable which commercial components your use case requires before you assume the engines alone cover your needs. Ask whether any of the commercial products are needed for monitoring, governance or low-code design, and get the support scope in writing.

What drives running cost for each option

Running cost for either engine is less about the license line and more about who patches the software, how often, and what the database and hosting stack demand. The cards below separate the recurring components so you can ask each vendor for the same breakdown in a quote.

Infrastructure and database hosting

Both options run as Java services on infrastructure you control, so compute, storage and high availability are recurring costs you carry in either case. CIB seven's supported environments list PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, IBM DB2 and H2, and Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Ask which database and application server versions each vendor tests against, and whether your database licensing (for example, Oracle or SQL Server) changes with the choice.

Paid editions and support subscriptions

Flowable's open-source engines are Apache-2.0 licensed with no subscription fee, and its commercial platform is a separate purchase. CIB seven's core is Apache-2.0, but its Community+, LTS and Enterprise editions are paid, and the FAQ recommends LTS for high-volume or regulated environments. Confirm in writing what each subscription includes, how long it runs, and whether it covers Camunda 7 Enterprise features.

Security patch cadence for paid distributions

CIB seven states that security patches and hotfixes for its paid distributions ship every 4 to 8 weeks, with urgent fixes released as needed for major security issues. That cadence is a recurring cost in staff time to test and deploy each release. The FAQ gives no fixed support duration per edition, so ask for the contractual support window and the process for out-of-cycle fixes. Flowable's open-source engines have no equivalent patch commitment, so your team owns patch timing.

Framework upgrades and migration effort

Flowable 8.0.0, released February 27, 2026, is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so a Spring Boot 3 application must move its framework stack before adopting it. Jackson 3 becomes the default JSON library, and JUnit 3 and 4 support is removed. CIB seven 2.x is based on the Camunda 7.24.0 baseline, and projects on older Camunda versions must first update to the matching baseline. Budget these upgrades as recurring work, not one-time migration.

Internal skills and operating staff

The largest recurring cost for most teams is the engineers who run, patch and extend the engine. Flowable's Spring Boot starters and REST application suit teams already fluent in Java and Spring, while CIB seven's own user interface for task lists and monitoring reduces the need for separate tooling. Ask each vendor for the expected operator skills, the documentation they provide for operations, and whether professional services or partner support is needed for routine upgrades.

Quote checklist for both options

Request a written quote that separates one-time costs (migration, customization, hardening, initial testing) from recurring costs (subscriptions, support, patch testing, hosting and database licenses). DeployOpen does not publish a price list, and a quote follows from a written scope. Ask each option for its support window, patch process, supported database and server versions, and the effort assumed for your next framework upgrade.

Moving from Camunda 7 to CIB seven or Flowable

This sequence shows what each path requires in order, from the baseline update and code changes on the CIB seven route to the API and schema switch on the Flowable route, so you can see what transfers unchanged and what must be rebuilt before cutover.

Confirm your current Camunda 7 baseline
Identify the exact Camunda 7 version your application runs, including the engine and any Camunda Tasklist, Cockpit or Admin modules in use. CIB seven's migration guide says projects on older Camunda versions must first update to the matching Camunda baseline before migrating. For the CIB seven 2.1 line, that baseline is Camunda 7.24.0, and for CIB seven 2.0 it is Camunda 7.23.0. Your platform team or application owner should record the version in the change ticket. The step is done when the target CIB seven line and its matching baseline are written down and agreed with the application owners.
Bring the application to the matching baseline
The developers update the existing Camunda 7 application to the Camunda baseline that matches your target CIB seven line, then run the full test suite and process regression tests against it. This step is done before any package names change, so that failures can be traced to a version move rather than to the rename. Confirm that the application builds, deploys and completes representative process instances on the baseline. Record which test cases pass, and keep the test evidence for the change record.
Run the OpenRewrite migration script
The developers run the OpenRewrite-based migration script that CIB seven provides, 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. Review the diff carefully before committing, because the script covers source and build files but not everything at runtime. The step is done when the project compiles against CIB seven artifacts and the diff has been reviewed by a second engineer.
Find org.camunda references stored in the database
Search the database and the process definitions for objects that the script does not rename. CIB seven's guide warns that items already stored in the database, such as script tasks and variables that reference org.camunda classes, are not renamed automatically. Build a list of affected process definitions, script tasks, serialized variables and custom listeners, then fix or redeploy each one. Ask the engineering team to confirm this inventory with a query against the running environment rather than relying only on the source tree. The step is done when the list is empty or every item has a documented fix.
Decide on namespace compatibility properties
CIB seven offers namespace compatibility properties for scripting and reflection, and they are disabled by default. Decide with the engineering team whether any scripts or reflective calls still depend on org.camunda names after the inventory. Enable a property only for a documented reason, and record which one, why, and the planned date for removing it. Security and architecture reviewers should approve any compatibility setting, since it keeps old names resolvable at runtime. The step is done when each enabled property has a written justification or the decision not to enable any is recorded.
Test, then cut over the CIB seven build
Run the migrated application against a copy of production-like data in the supported environment, using the Java, database and application server combination listed on CIB seven's supported environments page. Verify that running instances resume, that history and timers work, and that the CIB seven user interface covers the monitoring and task list needs that Camunda Tasklist, Cockpit or Admin used to provide. Plan the production cutover and a rollback path with the operations team. The step is done when test results are signed off and the rollback procedure has been rehearsed.
Switch from the Camunda API and schema to Flowable
On the Flowable path, the engineering team replaces Camunda 7 API calls with Flowable's Java and REST APIs and maps the Camunda data model to Flowable's, which uses different table and schema structures. Process models are reviewed against Flowable's BPMN support, and any Camunda-specific extensions or listeners are rewritten. Process data and history are a separate workstream. For how running instances and history move, see the sibling topic on Flowable vs Camunda 7 migration. The step is done when the application's API surface is mapped to Flowable and every Camunda-specific extension has a documented replacement.
Record what transferred and what was rebuilt
Close the change with a written record of what carried over unchanged, what was renamed, what was rewritten and what was rebuilt. On the CIB seven path, the record should list the baseline version, script output, database fixes and any compatibility properties. On the Flowable path, it should list the API mappings and any process data handled through the sibling migration. Ask the vendor or your implementation partner to confirm each assumption about compatibility before go-live. The step is done when the record is reviewed by the application owner and filed with the change ticket.

Where migrations usually run long

The migration effort is rarely in the engine swap itself. It sits in the custom code and data that reference Camunda 7 directly. Start by inventorying every Java delegate, execution or task listener, expression, and script task in your process models, and search each one for org.camunda imports. CIB seven's migration guide says Java imports change from org.camunda to org.cibseven and that an OpenRewrite-based script covers Maven coordinates, artifact names and imports. That script does not reach everything. Objects already stored in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically, and the namespace compatibility properties for scripting and reflection are disabled by default. Decide now whether those properties will stay off, and test every script path that runs in production.

Next, list the operational tooling your teams use today. CIB seven 2.0 and later ship their own user interface for task lists, process monitoring, and user and rights management, independent of the Camunda Tasklist, Cockpit and Admin modules. That is a replacement, not a drop-in. Inventory who uses Cockpit for incident work, which dashboards and saved filters operations depends on, and which permissions are granted through the Camunda Admin module. Then check how your users and groups reach the engine. If you rely on an identity provider or LDAP directory, confirm how the chosen stack maps identities and authorizations, and whether Flowable's identity service extension points cover your case. Flowable's documentation describes replacing the identity service and offers an LDAP reference implementation, but that work is yours to scope and test.

Finally, plan the test of long-running process instances. Instances that sit in wait states for weeks, timers, and async jobs are the cases most likely to break after a change of library or database namespace. Ask the vendor and your own team which upgrade path applies to in-flight instances, and whether any must finish on Camunda 7 before cutover. Confirm that the target database and application server combination is on the supported list, and that your schema and history tables migrate cleanly on a copy of production data. The CIB seven supported environments page is the reference for that check. Record the results as the acceptance evidence for the cutover, so the decision does not depend on memory.

Implementation decisions that shape the project

Flowable and CIB seven share a Camunda 7 heritage, so the differences show up in choices the team makes early: which engine lineage to build on, which Spring Boot baseline to target, and which database and identity source to connect. Each decision below carries a condition that determines whether it matters for your project.

Engine lineage and migration path

CIB seven keeps the Camunda 7 API and namespace, so a Camunda 7 codebase moves mostly through dependency and import changes. Flowable uses its own API and data model, so the work is a re-platforming exercise. The decision matters most if your process models, scripts or custom listeners depend on Camunda classes. Check whether any org.camunda references are stored in the database, because those are not renamed automatically during migration.

Spring Boot baseline

Flowable 8.0.0 targets Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so teams on Spring Boot 3 must upgrade the application before or during adoption. CIB seven's supported environments are framed around Java 17 and 21 and application servers rather than a single Spring generation. Confirm your framework version, Java version and the application server or container you run before choosing, since a platform upgrade and a framework upgrade should not be bundled without a plan.

Database target

Both engines persist process state in a relational database, and the supported lists differ. Flowable documents H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. CIB seven's 2.2 environments page lists PostgreSQL 15 to 18, MySQL 8.0, MariaDB, Oracle 19c and 23ai, SQL Server 2017 to 2022, DB2 11.5 and H2 2.3. Match the database to your existing platform and DBA standards, and ask each vendor to confirm the exact versions they will certify for your environment.

Identity source integration

Flowable's docs say identity management can be replaced by overriding the IdmIdentityService implementation, with an LDAP reference implementation available. CIB seven ships its own user interface for task lists, monitoring and user and rights management, which changes where user and rights administration lives. If your directory is the source of truth, decide early whether the engine reads identities directly or receives them from your identity provider, and map groups to task assignment rules before build starts.

UI replacement and operator tooling

Camunda 7 users typically rely on Tasklist, Cockpit and Admin. Flowable 7.0.0 removed the bundled UI applications, so you will build or source task and monitoring screens yourself, or use Flowable's commercial products. CIB seven 2.0 and later supply their own task lists, process monitoring and user administration. This decision matters most where business users work in task lists daily. Estimate the front-end scope with both vendors and check whether your operations team needs a monitoring console on day one.

Support contract and patch cadence

CIB seven's free Community edition is joined by paid Community+, LTS and Enterprise editions, and the FAQ recommends LTS for high-volume or regulated environments. Its paid distributions receive security patches and hotfixes every 4 to 8 weeks. Flowable's open-source engines come with a community forum, while professional services and partners are sold separately. Ask each vendor for written patch timing, severity response terms and the duration of support for the version you will run, because the sources do not give a fixed support duration for each CIB seven edition.

What implementing each involves

Both paths keep the process engine inside your own infrastructure, so the work splits between application code, database administration and operations. The decision to make first is which of those your team can staff. Moving from Camunda 7 to CIB seven is mostly a namespace and dependency change, while moving to Flowable means rewriting integration code against Flowable's own APIs. Before estimating either, inventory every Java class that imports org.camunda, every script task, and every stored variable that references Camunda classes, because the CIB seven migration guide notes that objects already in the database are not renamed automatically.

On the CIB seven path, the application changes center on Maven coordinates, artifact names, imports and the Liquibase changelog path under org/cibseven, and CIB seven provides an OpenRewrite-based script for much of that. Your team still owns the baseline step: projects on older Camunda versions must first move to the matching Camunda baseline. For Flowable, plan for a larger code effort, since the Flowable engines expose their own Java and REST APIs and the BPMN, CMMN and DMN integrations must be re-pointed. Confirm with each vendor whether an in-place data migration exists for your Camunda 7 version and history settings before you commit to a path.

Environment and operations work is similar on both sides and largely recurring. Check the supported matrix for your target stack. CIB seven's supported environments page lists specific Java, database and application server versions, so compare it against your current platform before you schedule upgrades. Your team also owns testing of process definitions, the async job executor and lock behavior across nodes, and the patch cadence. For CIB seven, ask whether your edition's security patch schedule fits your change process. DeployOpen plans and implements self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask each vendor and DeployOpen for a written scope that names who runs database maintenance, testing and on-call support after go-live.

Questions buyers ask before choosing Flowable or CIB seven

How much does moving from Camunda 7 to CIB seven cost?

The software license is not the main cost. The CIB seven source is Apache License 2.0, and its FAQ says it may be used free of charge in commercial software, at least for its core functions. The recurring and one-time costs sit elsewhere: engineering time for the migration and regression testing, infrastructure for the supported database and application server, and, if you choose it, a paid Community+, LTS or Enterprise edition. The FAQ recommends the LTS edition for high-volume or regulated environments. No price list was supplied, so ask CIB for each paid edition in writing, including what it covers and how long it runs. Ask your implementation partner for a quote built from a written scope, with migration, testing and handover listed as separate line items.

How long does a Camunda 7 exit take?

The supplied sources give no duration for either path, so treat any figure a vendor quotes as a claim to verify. The timeline is set by a few factors. The first is your starting Camunda version: CIB seven's migration guide says projects on older Camunda versions must first move to the matching Camunda baseline, and CIB seven 2.1 is based on Camunda 7.24.0. The second is the amount of change in your estate, including process definitions, Java delegates, scripts and any objects stored in the database that reference org.camunda classes, which are not renamed automatically. Others are database size, history retention, use of the Camunda web applications, and how much regression coverage exists. Ask for a phased plan with exit criteria for each phase.

Can an internal team migrate from Camunda 7 to CIB seven alone?

Often yes, if the team has Java, Maven, database and BPMN skills and time set aside for testing. CIB seven provides an OpenRewrite-based script that updates Maven versions, artifact names and imports, which covers the mechanical part of the work. The harder work is what the script does not do: stored database objects, scripts and reflection that refer to the old namespace, and behavior checks across every process. The namespace compatibility properties exist but are disabled by default, so someone must decide whether to enable them and test the result. Teams without a current regression suite, a production-like test environment or a rollback plan usually take longer and carry more risk. An outside partner can take on defined parts of the work under a fixed scope.

Which databases and application servers does CIB seven 2.2 support?

The CIB seven 2.2 supported environments page lists Java 17 and 21 and these databases: PostgreSQL 15 to 18, MySQL 8.0, MariaDB 10.6 and 11.8, Oracle 19c and 23ai, SQL Server 2017 to 2022, IBM DB2 11.5 and H2 2.3. The listed application servers are Apache Tomcat 11.0, JBoss EAP 8.1 and WildFly 40.0. Confirm your target combination against that page before you plan the migration, because a database or server version outside the list is a support question to put to CIB. Check the same for any Flowable target. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and notes that MySQL versions below 5.6.4 lack millisecond precision. Verify both lists against the versions you run.

Is CIB seven a safe long-term choice for a Camunda 7 estate?

It has several signs of continuity. The source is public under Apache License 2.0 on GitHub, the project published CIB seven 2.2.0 on May 31, 2026, and CIB describes CIB seven as a key strategic product of CIB software GmbH. CIB also says it has provided support and maintenance for Camunda 7 Community Edition since October 2025. Safety still depends on a single vendor and a fork maintained by that vendor. The FAQ gives a patch cadence of every 4 to 8 weeks for paid distributions but no fixed support duration per edition. Ask CIB, in writing, for the support end date of each LTS line, the terms if the company changes direction, and how you would continue with the source if the fork were discontinued.

Is Flowable a drop-in replacement for Camunda 7?

No. Flowable is a separate engine family with its own Java and REST APIs and its own release line, so moving to it means changing integration code, tests and deployment. CIB seven keeps the Camunda 7 API surface, with changes mostly limited to imports, artifact names and Liquibase paths, which is why its migration is a much smaller change. Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so check your framework versions before you choose a target. Flowable's 7.0.0 notes also list features removed from that line, including the UI applications and async history. Confirm with Flowable which process and history data carry over for your starting version, and whether it provides an in-place migration path for your case.

What support does each vendor cover?

Flowable's open-source engines are Apache-2.0 licensed, and open-source users get access to a community forum. Professional services and partners are offered separately, and Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, add low-code modeling, visual debugging, security controls, monitoring and governance on the same engines. CIB seven offers a free Community edition and paid Community+, LTS and Enterprise editions, with security patches and hotfixes in the paid tiers. CIB seven Enterprise includes the Camunda 7 Enterprise features starting with version 2.1.2. For either vendor, ask for the covered versions, response targets, patch windows and exclusions in writing. DeployOpen works separately from both vendors: its implementation, hardening, upgrade and support work is agreed in a written scope, with ongoing support available as a retainer.

What should we ask for in a quote for this move?

Ask for a quote that separates each cost component so you can compare options. Request the scope of each phase, including discovery, the process and dependency inventory, migration of code and configuration, data migration and history handling, testing, deployment, documentation and handover. Ask which items are one-time and which recur, such as paid vendor editions, retainers for upgrades, and infrastructure. Ask what drives the price up, including the starting Camunda version, the number of processes and custom integrations, and the number of environments to validate. Ask for named acceptance criteria and what happens if a defect is found after handover. Finally, ask the vendor to confirm in writing the database and application server versions the quote covers.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Flowable vs CIB seven, that means starting from your Camunda 7 footprint, your database and application server choices, and your support requirements, then agreeing the work in writing before anything is built.

How we scope

Inventory your current Camunda 7 version, BPMN process definitions, scripts and database objects before choosing an engine path.
Confirm the target database and application server combination against the vendor's supported environment lists for each option.
Agree a fixed-scope written plan covering deliverables, timelines and the support model, with ongoing support available as a retainer.

How we build

Set up the chosen engine in your own cloud, data center or air-gapped network, with the Spring Boot or servlet deployment model your teams use.
Run migration rehearsals against a copy of your production process data, including history tables and objects that still reference old namespaces.
Test identity integration, async executor behavior across nodes and any custom scripting or reflection code before cutover.

How we hand over

Document the configuration, deployment steps, migration decisions and rollback procedure in a form your platform and operations teams can maintain.
Provide evidence for your own compliance assessments, such as change records and access configuration, without issuing any audit report or certification.
Walk your engineers through upgrade paths, including the vendor's patch cadence for paid editions, so your team owns the platform after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial implementation.
Plan upgrades against the vendor's release and patch schedule, and retest processes and integrations after each change.
Confirm with each vendor which support tier covers your environment, since commercial support terms differ between the two options.