Camunda 7 vs CIB seven: which fits your 7.24 estate
Choose Camunda 7 Enterprise if your organization already holds a Camunda contract and the main goal is to keep the vendor's support path unchanged until the end of the 7.24 line. Camunda 7 Enterprise Edition end of life has been extended to April 9, 2030, with 7.24 as a long-term support release receiving updates twice a year in April and October, and paid extended support available from April 2030 through April 2032, according to Camunda's end of life extension announcement. This path keeps the org.camunda packages, the existing Liquibase changelog paths and the Tasklist, Cockpit and Admin applications, so the code change is near zero. The trade-off is that you stay on a vendor-controlled product line with a fixed end date, and any move afterward is a separate project. Confirm the exact entitlements, edition terms and renewal dates in your Camunda contract, not in this summary.
Choose CIB seven when you need a vendor-backed fork that keeps the Camunda 7 code base but offers paid LTS or Enterprise support on a different lifecycle. CIB seven is Apache-2.0 licensed, and its FAQ describes a free Community edition plus paid Community+, LTS and Enterprise editions, with security patches and hotfixes released every 4 to 8 weeks for the paid distributions. The FAQ recommends the LTS edition for high-volume or regulated environments. From version 2.0, CIB seven ships its own web interface for task lists, process monitoring and user and rights management, so your team must test whether the Camunda Tasklist, Cockpit and Admin screens your operators use have equivalents. Moving requires renaming org.camunda imports to org.cibseven and the Liquibase path from org/camunda to org/cibseven. Your team must also update stored objects, such as script tasks or variables that reference org.camunda classes, which the migration guide says are not renamed automatically.
The decision turns on three checks. First, the support model: compare the Camunda 7 Enterprise end date with the CIB seven edition, patch cadence and contract terms your procurement team can accept. Second, the database and runtime match: confirm your database and application server appear on the CIB seven 2.2 supported environments page, which lists PostgreSQL 15 to 18, MySQL 8.0, Oracle 19c and 23ai, and Apache Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0, among others. Third, how much renaming your estate can absorb: count Java classes, scripts, custom listeners, and database rows that reference Camunda namespaces, and run the OpenRewrite migration script against a staging copy before you commit. Migrating from 7.23 or 7.24 is the documented path, and older Camunda versions must first be moved to the matching baseline.
Which platform fits which Camunda 7 scenario
This table maps common Camunda 7 situations to the better fit between staying on Camunda 7 Enterprise and moving to CIB seven. Read each row for the condition that tips the decision, then confirm the vendor terms that apply to your contract and environment.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Existing Camunda Enterprise contract | Camunda 7 Enterprise | Your contract already covers 7.24 support through the end of life extended to April 9, 2030, and you have no need to change the codebase or vendor. |
| Regulated environment needing vendor patches on a fixed cadence | CIB seven LTS or Enterprise | CIB seven's paid distributions release security patches and hotfixes every 4 to 8 weeks, per its FAQ. Confirm the commitments in writing before you rely on them. |
| Team that wants to keep Cockpit and Tasklist | Camunda 7 Enterprise | From version 2.0, CIB seven ships its own task list, monitoring and user management UI rather than the Camunda Cockpit and Tasklist modules, so existing operator workflows change. |
| Team on 7.23 or 7.24 running Oracle or SQL Server | Confirm before choosing | CIB seven 2.2 supports Oracle 19c and 23ai and SQL Server 2017 to 2022. Check that your exact database versions and JDBC drivers are on the supported list. |
| Team on Camunda 7.23 or 7.24 with PostgreSQL or MySQL | CIB seven | Both databases appear in CIB seven's supported environments, and the migration path starts from the 7.23 or 7.24 baseline without a Camunda 8 rewrite. |
| Team that plans to leave Camunda 7 within a year | Camunda 7 Enterprise or CIB seven, short term | A migration to CIB seven still requires package and changelog changes and a review of stored objects. If the exit date is near, a short Enterprise term may be simpler than a fork migration plus later exit. |
| Team with custom code referencing org.camunda classes in stored scripts | Camunda 7 Enterprise until the change is scoped | CIB seven does not rename objects already stored in the database, such as script tasks or variables. Scope that work before choosing the fork. |
| Team that expects to move to Camunda 8 later | Camunda 7 Enterprise | Staying on the Camunda 7 codebase keeps the Camunda 8 move as a separate project. CIB seven adds a second namespace to unwind if you leave later. |
How both engines are built and what they mean for operations
Both engines share a Camunda 7 lineage, so most of the architecture carries over unchanged. What differs is who ships the web tier, who patches it, and which runtimes and deployment shapes are supported. The cards below cover the parts that decide your operating load.
Embedded relational engine
Both products run the process engine on a relational database through MyBatis, and the engine can run embedded in a Java application, as a shared engine, or standalone. Because the schema and API are inherited from Camunda 7, existing process data stays in the same kind of store. Check which database engines and versions your DBA team has approved, because CIB seven publishes its own supported list and that list, not the Camunda 7 list, governs your upgrades.
REST APIs and Camunda web applications
Camunda 7 ships REST APIs plus the Tasklist, Cockpit and Admin web applications. If you keep the Camunda web tier, you keep the Camunda 7 patch path for those applications, which ends for Community Edition after its final release. Confirm which web components your processes and operators depend on before you decide whether the web tier moves with the engine or stays on its own schedule.
CIB seven's own user interface
From version 2.0, CIB seven ships its own interface for task lists, process monitoring, and user and rights management, independent of the Camunda Tasklist, Cockpit and Admin modules. This means the operations team patches and configures a second web tier that CIB seven owns. Ask whether your current Cockpit dashboards, custom Tasklist forms and user group mappings can be reproduced in that interface, and budget testing for each one.
Frameworks and deployment shapes
CIB seven documents Spring Boot, Quarkus, Docker and Kubernetes setups, with Helm charts described as in preparation. A team that relies on a Helm chart for cluster rollout should treat that chart as a gap today and plan a hand-maintained deployment manifest until it ships. Check that the framework version your application uses appears in the supported environments list before committing.
Supported Java runtimes
CIB seven 2.2 supports Java 17 and 21 on Apache Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0. Any application that has moved to a newer Java baseline, or that runs on an application server outside this list, needs a platform decision before migration. Java runtime changes affect the application image, the build pipeline and the security scanning baseline, so raise them in the design phase rather than at cutover.
Patching and monitoring responsibility
Under the CIB seven FAQ, paid distributions receive security patches and hotfixes every four to eight weeks, with urgent fixes released as needed for major security issues. The community edition is free but carries no equivalent guarantee. Your team will own the patch test cycle either way, so ask CIB about the edition you select, how notifications arrive, and how a hotfix reaches a deployed application without a full engine upgrade.
Capabilities, runtimes and databases compared
This table compares licensing, support, patch cadence, runtimes, databases, web interface and packaging for Camunda 7 and CIB seven. Read each row as a question to put to both vendors, since the CIB seven matrix is published while the Camunda 7 Enterprise matrix must be confirmed directly with Camunda. The main takeaway is that CIB seven publishes a concrete support matrix today, while Camunda 7 Enterprise coverage depends on what your contract and Camunda confirm.
| Capability | Camunda 7 (Enterprise, to 2030) | CIB seven (2.2) |
|---|---|---|
| License and source | Camunda 7 Community Edition is Apache-2.0, but its repository is archived with 7.24.0 as the last tag | Source under Apache License 2.0, free for commercial use of core functions per its FAQ |
| Support model | Enterprise Edition from Camunda, with end of life extended to April 9, 2030 | Community free, paid Community+, LTS and Enterprise editions from CIB software |
| Patch cadence | Long-term support release 7.24 receives updates twice a year, in April and October | Security patches and hotfixes every 4 to 8 weeks for paid distributions, per its FAQ |
| Java baseline | Confirm the Java versions for your Camunda 7 Enterprise release with Camunda | Java 17 and 21 on the 2.2 supported environments page |
| Relational databases | Confirm the Enterprise database matrix with Camunda before purchase | 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, H2 2.3 |
| Application servers | Confirm supported application servers for your Enterprise release with Camunda | Apache Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0 |
| Web interface | Tasklist, Cockpit and Admin applications from Camunda 7 | Own UI for task lists, process monitoring and user and rights management from version 2.0 |
| Packaging and deployment | Embedded, shared or standalone engine as documented for Camunda 7 | Spring Boot, Quarkus, Docker and Kubernetes setups; Helm charts in preparation per the FAQ |
What each license and edition includes and what it costs to keep
Camunda 7 Enterprise is the paid, vendor-supported distribution of the Camunda 7 engine from Camunda. Its end of life was extended to April 9, 2030, with 7.24 as the 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. The Camunda 7 source repository is Apache-2.0 licensed, but the Enterprise line is what Camunda sells and supports.
- Paid status: Support and maintenance are a commercial agreement with Camunda, so the subscription is recurring.
- Patch rhythm: Updates on the 7.24 long-term support line arrive twice a year, in April and October.
- Lifecycle: Standard maintenance runs to April 9, 2030, and paid extended support runs from April 2030 through April 2032.
- Community status: Camunda 7 Community Edition receives no further releases or security patches after 7.24, so Enterprise is the only vendor-patched path from Camunda.
- Cost drivers: Price depends on the agreement, so request the contract terms, the included support hours and the extended support pricing in writing.
Before signing, confirm the exact support window, what counts as a security fix versus a feature, and whether extended support pricing is fixed or renegotiated in 2030.",
The CIB seven Community edition is the free, open-source distribution of the CIB seven fork. CIB seven's source files are made available under the Apache License Version 2.0, and the project's FAQ says the software may be used free of charge in commercial software, at least for its core functions. CIB software also states that it has provided support and maintenance for the Camunda 7 Community Edition since October 2025.
- Paid status: The Community edition is free to use, so the cost is staff time and infrastructure rather than a license fee.
- Patch cadence: Security patches and hotfixes for the paid distributions follow a 4 to 8 week cadence, and the Community tab does not carry the same commitment in the FAQ, so confirm what it receives.
- Responsibility: Your team owns testing, patching and upgrades unless you contract support separately.
- Scope: Confirm whether the core functions you rely on are covered by the free-use statement.
- Regulated use: The FAQ recommends the LTS edition for high-volume or regulated environments, so Community is a weaker fit for those workloads.
Ask CIB to state in writing what security response the Community edition receives and who answers a vulnerability report on it.
CIB seven Community+ is one of the paid editions described in the CIB seven FAQ, alongside LTS and Enterprise. It is positioned between the free Community edition and the higher-assurance paid distributions. The FAQ describes the paid editions as including security patches and hotfixes, which is the main reason to pay for this tier rather than run the free build.
- Paid status: Community+ is a paid subscription from CIB software, and the FAQ does not publish its price in the supplied material.
- Patch cadence: Security patches and hotfixes are released every 4 to 8 weeks, with urgent fixes released as needed for major security issues.
- Support duration: The FAQ gives no fixed support duration per edition, so ask CIB for the end date of support for this tier in writing.
- Feature scope: Confirm which functions are included compared with LTS and Enterprise.
- Upgrade path: Check whether moving from Community+ to LTS or Enterprise is a configuration change or a re-platforming effort.
Request a written statement of included patches, the support window and the service levels for response to urgent security issues.
CIB seven LTS is the paid long-term support edition that the CIB seven FAQ recommends for high-volume or regulated environments. It is the tier to evaluate first if your organization needs a stable release line with security patches over a long period. The FAQ still gives no fixed support duration for this edition, so the length of the commitment must come from CIB in writing.
- Paid status: LTS is a paid subscription, and its cost is set by CIB software in the quote.
- Patch cadence: Security patches and hotfixes follow the 4 to 8 week cadence, with urgent fixes released as needed for major security issues.
- Regulatory fit: The FAQ specifically recommends this edition for regulated environments, which makes it the natural reference point for audit-facing teams.
- Support window: No fixed duration appears in the FAQ, so ask CIB for the exact end date of support for the release you plan to run.
- Operating cost: Your team still pays for testing and rolling out each patch within your change process.
Ask for the support end date, the patch notification process and a written statement of what happens if a patch breaks your deployment.
CIB seven Enterprise is the top paid edition in the CIB seven range. The FAQ says CIB seven Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2, which makes it the closest functional match for teams currently on Camunda 7 Enterprise. Enterprise carries the same 4 to 8 week patch cadence for security patches and hotfixes, with urgent fixes released as needed.
- Paid status: Enterprise is a paid subscription from CIB software, priced through a quote.
- Feature parity: Version 2.1.2 and later are stated to offer all Camunda 7 Enterprise features, so verify the features you use against that version.
- Patch cadence: Security patches and hotfixes are released every 4 to 8 weeks, with urgent fixes as needed.
- Support duration: The FAQ gives no fixed duration per edition, so the support term must be stated by CIB in writing.
- Cost comparison: Compare the Enterprise quote with Camunda 7 Enterprise, including the extended support period you would need.
Before comparing quotes, request a written feature mapping against your current Camunda 7 Enterprise usage and a written support end date.
What drives the running cost of each path
The running cost of staying on the Camunda 7 codebase depends first on who is paid for support and who is paid for effort. On the Camunda side, the Camunda 7 Enterprise subscription buys vendor maintenance for the 7.24 long-term support line, with updates twice a year and paid extended support after April 9, 2030. On the CIB seven side, CIB software sells LTS and Enterprise support for its own distribution, and the CIB seven FAQ describes Community, Community+, LTS and Enterprise editions without publishing a fixed price or support duration per edition. Your internal platform team or a partner is paid for everything the subscription does not cover: running the migration, testing process applications, updating the application server and database, and absorbing each patch. Confirm with each vendor which of these items their fee includes and which you carry yourself.
The one-time costs cluster around the move itself. Migrating to CIB seven means first bringing a project up to the matching Camunda baseline (7.23.0 for CIB seven 2.0, 7.24.0 for CIB seven 2.1), then running the OpenRewrite script that updates Maven coordinates and changes imports from org.camunda to org.cibseven, along with the Liquibase changelog path. The larger effort is usually the work the script does not do: finding database rows that still reference org.camunda classes, such as script tasks and serialized variables, and testing scripting or reflection paths while the namespace compatibility properties stay disabled by default. Budget for repeated test cycles against your real process models and for database compatibility checks on the engines you run, including PostgreSQL, Oracle or SQL Server, as listed on the supported environments page.
The recurring costs are the ones that persist for as long as you run the platform. Subscription fees, where they apply, repeat each contract period. Patch intake is recurring: CIB seven's paid distributions ship security patches and hotfixes every 4 to 8 weeks, so someone must test and deploy each release on a schedule your change process allows. Infrastructure, Java runtime upgrades (CIB seven 2.2 supports Java 17 and 21), database version upgrades and application server changes repeat as well. Before you accept a quote, ask the vendor for a written statement of what the fee covers, the patch delivery method, the support hours and escalation path, and the Java and database versions covered for the contract term. Ask your partner for a fixed-scope estimate that separates migration, testing and first-year upgrade work, and confirm the exact figures directly with each vendor. This section gives no price figures.
Moving from Camunda 7 to CIB seven in order
This sequence takes a Camunda 7 process application from its current baseline to CIB seven with the dependency, package and schema changes made in a known order, and with a test record that shows the application still runs on the target stack.
Confirm the Camunda 7 baseline
Confirm which Camunda 7 version your application runs on before touching any code. CIB seven's migration guide says the CIB seven 2.1 backend is based on Camunda 7.24.0 and CIB seven 2.0 on Camunda 7.23.0, and that projects on older Camunda versions must first update to the matching baseline. Your engineering lead checks the Maven dependency tree and the engine version in the running environment. Done means you have a written baseline, the target CIB seven line, and a list of any upgrade needed first. Ask the CIB seven team to confirm the path for your version before you commit to a date.
Inventory BPMN, DMN and form assets
List every BPMN process, DMN decision table, form and custom Java delegate, listener or script in the application. Process models and the process data model are expected to transfer unchanged, so this inventory is mainly to find the parts that do reference Camunda classes. Mark each Java class, expression, script task and variable that names an org.camunda type. Done means you have a register separating assets that carry over as-is from assets that need code or configuration changes, reviewed by the team that owns the process logic.
Run the OpenRewrite migration script
Run the OpenRewrite-based migration script that CIB seven provides to update Maven versions, artifact names and imports. Run it on a branch, in a version-controlled repository, so every rewritten file appears in a diff. The developer who owns the build reviews the diff for dependency coordinates and for any import that the script did not reach. Done means the project compiles against the CIB seven artifacts with no remaining org.camunda imports in your own code, and the diff is approved.
Change the Liquibase changelog path
Update the Liquibase changelog path from org/camunda to org/cibseven, as described in CIB seven's migration guide, and check any custom changelog or configuration that points to the old path. The database administrator and the developer review the change together, since a wrong path can cause schema management to fail at startup. Done means a clean startup against a copy of the production schema, with the Liquibase log showing the expected changelog path and no unexpected schema changes.
Address objects already stored in the database
Find objects that are already persisted and still reference org.camunda classes, such as script tasks or variables that hold serialized Camunda types. The migration guide says these are not renamed automatically, so they need an explicit decision for each one: rewrite the stored data, convert the object to a neutral type, or retire the process instance before cutover. The data owner and the process owner sign off on each decision. Done means a query against the database returns no unhandled references to org.camunda, or each remaining reference has a documented owner and plan.
Decide on namespace compatibility properties
Decide whether scripting and reflection code needs the namespace compatibility properties that CIB seven documents. These are disabled by default. Enable them only for the scripts or reflective calls you inventoried, because they keep old package names working and can hide code that still needs a rename. Record the decision and the reason in the migration log. Done means every enabled property has a named owner, a link to the code that needs it, and a plan to remove it once that code is updated.
Rebuild custom interface and reflection code
Rebuild the parts that do not transfer: integrations with the Camunda Tasklist, Cockpit or Admin modules, and any custom web interface or reflection code that depends on Camunda internals. From version 2.0, CIB seven ships its own user interface for task lists, process monitoring and user and rights management, so decide whether each integration moves to that interface or to your own front end. Developers and the operations team agree on the replacement. Done means each replaced integration passes its own tests and nothing in the running system calls the removed Camunda modules.
Test on the target database and application server
Test the migrated application on the database and application server you will run in production. CIB seven's supported environments page lists combinations such as PostgreSQL 15 to 18 on Apache Tomcat 11.0, and the team should confirm the exact pairing against that page. Run process deployment, long-running instances, human tasks, timers and a rollback rehearsal. The quality lead signs off on a test report covering each process family. Done means the migrated application passes the agreed test set on the production combination, and the rollback path has been exercised.
Where CIB seven migrations usually run long
The effort in a CIB seven move rarely sits in the Maven change itself. It sits in everything that refers to the old namespace. The documented path renames Java imports from org.camunda to org.cibseven and moves the Liquibase changelog path from org/camunda to org/cibseven, and the OpenRewrite script covers Maven versions, artifact names and imports. Custom code, test suites and helper libraries that the script does not reach still need manual review. The bigger risk is data. Script tasks, variables and other objects already stored in the database that reference org.camunda classes are not renamed automatically, so a model that looks migrated can still fail at the first execution of an old instance. Plan a search of the BPMN and DMN assets, the process variable inventory and any stored serialized values, and decide in advance how each finding is handled. The namespace compatibility properties for scripting and reflection exist, but they are disabled by default, and turning them on is a decision with its own testing scope.
Database and runtime validation adds a second layer. CIB seven publishes a supported environments list that pairs Java 17 or 21 with specific database versions and application servers, so the team must confirm that its production database, driver and servlet or application server are on that list before the schema work starts. Teams that run Oracle, SQL Server or IBM DB2 should verify their exact versions with CIB, because the list is narrower than what most enterprises already operate. The second layer is operational. If your current Camunda 7 deployment uses Cockpit, Tasklist or Admin for monitoring, task handling or user and rights management, those workflows must be rebuilt on CIB seven's own interface or on other tooling. That means new access roles, new audit evidence and retraining for operators and business users. Staff who know the Camunda 7 web applications will need time to learn the replacement, and access control changes need their own review.
The work needs three skill sets working together: Java and Spring or application server engineers who can read the custom code, database administrators who can validate the schema change and rollback path, and release managers who can sequence the changes across environments. Regression testing should cover every process definition in production, including long-running instances that started before the cutover. Before starting, ask CIB which 2.x line and edition fit your support requirements, what patch cadence applies to the edition you buy, and whether the migration script has known gaps for your code patterns. Ask Camunda whether any support terms change for your current Enterprise contract if you leave the Camunda 7 codebase, and confirm your exit options in writing. Put these answers into the scope document before fixed-scope work is agreed, so the effort estimate reflects your actual code and data rather than the happy path.
Questions buyers ask before they choose a Camunda 7 path
How much does a CIB seven migration cost?
No single figure applies, because the cost depends on the size of your Camunda 7 estate and the work around it. CIB seven's software is Apache-2.0 licensed and its FAQ says the core functions may be used free of charge in commercial software, so the licence itself is not the main line item. The costs that matter are engineering time to update the Camunda baseline, run the migration script and test, any paid CIB seven edition you choose, and outside help if you buy it. Ask for a written quote that separates one-time migration work from recurring support, and ask which CIB seven edition the quote assumes.
How long does a CIB seven migration take?
The duration depends on how far your project sits from the supported baseline and how much custom code touches the engine. CIB seven's migration guide says projects on older Camunda versions must first move to the matching Camunda baseline, so a team on an older release adds a step before the fork swap. The main drivers are the number of process applications, custom Java delegates, scripts, and stored objects that reference org.camunda classes, plus the regression testing your change control requires. Agree the duration in a written scope rather than relying on a generic estimate.
Can our team migrate to CIB seven without outside help?
Yes, a team with Java and Maven experience can often do it in-house, provided it has the test coverage to prove behaviour is unchanged. The documented path includes an OpenRewrite-based script that updates Maven versions, artifact names and imports, and the migration guide covers the Liquibase changelog path change. Teams that lack that depth, or that run many process applications on a regulated timeline, often buy implementation help. DeployOpen plans, implements and tests self-hosted platforms in the client's own infrastructure, and works from a fixed written scope if you choose that route.
Does the OpenRewrite script cover everything in a CIB seven migration?
No, the script covers the mechanical changes and not the stored or dynamic ones. It updates Maven versions, artifact names and imports, but CIB seven's migration guide warns that objects already in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically. The guide also offers namespace compatibility properties for scripting and reflection, which are disabled by default, so you must decide whether to enable them and test that choice. Review your database contents, scripts and reflective code paths separately from the recipe output.
Do we need CIB seven LTS for a regulated environment?
The CIB seven FAQ recommends the LTS edition for high-volume or regulated environments, so that is the vendor's stated guidance and a strong starting point. The FAQ describes security patches and hotfixes for paid distributions every 4 to 8 weeks, with urgent fixes released as needed for major security issues, but it gives no fixed support duration per edition. Whether LTS satisfies your internal policy, or an assessor's expectations, is a question for your compliance function and your auditor. Ask CIB software for the support end date of the edition you plan to run.
What should a CIB seven support contract state?
A support contract should state the covered edition and version, the patch cadence, the severity levels and response expectations, and the end date of support for that release. Because the FAQ gives no fixed support duration per edition, get that end date in writing rather than inferring it from the release cadence. Also confirm which supported databases and runtimes are covered, such as the PostgreSQL 15 to 18 range or Tomcat 11.0 listed in the supported environments page, and whether Helm charts or Kubernetes guidance are included. Ask how upgrades between CIB seven releases are handled and whether that work is priced separately.
What changes for engineers once CIB seven ships its own web interface?
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. Engineers should check which screens, roles and custom plugins their operators rely on, because those views will be served by a different application after the move. Confirm that your identity and access setup maps cleanly to the new user and rights management before cutover. Test operator workflows in a non-production environment with real user roles.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, so the Camunda 7 vs CIB seven decision is made on the client's workloads and compliance needs rather than on a preferred product. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the Camunda 7 version, embedded or shared engine use, and custom code that references org.camunda classes
- Confirm the target database, Java runtime and application server against the vendor's supported environment lists
- Record which Cockpit, Tasklist or Admin features your operators rely on before choosing a path
- Agree in writing whether the work covers a migration, a support model decision, or both
How we build
- Run the CIB seven OpenRewrite migration script against a copy of the codebase in a non-production environment
- Review Liquibase changelog path changes and any stored objects that still reference the old package names
- Test scripting and reflection paths with namespace compatibility settings and document each one kept enabled
- Validate process instances, history and external task workers against the chosen baseline before cutover
How we hand over
- Deliver a written record of the baseline, versions, edition chosen and every package and schema change made
- Document the rollback path and the steps to return to Camunda 7 Enterprise or another fork if needed
- Provide runbooks for deployment, database backup and upgrade so your team can operate the platform
- Map the evidence produced for your internal change records or external auditors, without issuing any attestation
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the migration
- Plan patch intake against the editions' published security patch cadence and your own change windows
- Re-test the platform after each vendor patch or fork release before it moves to production
- Ask any support provider to confirm response terms, support duration and coverage in writing before signing
