Which Camunda 7 support path fits your lifecycle risk
A team still running Camunda 7 process applications has to decide who will support the engine for the next several years. Camunda 7 Enterprise has a documented end of life of April 9, 2030, with paid extended support available through April 2032, while CIB seven is a vendor-backed fork that offers paid LTS and Enterprise editions with security patches and hotfixes released every 4 to 8 weeks for its paid distributions. The Camunda 7 Community Edition stopped receiving releases after 7.24, and CIB has provided support and maintenance for that Community Edition since October 2025. Teams on the free Community Edition therefore have no upstream security patches from Camunda, and this is the first risk to resolve.
The right answer depends on three things: your regulatory obligations, the written terms of each edition, and whether you want support from Camunda itself or from a vendor-backed fork. Ask Camunda for the Enterprise terms in writing, including what the long-term support release receives and when, and ask CIB which edition carries the patch commitment your auditors expect. CIB's FAQ recommends its LTS edition for high-volume or regulated environments, but it does not state a fixed support duration per edition, so confirm that duration in the contract. For a broader view of the choice, the overall comparison of the three Camunda 7 paths is the next read, and the paths differ in migration effort as well as support.
Plan for the exit before you sign. Staying on the Camunda 7 codebase through a fork keeps your Java imports, Liquibase changelog and stored process objects close to what you run today, but CIB seven still changes org.camunda references to org.cibseven, and objects already stored in the database are not renamed automatically. Record which edition you buy, the support end date in its contract, and the date on which you will need a new path. Teams with a 2030 horizon should set a review date well before April 2030 so that a move to another engine is a planned project, not an emergency.
How the support models differ, part by part
This table sets Camunda 7 Enterprise beside CIB seven across the points that govern how long each line stays supported and who answers when something breaks. Read each row as a question to put to the vendor: where the facts give a date or cadence, the cell states it, and where they do not, the cell says what to confirm.
| Support factor | Camunda 7 Enterprise | CIB seven |
|---|---|---|
| Last feature baseline | Camunda 7.24, the final feature release, scheduled for October 14, 2025 | Built on the Camunda 7.24.0 backend in the 2.1 line, per the CIB seven migration guide |
| End of life or support window | Enterprise end of life extended to April 9, 2030, with 7.24 as a long-term support release | No fixed support duration per edition is stated in the FAQ; ask CIB for the end date of your chosen line |
| Paid extension | Paid extended support from April 2030 through April 2032 | Paid LTS and Enterprise editions; confirm in writing whether any extension beyond a line's life exists |
| Patch cadence | Long-term support release updated twice a year, in April and October | Security patches and hotfixes for paid distributions every 4 to 8 weeks, with urgent fixes as needed |
| Community tier after the last release | No further releases or security patches for Community Edition after October 2025 | Free open-source Community edition; the FAQ says security patches and hotfixes come with the paid editions |
| Edition structure | Community Edition and Enterprise Edition | Community, Community+, LTS and Enterprise, with LTS recommended for high-volume or regulated environments |
| Who provides support | Camunda, under its Enterprise agreement | CIB software GmbH, which says it has supported Camunda 7 Community since October 2025 |
What the Camunda 7 end of life to 2032 actually covers
The Camunda 7 Community Edition has no future releases or security patches. Camunda's final feature release, 7.24, was scheduled for October 14, 2025, and after that date no further releases or security patches are made for the Community Edition. The Enterprise Edition runs longer. Camunda extended its end of life to April 9, 2030, with 7.24 designated as a long-term support release that receives updates twice a year, in April and October. Paid extended support is available from April 2030 through April 2032. Read the dates as a sequence: Community stopped, Enterprise continues to 2030, and paid extension covers the two years after that. Any team still running the Community Edition is outside the patch stream today, regardless of what its Enterprise neighbors receive.
Before you rely on these dates, confirm the contract terms in writing with Camunda. Ask which exact 7.24 patch levels the twice-yearly updates include, whether security fixes are delivered outside the April and October cadence for critical issues, and how fast a fix reaches a customer who reports it. Ask whether the 2030 to 2032 extended support is priced per year, as a single block, or as a percentage of license fees, and whether it is renewable or fixed. Also confirm what is in scope: the engine only, or the Tasklist, Cockpit and Admin web applications, the REST API and the supported Java, application server and database versions. The answers determine whether the Enterprise path fits a multi-year plan.
The same questions apply to CIB seven, but the public terms differ. Its FAQ describes paid distributions that receive security patches and hotfixes every 4 to 8 weeks, with urgent fixes as needed, and it gives no fixed support duration per edition. Put that in your evaluation as an open item: request the support term, the patch service levels and the renewal mechanics in a written quote before comparing the two paths on cost. Treat any timeline you cannot document as a risk to plan for, not as a fact to assume.
What changes the support decision in practice
Staying on the Camunda 7 codebase means choosing a support model, a patch rhythm and a runtime baseline together. The cards below cover the factors that most often tip the decision between Camunda 7 Enterprise and CIB seven, and what to verify with each vendor before committing.
Audit expectations for supported software
Auditors and regulators often ask whether every component in a production process engine still receives vendor security fixes. Camunda 7 Community Edition received no further releases or security patches after its final feature release, so a Community-only deployment has a documented gap. Ask your assessor which evidence they accept for a supported version, such as a vendor support contract, a maintenance statement or a dated patch record, and confirm the exact control wording with your framework owner.
Speed of security patch delivery
Ask how quickly a fix for a critical vulnerability reaches your production environment, not only when it is published. CIB seven's paid distributions ship security patches and hotfixes every 4 to 8 weeks, with urgent fixes released as needed for major security issues. Camunda 7 Enterprise patch timing is set by its own release calendar, so compare the worst-case gap you would accept against your internal emergency change process.
Patch cadence against LTS rhythm
Camunda 7 Enterprise's long-term support line, 7.24, receives updates twice a year, in April and October. CIB seven's paid editions instead release patches every 4 to 8 weeks. A faster cadence means more frequent upgrade rounds for your operations team, while a slower one means longer waits between fixes. Map both cycles against your change calendar and test window before choosing, and ask CIB whether the LTS edition follows the same cadence as its other paid editions.
Vendor roadmap beyond 2032
Camunda 7 Enterprise end of life is extended to April 9, 2030, with paid extended support available through April 2032. If your process estate will run longer than that, the question is who maintains the codebase after the window closes. Ask CIB seven about its commitment to the fork beyond the next few years, how it governs the codebase, and what exit path it provides, and ask Camunda about any support available after the extended window.
Database and Java runtime coverage
Confirm that your database engine, JDK and application server appear in the vendor's supported environments list before you commit. CIB seven 2.2 lists Java 17 and 21, PostgreSQL 15 to 18, MySQL 8.0, MariaDB, Oracle 19c and 23ai, SQL Server 2017 to 2022, IBM DB2 11.5 and H2 2.3, on Tomcat, JBoss EAP or WildFly. A gap here can force an infrastructure change that costs more than the license, so check your current versions against that matrix and ask Camunda to confirm its own matrix for the 7.24 line.
Migration effort from the org.camunda namespace
Moving to CIB seven changes Java imports from org.camunda to org.cibseven and the Liquibase changelog path. CIB seven provides an OpenRewrite script for Maven coordinates, artifact names and imports, but it does not rename objects already stored in the database, such as script tasks or variables that reference org.camunda classes. Namespace compatibility properties exist but are disabled by default. Budget a review of stored definitions, scripts and custom listeners, and ask CIB to confirm which baseline your version needs before migrating.
Which path suits which team situation
Teams in banking, healthcare or public sector often need a dated, vendor-stated end of life before they can sign off on a platform. Camunda 7 Enterprise gives that date: Enterprise end of life was extended to April 9, 2030, with paid extended support available through April 2032, per Camunda's announcement. CIB seven publishes a patch cadence of security patches and hotfixes every 4 to 8 weeks for its paid distributions, but its FAQ gives no fixed support duration per edition, so a regulator-facing lifecycle statement has to come from CIB's contract terms rather than the public FAQ.
- Fixed end date: Camunda 7 Enterprise offers a published end of life. CIB seven's paid editions offer a cadence but no published end date in the supplied material.
- Patch rhythm: CIB seven's LTS edition is recommended for high-volume or regulated environments, with patches every 4 to 8 weeks and urgent fixes as needed.
- Community edition risk: Camunda 7 Community Edition receives no further releases or security patches after 7.24, so it does not suit a regulated production system.
- Evidence trail: Ask CIB for written support terms covering the patch window, the notification process for critical fixes and the supported database versions.
Confirm with each vendor how a security finding will be handled, in writing, before your assessment window opens.
Organizations that already hold a Camunda 7 Enterprise subscription usually gain the least from switching forks during the current contract term. The codebase, APIs and Camunda tooling stay in place, and the remaining work is to keep the platform on the supported 7.24 line through 2030. Staying put avoids the package rename, the Liquibase path change and the review of stored objects that a fork migration requires.
- Lowest change load: No namespace, import or Maven artifact changes are needed while the Enterprise subscription remains valid.
- Known support window: The end of life sits at April 9, 2030, with 7.24 receiving updates twice a year in April and October.
- Renewal leverage: Teams can use the approaching 2030 date to plan a later move, whether to CIB seven, Camunda 8 or another path, on their own schedule.
- Where it stops winning: If the Enterprise contract is scheduled to end before the team can move, the benefit disappears and a fork becomes the practical choice.
Check the exact terms of your current subscription, including which fixes and support hours it covers, before assuming it extends to 2030 on your deployment.
CIB seven ships its own user interface for task lists, process monitoring and user and rights management from version 2.0, independent of the Camunda Tasklist, Cockpit and Admin modules. Teams that want to stop depending on Camunda's web applications, or that need to standardize on a vendor-backed LTS line, fit this path well. The migration still requires a Camunda 7.23 or 7.24 baseline and package changes, so the interface is a reason to move only when the rest of the migration is acceptable.
- Own UI: CIB seven's interface replaces the Camunda web applications, which matters if your operations staff rely on Cockpit or Tasklist workflows that need redesign.
- LTS for regulated loads: The FAQ recommends the LTS edition for high-volume or regulated environments.
- Supported stack: The 2.2 environments page lists Java 17 and 21, PostgreSQL 15 to 18, MySQL 8.0 and others, on Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0.
- Where it stops winning: If your database or application server is outside the supported list, or your team depends on Camunda-specific features absent from the CIB interface, the path loses value.
Confirm that your database version and runtime appear on the supported environments page and that your process monitoring needs are met by the CIB interface.
Teams planning systems that must run beyond 2032 face a question that no Camunda 7 path fully answers. Camunda 7 Enterprise support ends in April 2032 at the latest, and the Community Edition is already frozen. A fork can carry the codebase further only if its vendor or community commits to that horizon, and the supplied CIB seven material describes patch cadence and editions but not a fixed end-of-life date beyond the current paid terms. For long horizons, the lifecycle question becomes a contract question.
- Dated support: Camunda 7 Enterprise has a known last date. Use it as the outer limit for any plan that stays on 7.24.
- Vendor commitment: CIB seven's paid editions can be contracted for a longer term. Ask CIB for the support duration per edition in writing.
- Exit planning: Staying on any Camunda 7 lineage means a later migration is still needed. Budget for that exit path from the start.
- Where it stops winning: If the workload must run for many years without another migration, a platform with a longer published lifecycle, or a move off BPMN altogether, may fit better.
Ask each vendor for its committed support end date and the exit path it will support, and compare the answers against your system's planned retirement.
How to confirm support terms in your own environment
This sequence turns vendor claims about Camunda 7 and CIB seven into written terms, tested against your own Java, application server, database and change calendar before you commit to either path.
Inventory your current Camunda 7 footprint
Record the exact Camunda 7 version in every environment, including any embedded engines inside application archives, and list the Java runtime, application server, Spring or other framework versions, and the relational database with its version. Include the Camunda web applications you use (Tasklist, Cockpit, Admin) and any custom REST or scripting code. Done means one inventory document that a second engineer has checked against the running systems, not against the original project files.
Request written support terms from Camunda
Ask Camunda in writing for the Enterprise Edition support terms that apply to your version, including the end of life date, the long-term support line you would stay on, and the paid extended support window. Confirm which edition covers your organization and whether security patches reach the exact release you run. Done means a written reply that names the edition, the release line and the dates, filed with your procurement record.
Request written support terms from CIB
Ask CIB software in writing which edition (Community, LTS or Enterprise, and any Community+ offer) fits your use, how the paid distributions deliver security patches and hotfixes, and what support duration applies per edition. The public FAQ gives a patch cadence but no fixed support duration per edition, so the duration must come from the contract. Done means a written answer for each edition you are considering, with any gaps listed as open questions.
Check CIB seven supported environments against your stack
Compare your Java version, application server or container runtime, and database product and version against the CIB seven 2.2 supported environments page. Note every mismatch, such as a database version outside the listed range or a server not on the list, and ask CIB whether the gap is covered by support or needs a platform upgrade first. Done means a signed-off compatibility table with each item marked supported, unsupported or to be confirmed.
Map patch cadence to your change windows
Take the patch cadence stated for CIB seven paid distributions and lay it against your own change approval process, freeze periods and testing lead times. Identify whether an urgent security fix could be deployed inside your normal window and who approves an out-of-cycle change. Compare this with the Camunda 7 Enterprise patch schedule from the vendor's written terms. Done means a short calendar note that states how each option would be applied in practice, reviewed by operations and the security owner.
Run a test patch cycle on a copy of production
Restore a copy of your production database to a non-production environment, then apply the candidate Camunda 7 or CIB seven release, including the migration steps from the vendor guide where your baseline requires them. Run your regression tests, check that existing process instances and history still load, and time the database update step. Scripting or reflection code that references old package names should be checked explicitly. Done means a recorded test log with any failures and fixes, which becomes the template for real patch cycles.
Document the exit path before you sign
Write down how you would leave each option: moving back to Camunda 8, moving to another engine, or forking again, with the migration effort each path would require. Record what data, models and custom code would need conversion and which items the test cycle already proved. Have the document reviewed by the architecture owner and the compliance lead. Done means a dated exit plan attached to the decision record, so the choice can be revisited when a support date approaches.
Questions buyers ask about Camunda 7 and CIB seven support
What does Camunda 7 Enterprise extended support cost?
Camunda does not publish the fee for paid extended support, so confirm the figure with Camunda in writing before you budget. The Enterprise subscription covers 7.24 as a long-term support release with updates twice a year in April and October, through April 9, 2030, and paid extended support runs from April 2030 through April 2032. The fee typically depends on the number of production deployments, the support tier and the contract term, so ask for each element separately in the quote. Also ask whether the extended period is priced as a separate line or bundled, and what happens to pricing if you move to a fork later.
How much effort does a CIB seven migration from Camunda 7.23 or 7.24 take?
The effort depends mainly on how much custom code and stored data reference Camunda packages. The CIB seven migration guide says the 2.1 backend is based on Camunda 7.24.0 and the 2.0 backend on 7.23.0, and projects on older Camunda versions must first move to the matching baseline. An OpenRewrite-based script updates Maven versions, artifact names and imports, and the Liquibase changelog path changes from org/camunda to org/cibseven. The work that remains manual is objects already stored in the database, such as script tasks or variables that reference org.camunda classes, which are not renamed automatically. Namespace compatibility properties exist but are disabled by default, so test them in a staging environment with real process instances before cutover.
Can our team run the CIB seven patch cycle ourselves?
Yes, if your team can absorb the testing and redeployment work that comes with each release. CIB seven's FAQ says security patches and hotfixes for its paid distributions arrive every 4 to 8 weeks, with urgent fixes released as needed for major security issues. Each patch needs a build, regression tests against your process models, a database check where schema-related changes apply, and a controlled rollout. Ask yourself who will own that cycle every month, who covers it during leave, and whether you have a staging environment that matches production databases such as PostgreSQL, Oracle or SQL Server. A retainer with an implementation partner can cover that routine, but the decision still rests on your internal ownership.
What does a fixed-scope implementation partner need from our side?
A fixed-scope engagement needs a written scope that names the systems, process models, environments and deliverables before work starts. From your side, expect to provide an inventory of Camunda 7 applications with their Java and database versions, access to source repositories and build pipelines, sample process instances and historical data for testing, and named owners who can approve changes. You will also need a decision on the target distribution and support tier, plus a test plan that defines what counts as an accepted result. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, so the scope should state exactly which of those activities are included.
Is the free CIB seven Community edition enough for production?
It depends on your risk profile, your patch expectations and whether auditors or customers expect a vendor-backed support path. CIB seven's FAQ describes a free, open-source Community edition alongside paid Community+, LTS and Enterprise editions, and it recommends the LTS edition for high-volume or regulated environments. The paid editions carry the security patches and hotfixes described in the FAQ, so the Community edition leaves you responsible for tracking and applying fixes yourself. Confirm with CIB which fixes reach the Community edition and on what timeline, and map that answer to your own change management and vulnerability management policy before you decide.
What is the exit path if CIB seven or Camunda changes its terms?
The exit path is more manageable if you keep your BPMN and DMN models, your application code and your database under your control, and avoid private extensions tied to one distribution. The CIB seven FAQ says the software may be used free of charge in commercial software, at least for its core functions, and the source is under Apache License Version 2.0, which limits the risk of a sudden license change on the released code. Camunda 7 Community Edition has no further releases or security patches, so the realistic alternatives are other Camunda 7 compatible forks, Camunda 8 or a different engine. Ask each vendor for written terms on support continuity, and document the Java package and schema dependencies that would have to change in each scenario.
Which CIB seven environments are supported before we commit?
Check the supported environments page for the exact version you plan to run, because the list is specific to each release. For CIB seven 2.2, the documentation lists Java 17 and 21, 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, running on Apache Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0. Compare that list with your current Java runtime, database and application server before scheduling a migration. If your stack falls outside the list, confirm support with CIB in writing, since a database or runtime outside the matrix changes the test scope and the support position.
How the migration path affects long-term support
The support model you pick also fixes how hard your next move will be, and the first constraint is the baseline. CIB seven's documented migration from Camunda 7 expects you to be on the Camunda 7.23 or 7.24 baseline. CIB seven 2.1 is built on Camunda 7.24.0 and CIB seven 2.0 on Camunda 7.23.0, and projects on older Camunda versions must first update to the matching baseline before they migrate. If your estate runs older 7.x builds, budget that upgrade as a separate step. Confirm your exact version in your own build files before you commit to a timeline with any vendor.
The move itself is mostly mechanical, but it is not finished when the build compiles. The migration changes Java imports from org.camunda to org.cibseven and the Liquibase changelog path from org/camunda to org/cibseven. CIB seven provides an OpenRewrite-based script that updates Maven versions, artifact names and imports. The guide is explicit that objects already stored in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically. Inventory those stored definitions and variables, and decide whether to migrate them or enable the namespace compatibility properties, which are disabled by default. Test scripting and reflection paths in a staging copy of your production data.
The support choice also sets your exit path. Staying on Camunda 7 Enterprise keeps you on the Camunda codebase until the end of life date, after which paid extended support runs through April 2032. A CIB seven move keeps the Camunda 7 programming model and database schema, but it changes the package namespace, so a later move to another platform starts from the CIB seven namespace. Ask each vendor what they will support after your chosen end date, and how they handle customer-specific patches. Camunda 8 and the other Camunda 7 forks each carry their own migration effort, and those are covered on the sibling comparison pages.
How DeployOpen helps teams choose and implement a Camunda 7 support path
DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure, so a Camunda 7 support decision can be tested against the actual engine, database and deployment before anything is committed. We scope the path, build and verify it in your environment, and hand over the documentation and runbooks your team needs to run it.
How we scope
- We confirm which Camunda 7 baseline and database each process application runs on before recommending a path.
- We agree the written scope for the support decision, including which applications, environments and deliverables are covered.
- We list which support terms, edition features and patch cadence your team must confirm directly with the vendor before signing.
How we build
- We run a fixed-scope migration spike in a non-production copy of your environment against the chosen fork or Enterprise line.
- We review namespace changes, stored objects that still reference old package names and scripts that depend on reflection.
- We test the chosen supported database and Java runtime combination against your workload before any production change.
How we hand over
- We document the chosen support path, the migration steps taken, and the rollback plan in language your engineers can follow.
- We deliver configuration, deployment and upgrade runbooks for the platform inside your own cloud account or data center.
- We record open items, including edition features and support windows that still need vendor confirmation, with named owners.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover patch review and upgrade testing when the vendor publishes new security fixes or releases.
- Any ongoing work starts from a written scope, so your team knows what is covered and what needs a new quote.
