Migrate from Camunda 7 to CIB seven: what the move involves
If you run a Camunda 7 Community or Enterprise application and need to leave the end-of-life track, the choice is usually between a Camunda 8 re-platform and a Camunda 7 fork. CIB seven keeps the embedded Java engine, so the application stays a Java process with the same in-process model, and the work is mostly package renames, aligning to the correct Camunda baseline, and fixing stored objects. The effort is generally bounded by how much custom code, stored script and database state your application carries, not by a rewrite of the process model. The starting point is to confirm which Camunda 7 version you run, because CIB seven's migration guide says projects on older Camunda versions must first update to the matching Camunda baseline. The CIB seven 2.1 backend is based on Camunda 7.24.0 and 2.0 on Camunda 7.23.0, so a team on an earlier 7.x release has an extra upgrade step to plan and test.
In most organizations an internal platform or middleware team does the migration, with an implementation partner brought in for the parts that are unfamiliar: the database migration, the OpenRewrite run across several repositories, or the Helm and Kubernetes packaging. The partner's role is defined in a written scope, so confirm who owns the code changes, who runs the regression tests and who signs off on the cutover. Risk sits in three places: classes and scripts that are stored in the database and are not renamed automatically, variables that reference org.camunda classes, and reflection or scripting code that depends on the old namespace. The CIB seven guide offers namespace compatibility properties for scripting and reflection, but they are disabled by default, so decide deliberately whether to enable them during the transition. Confirm the exact effort with the vendor and your own environment before you commit to a timeline.
Which Camunda 7 capabilities move cleanly to CIB seven
This table maps the Camunda 7 capabilities your application depends on to their status in CIB seven, the fork of the Camunda 7 Community Edition. Clean means the capability carries over with the standard migration script, needs rework means code or stored data must change, and confirm means verify in the CIB seven FAQ and your own test environment before you commit. Confirm CMMN coverage and any Camunda Enterprise-only features first, because they decide whether the fork fits your application.
| Capability | Status | What to do |
|---|---|---|
| BPMN 2.0 process engine | Clean | CIB seven's core is a native BPMN 2.0 engine in the JVM. Run the OpenRewrite script, then regression test each process. |
| CMMN and DMN engines | Confirm | Camunda 7 supports CMMN and DMN. Check CIB seven's CMMN coverage in its FAQ and test every decision table on the new baseline. |
| REST API | Confirm | Verify endpoints, payloads and client libraries against the CIB seven manual. Update client code that imports org.camunda classes. |
| Tasklist, Cockpit and Admin | Needs rework | CIB seven 2.0 and later ship their own task list, process monitoring and user rights UI. Retrain operators and rebuild custom Tasklist forms. |
| Database persistence through MyBatis | Clean | Confirm your database and version appear in the CIB seven supported environments list, such as PostgreSQL 15 to 18 or Oracle 19c. |
| Java delegates and external task clients | Confirm | Rename org.camunda imports to org.cibseven. Confirm the external task client version your workers use is supported on the new baseline. |
| Spring Boot and Quarkus setups | Needs rework | The FAQ lists both setups. Update dependency coordinates and container images, and confirm the Helm chart plan for Kubernetes. |
| Stored scripts and variables | Needs rework | Objects already in the database that reference org.camunda are not renamed automatically. Plan a data update and test script tasks. |
| Camunda Enterprise-only features | Confirm | The FAQ says CIB seven Enterprise offers all Camunda 7 Enterprise features from version 2.1.2. Confirm which features you use before choosing an edition. |
What data and integrations to move and rebuild
A Camunda 7 to CIB seven move touches four layers: the database, the deployed models, the custom Java code and the surrounding identity and integration setup. Each layer has a different migration path, and only some of them are automated, so the inventory should come before the schedule.
Running instances and history
CIB seven's migration path starts from a Camunda 7 database at a matching baseline, then applies the schema changes through its own Liquibase changelog. Confirm with your DBA which database engine and version you run, because the supported environments list is specific about versions. Count active instances, open jobs and history volume per process definition, since these set the length of the cutover window. Do not assume running instances move without a tested rehearsal on a copy of production data.
Deployed BPMN and DMN models
Process and decision definitions that are already deployed carry Camunda 7 namespaces and expression syntax. The OpenRewrite script updates Maven coordinates, artifact names and Java imports, but it does not rewrite the model files themselves. Export every deployed definition, diff it against the source repository, and check that each DMN table still evaluates the same inputs. Keep a list of the versions in production so you can test the exact set that will run.
Liquibase changelog path
The changelog location changes from org/camunda to org/cibseven, so any tooling, deployment script or custom Liquibase configuration that points at the old path will fail or apply the wrong set of changes. Search your build files, Helm values and CI pipelines for the old path before the first run. Record the changelog state of the existing schema so that the upgrade starts from a known point.
Custom plugins and Java delegates
Process engine plugins, execution listeners, Java delegates and custom job handlers are compiled against org.camunda packages. The OpenRewrite script covers imports in source code, but any class that is loaded by name, referenced from XML or produced by a separate library needs its own check. Inventory each plugin, decide whether it is rebuilt or retired, and run the unit and integration tests against the new engine version.
Stored scripts and variables
The migration guide states that objects already stored in the database are not renamed automatically. Script tasks, serialized variables and expressions that reference org.camunda classes will keep the old names until someone changes them. Review every stored script task and every variable type in the history and runtime tables, and decide whether to edit, re-deploy or replace each one. The namespace compatibility properties exist for scripting and reflection, but they are disabled by default, so enabling them is a deliberate decision to document and test.
Identity, authorization and external integrations
Users, groups, authorizations and tenant assignments live in the Camunda 7 tables and in any LDAP, SSO or identity provider adapter wired to the engine. CIB seven ships its own user interface for task lists, monitoring and user and rights management, so the Camunda Tasklist, Cockpit and Admin screens are replaced rather than carried over. Map each authorization rule to its new home, and test every REST client, message correlation and connector that calls the engine, since their endpoints and credentials must still work after the upgrade.
The migration sequence from inventory to decommission
This sequence moves a Camunda 7 application onto CIB seven in a controlled order, so each change is tested on a copy before production and the old application is retired only after the new one has proven itself. Each step closes with a record that the next step depends on.
Inventory the Camunda 7 estate
The application owner and engineering lead list every Camunda 7 deployment with its exact Camunda version, the BPMN, CMMN and DMN files, custom Java delegates and listeners, plugins, scripts, forms, REST API consumers and the database vendor and schema version. They also record which objects are already stored in the database, such as script tasks and variables that reference org.camunda classes, because the migration guide says these are not renamed automatically. The output is a dated inventory list with one owner per item. The step is done when every running process definition and every external caller appears on the list and the team has confirmed nothing is missing from the deployment pipeline.
Update to the matching Camunda baseline
Before any CIB seven change, the engineering team moves the application to the Camunda baseline that matches the target CIB seven line. According to CIB seven's Camunda migration guide, the 2.1 backend is based on Camunda 7.24.0 and the 2.0 backend on Camunda 7.23.0, and projects on older versions must first update to the matching baseline. The team runs the existing test suite against that baseline and confirms the application starts, deploys its models and completes a set of representative process instances. The output is a build that passes the existing test suite on the baseline version, tagged in source control so the next steps have a clean starting point.
Run the pilot on a non-production copy
The team restores a copy of the production database to a non-production environment and runs the migration there first. Using the supported environments list, they confirm the Java version, database vendor and version, and application server or Spring Boot or Quarkus setup match what they intend to run in production. They then execute the OpenRewrite script, rename the Liquibase changelog path and start the application against the copied data. The output is a pilot test report that lists every failing process instance, stored script, variable and external integration, with an owner and a fix for each. The pilot is complete when the test report has no open items that affect production behavior.
Apply the OpenRewrite script and Liquibase path changes
On the working branch, the developers run CIB seven's OpenRewrite-based migration script, which updates Maven versions, artifact names and Java imports from org.camunda to org.cibseven. They then move the Liquibase changelog path from org/camunda to org/cibseven and review every change the script made, since automated rewriting can miss reflection, string-based class names and scripts stored in the database. Any remaining references are fixed by hand or handled with the namespace compatibility properties, which are disabled by default and should be enabled only as a documented, time-limited measure. The output is a reviewed pull request with a changelog of rewritten files and a list of manual fixes, and the build passes the test suite on CIB seven.
Run the parallel period and cut over
For a defined parallel period, the new CIB seven environment receives the same business inputs as the legacy Camunda 7 application, or the team runs new instances on CIB seven while existing instances finish where they are, depending on the design agreed in the pilot. The operations team compares process outcomes, task routing, job execution and performance against the baseline and records any deviation. The cutover checklist is signed off by the process owner, the security team and operations. It covers backup and restore tests, rollback steps, user access, monitoring, and the final database migration window. The output is a signed-off cutover checklist and a rollback plan that has been rehearsed on the non-production copy.
Decommission the Camunda 7 application
Once the cutover checklist is closed and the agreed stabilization period has passed without blocking defects, the team stops scheduling new work on the Camunda 7 application and disables its endpoints. They retain a read-only, access-controlled copy of the database and the final process history for the retention period set by the organization's records policy. Credentials, service accounts and integration routes that pointed at the old engine are removed, and the infrastructure is released. The output is a decommission record that lists retired components, where archived data is stored, who approved the retention, and the date each step was completed.
How to run both engines in parallel and cut over safely
The safest cutover keeps Camunda 7 running for instances already in flight and sends only new process starts to CIB seven, at least until you have confirmed that the CIB seven side behaves correctly under real load. Letting running instances finish on Camunda 7 means the old engine, its database and its Tasklist, Cockpit and Admin consoles stay operational for as long as those instances need, so the operational risk is spread out instead of concentrated on a single switch date. The alternative is to move state through a supported path, which means running instance migration and history handling for your exact version. Confirm that approach against the CIB seven manual for your version, because the supported migration path, the minimum Camunda baseline and the handling of history data are version-specific and this section does not replace that check.
Routing new starts is the main control in a parallel run. Keep the routing decision in one place, such as a feature flag, a configuration property or a gateway rule, so that you can move a single process definition, a tenant or a percentage of traffic back to Camunda 7 without a redeploy. Where a process is started by a message or by a Java delegate, make sure both engines cannot start the same business case twice. Monitoring both engines needs its own dashboards: running and failed job counts, incidents, stuck timers and the age of the oldest open instance on each side. Because CIB seven ships its own task list, process monitoring and user management, decide early which console your operations team will use during the overlap period and which one is the system of record for each user.
The database work depends on whether the two engines share a schema. A separate schema or database for CIB seven is the simpler choice for a parallel run, because the Camunda 7 tables stay untouched and the rollback path is a routing change rather than a data restore. A shared schema needs a written review of the Liquibase changelog path, the migration script's effects on the database and the backup point you can restore to. Whichever you choose, take and test a full backup of the Camunda 7 database before the first new start on CIB seven, and keep it until the last Camunda 7 instance has finished. Define the rollback trigger in advance, such as a threshold of failed jobs or a defined incident category, and rehearse the reroute in a non-production environment.
What drives the cost and duration of the migration
This table lists the factors that most change the effort of moving a Camunda 7 application to CIB seven, with the reason each matters and how to reduce it. Use it to scope your own estimate and to check that a quote covers the work that actually drives the schedule.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Baseline version gap | CIB seven 2.1 is based on Camunda 7.24.0 and 2.0 on 7.23.0, so older Camunda 7 projects must first move to the matching baseline before the CIB seven migration starts. | Record your current engine version and ask the vendor or partner to quote the baseline upgrade as a separate step. |
| Java delegates, listeners and scripts | Each Java delegate, execution listener and script task must compile and behave the same against renamed packages, so the count sets the test and rework load. | Inventory every delegate and script in a list, group identical patterns, and migrate them in batches with a shared test set. |
| Stored objects that reference org.camunda classes | Script tasks, serialized variables and other objects already in the database are not renamed automatically, so they can fail at runtime even after the code compiles. | Query the database for org.camunda references before scoping, and decide per object whether to convert, re-deploy or use the namespace compatibility properties, which are disabled by default. |
| Custom plugins and engine extensions | Custom process engine plugins, cockpit or tasklist plugins and custom REST resources each need review against the CIB seven packages and its own user interface. | List each plugin, confirm which Camunda 7 Tasklist, Cockpit or Admin features your users depend on, and map them to CIB seven's built-in interface. |
| Camunda Enterprise features in use | CIB seven Enterprise offers Camunda 7 Enterprise features from version 2.1.2, so features in use decide which edition is needed and whether a feature has an equivalent. | Compare your enterprise feature usage with the CIB seven FAQ and ask the vendor to confirm coverage in writing before scoping. |
| Database engine and version | CIB seven 2.2 lists supported databases and versions, and a database outside that list, or an older version, adds a platform step and extra testing. | Check your database against the supported environments page and plan any upgrade before the code migration begins. |
| Number of applications sharing the engine | A shared engine serving several applications means every application's delegates, scripts and deployments must move together, which lengthens coordination and regression testing. | Split applications into migration waves where possible, and agree a cutover order with each owning team. |
| Test coverage and running instances | Weak automated tests force manual regression work, and in-flight instances must be checked for correct behavior after the switch. | Build a regression suite on the baseline first, and ask the quote to name how running instances will be drained or tested. |
| CIB seven edition choice | Community, Community+, LTS and Enterprise editions differ in patch cadence and support, and the FAQ recommends LTS for high-volume or regulated environments. | Decide the edition before scoping, and ask the quote to state which patch and support terms it assumes. |
What usually goes wrong and how to prevent it
Most failed Camunda 7 to CIB seven moves trace back to a short list of causes: a skipped baseline step, namespace leftovers in the database, and compatibility settings that were never turned on. Each card names one of these risks and the check that catches it before cutover.
Skipping the baseline update
CIB seven's migration guide says projects on older Camunda versions must first update to the matching Camunda baseline. The CIB seven 2.1 backend is based on Camunda 7.24.0 and 2.0 on Camunda 7.23.0, so a project still on an earlier 7.x release can fail in ways that look like CIB seven bugs. Before running any conversion, confirm the current Camunda 7 version in the POM, upgrade to the matching baseline, and run the full test suite on that intermediate version.
Org.camunda references in stored data
The migration guide warns that objects already stored in the database, such as script tasks and variables that reference org.camunda classes, are not renamed by the OpenRewrite script. Running instances can therefore fail when they resume, even though the source code compiles cleanly. Query the ACT_RU and ACT_HI tables and serialized variable values for org.camunda strings, and decide per item whether to rewrite it, republish the model or let the instance finish on its old definition.
Liquibase changelog path errors
Moving to CIB seven changes the Liquibase changelog path from org/camunda to org/cibseven. If the application still points at the old path, schema management can fail at startup or apply changes against the wrong state. Check every configuration file, Spring or Quarkus property and custom bootstrap class for the old path, then start the application against a copy of the production schema and confirm the changelog table reports the expected state.
Scripting and reflection needing compatibility properties
The namespace compatibility properties for scripting and reflection are disabled by default. Groovy, JavaScript or JUEL scripts, and Java code that loads classes by name, may still expect org.camunda types and fail only at runtime on a specific path. Inventory every script engine use and reflective lookup, decide which need the compatibility properties, and document why each setting is on. Treat any enabled setting as technical debt with an owner and a removal plan.
Unsupported database or server versions
CIB seven 2.2 lists supported combinations: Java 17 or 21, PostgreSQL 15 to 18, MySQL 8.0, MariaDB 10.6 or 11.8, Oracle 19c or 23ai, SQL Server 2017 to 2022, IBM DB2 11.5, and H2 2.3, on Tomcat 11.0, JBoss EAP 8.1 or WildFly 40.0. Teams often keep an older database or application server out of habit, and the mismatch surfaces during load or upgrade testing. Compare the current stack with the supported environments page before choosing the target platform, and budget time for a database upgrade if it is required.
Missing regression tests for process paths
Camunda 7 applications often rely on BPMN paths that are exercised only in production, such as timers, boundary events, compensation and error handling. Without regression tests, a successful build proves little about the process behavior after migration. Build a test set around each business-critical path, run it on the Camunda 7 baseline and again on CIB seven, and compare the resulting history and variables. Keep the tests as a release gate for later CIB seven upgrades.
How the migration differs by starting point
Teams on Camunda 7 Community Edition start from a line that no longer receives releases or security patches. The repository is archived and 7.24 is the last tag, so the first question is which Camunda baseline the application is on. CIB seven's migration guide says projects on older Camunda versions must first update to the matching Camunda baseline. CIB seven 2.1 is based on Camunda 7.24.0 and 2.0 on Camunda 7.23.0, so a team on an earlier 7.x release has a separate upgrade step before any CIB seven work begins.
- Baseline upgrade first: Move the application to the matching 7.x baseline and run the existing test suite before touching imports.
- Scope of change: Expect Maven coordinates, artifact names, Java imports and the Liquibase changelog path to change, handled largely by the OpenRewrite script.
- Stored objects: Script tasks and variables already in the database that reference org.camunda classes are not renamed automatically, so inventory them before cutover.
- Edition choice: The free Community edition is Apache-2.0, but the CIB seven FAQ recommends the LTS edition for high-volume or regulated environments, and paid editions carry security patches every 4 to 8 weeks.
- Runtime: Confirm the Java version and database against the CIB seven 2.2 supported environments list, such as Java 17 or 21 and PostgreSQL 15 to 18.
Before committing, confirm which Camunda 7.x version is in production and whether your database and application server appear in the supported list.
Teams on the Camunda 7 Enterprise Edition are not forced off the platform by an end-of-life date that has already passed, because Camunda extended Enterprise end of life to April 9, 2030, with paid extended support from April 2030 through April 2032. The migration to CIB seven is therefore a choice about cost and control, not a deadline. The CIB seven FAQ says CIB seven Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2, which is the main point to verify against your current feature usage.
- Feature parity: List every Enterprise feature in use and confirm it appears in the CIB seven Enterprise edition from version 2.1.2 onward.
- Subscription exit: Ask your Camunda contact what notice and renewal terms apply, and ask CIB seven for a written quote on the LTS or Enterprise edition.
- Support model: Compare the support and patch cadence of the replacement with your current Camunda Enterprise contract.
- Custom code: Plugins and listeners built on Enterprise-only APIs need separate review, since they may not be covered by the namespace migration alone.
- Interface: CIB seven 2.0 and later ship their own task list, monitoring and user administration, so plan replacements for Tasklist, Cockpit and Admin.
Before a renewal decision, confirm the Enterprise feature set you rely on and obtain written terms from both vendors.
Applications that embed the engine in Spring Boot or Quarkus package the process engine with the application, so the migration moves dependencies, configuration and code together. CIB seven's FAQ lists Spring Boot, Quarkus, Docker and Kubernetes setups, and CIB seven 2.2 supports Java 17 and 21 with Apache Tomcat 11.0 among the listed containers. Because the engine version is tied to the deployment, each service can move on its own schedule, which makes staged rollout practical.
- Dependency scope: Each service changes its own Maven coordinates and imports, so run the OpenRewrite script per repository.
- Testing: Run integration tests against a database that matches production, such as PostgreSQL or Oracle from the supported list.
- Configuration: Check Spring or Quarkus configuration keys and any Camunda-specific properties that still reference org.camunda names.
- Deployment: Use the Docker or Kubernetes setup and confirm the Helm chart status, since the FAQ says Helm charts are in preparation.
- Rollback: Keep the Camunda 7 build deployable until in-flight instances are verified on the new engine.
Confirm your framework version and database against the supported environments page before choosing a target.
Teams that run a shared process engine on an application server, such as Apache Tomcat, JBoss EAP or WildFly, move one engine that serves several applications. The migration is therefore coordinated: every deployed application that uses the shared engine must change in the same window, or the engine and its clients will disagree about namespaces. CIB seven 2.2 lists Apache Tomcat 11.0, JBoss EAP 8.1 and WildFly 40.0 as supported application servers, so confirm that your server version appears in that list before planning.
- Coordinated cutover: Inventory every application that calls the shared engine and schedule them together.
- Server version: Check that the application server version matches the supported list, not only its major line.
- Database schema: Plan the database upgrade and back up the schema before running the Liquibase path change.
- Shared UI: Decide whether CIB seven's own task list and monitoring replace the Camunda web applications for all users.
- Operating model: Ask whether your platform team or CIB seven support will own patching, since shared engines concentrate risk.
Before scheduling, confirm the application server and database versions against the CIB seven 2.2 supported environments page.
Questions teams ask before migrating to CIB seven
How much effort and cost does a Camunda 7 to CIB seven migration involve?
The main cost is internal and partner engineering time, because the CIB seven software itself is Apache-2.0 licensed and can be used free of charge in commercial software, at least for its core functions. The effort depends on how much custom code, how many stored BPMN models, scripts and variables reference org.camunda classes, how many Camunda 7 modules you use (Tasklist, Cockpit, Admin, REST API), and how far your Camunda version sits from the baseline. Recurring costs include support, patches and hosting. Ask any partner for a fixed-scope quote built from a written inventory of these items, and ask CIB seven about the fees for its paid Community+, LTS or Enterprise editions, which the CIB seven FAQ describes.
How long does a CIB seven migration take?
No duration figure is supplied for this migration, so treat any timeline as something to confirm against your own inventory. The timeline is set mainly by the Camunda baseline gap, the number of applications and process definitions, the amount of custom Java code and stored scripts that need renaming, the testing you require, and your release freeze windows. Projects on older Camunda versions must first update to the matching Camunda baseline before migrating, which adds a step. Ask for milestones tied to each application and a test exit criterion in the written scope.
What does the work require from our internal team?
Your team needs Java and Maven skills to run the migration script, review its changes and fix code, plus database skills for the Liquibase changelog path change and the stored objects that the script does not rename. Someone must own the inventory of models, scripts, variables and external integrations, and someone must run regression tests on each affected process. Operations staff need to plan the database and runtime change, and the security or compliance owner should review the new edition and patch process. The CIB seven migration guide lists the exact import and path changes you will need to verify.
Can our internal team do the migration alone?
Many teams with strong Java and Camunda 7 experience can run the OpenRewrite script and the manual fixes themselves, especially for a small number of applications. Teams with many applications, heavy scripting, unusual database vendors or a regulated change process often bring in an implementation partner for the inventory, the baseline update, test planning and the cutover. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and works from a written, fixed scope agreed before work starts. Whichever route you choose, confirm the database and application server combinations you run against the supported environments list.
Is the CIB seven Community edition enough for regulated workloads?
The Community edition is free and open source, but the CIB seven FAQ recommends its LTS edition for high-volume or regulated environments. The paid Community+, LTS and Enterprise editions include security patches and hotfixes, which the FAQ says are released every 4 to 8 weeks, with urgent fixes released as needed for major security issues. The FAQ gives no fixed support duration per edition, so ask CIB seven for the support window of the edition you select. CIB seven Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2. Confirm the edition details on the CIB seven FAQ before you decide.
What happens to running process instances during the migration?
Running instances stay in the database, so the migration must carry their state across to the new engine schema and classes. Objects already stored in the database, such as script tasks or variables that reference org.camunda classes, are not renamed automatically, so you must find and fix them before cutover. CIB seven offers namespace compatibility properties for scripting and reflection, which are disabled by default, and you should enable them only after reviewing their effect. Plan a drain or a tested cutover for in-flight work, and rehearse it on a copy of production data.
How does CIB seven compare with Operaton for a Camunda 7 team?
Both are Apache-2.0 forks that keep the embedded Java engine model that Camunda 7 teams know. CIB seven is the Camunda 7 Community Edition fork maintained by CIB software and, since version 2.0, ships its own user interface for task lists, process monitoring and user and rights management. Operaton is also built from the Camunda 7 codebase, provides a compatible REST API, database schema and deployable models, and offers an OpenRewrite recipe for migrating from Camunda 7. Its repository is the source to check for its own compatibility statements. The choice often comes down to the operations model you want, the support you can buy, and which fork's migration path fits your application inventory.
How DeployOpen scopes and runs a CIB seven migration
DeployOpen scopes a CIB seven migration in writing before any work starts. DeployOpen is a Chainscore Labs company. It plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Camunda 7 move, the written scope usually names the source Camunda 7 baseline version, the target CIB seven release, the database engine and its version, the application server or Spring Boot and Quarkus setup, the number of applications and process definitions, and whether the CIB seven user interface replaces the Camunda Tasklist, Cockpit and Admin modules. Each deliverable is listed with its acceptance check, and timelines are agreed alongside it. Most engagements are fixed-scope, so the decisions above need an owner on the client side before the scope is signed.
Quotes follow from that written scope. DeployOpen does not publish a price list, so the cost components are the things to ask about: the discovery and inventory of Camunda 7 code, stored scripts and variables, the OpenRewrite-based conversion and its review, testing against the chosen database, the choice between CIB seven's free Community edition and its paid Community+, LTS or Enterprise editions, and the hardening and backup work in the client's environment. Ongoing support, upgrades and continuous testing are available as separate retainers after go-live. Ask for the scope, deliverables, timelines and the retainer terms as separate line items so that one-time migration work and recurring support can be compared. DeployOpen is not a CIB software or Camunda partner, reseller or certified provider unless that status is stated in writing. Where a compliance assessment follows the migration, DeployOpen prepares systems, controls and evidence. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
