How much migration effort does Camunda 7 to Camunda 8 really take?
A team running Camunda 7.24 with Enterprise support to April 9, 2030 can treat the move to Camunda 8 as a re-platforming project, not a version upgrade. Camunda provides the Diagram Converter, which analyzes Camunda 7 BPMN, DMN and form files, lists the migration tasks and converts them to the Camunda 8 format. The converter covers the process models, but the effort sits in what it does not carry: Java delegates and listeners, the embedded engine's REST and Java API calls, history data, and the production license you need for Camunda 8 Self-Managed. Those items drive the budget, so the question is less about the diagrams than about the code around them. The effort depends on three things you can measure before committing. First, the process inventory: count the deployed definitions, the active instances that must finish on 7.x or be restarted, and the history retention you actually need to keep. Second, the Java and Spring integration: list every service task implementation, custom listener, embedded plugin and application that calls the engine API, because each one is rewritten against Camunda 8 clients and connectors. Third, licensing: the Camunda License 1.0 limits use to non-production environments, so production use requires the Self-Managed Enterprise Edition. Ask Camunda for a written quote covering that license.
Set that against the staying options in your own environment. Flowable offers a separate migration path, described in a Flowable engineering post on escaping legacy engines, and Camunda 7 Enterprise remains supported to 2030 with paid extended support to 2032. For the wider architecture comparison between the embedded relational engine and Zeebe, see the companion Camunda 7 vs Camunda 8 page. Before you decide, confirm with Camunda and with your own test environment which converter output needs manual rework, and get a fixed scope for the code changes, since those costs recur only if the process estate keeps changing.
Which migration effort parts change between Camunda 7 and Camunda 8
This table breaks the Camunda 7 to Camunda 8 Self-Managed move into components and shows what changes in each, with a row for a compatible fork that keeps the Camunda 7 API and schema. Read each row as a question to answer in your own inventory of models, code and running instances. The main takeaway is that the model files have a converter, while the engine, Java code, persistence and operations tooling each need separate planning.
| Component | Camunda 7 (source) | Camunda 8 Self-Managed (target) |
|---|---|---|
| Model files (BPMN, DMN, forms) | Process, decision and form files as used by the Camunda 7 engine | The Diagram Converter analyzes Camunda 7 BPMN, DMN and forms, lists migration tasks and converts them to the Camunda 8 format |
| Engine architecture and persistence | Java process engine persisting to a relational database through MyBatis | Zeebe, a cloud-native process engine that runs without a relational database for its core operation |
| Java API and code | Java API of the embedded or shared engine | Different APIs and clients, so application code that calls the engine needs rework; confirm scope with your code inventory |
| REST and integration points | REST APIs shipped with Camunda 7 | Integration through the Camunda 8 clients, connectors and Kafka or other message queues; confirm each endpoint and connector in use |
| Running history and active instances | Active process instances and history stored in the Camunda 7 database | Confirm with Camunda which in-flight instances and history can be carried over, and plan how to drain or finish them before cutover |
| Operations tooling | Tasklist, Cockpit and Admin web applications | Tasklist, Operate and Identity, with Self-Managed teams deploying and securing the stack on their own Kubernetes or cloud infrastructure |
| Production licensing | Enterprise Edition support to April 9, 2030, per Camunda's announcement | Production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition, and the Camunda License 1.0 limits use to non-production without it |
| Compatible fork (Operaton or CIB seven) | Keeps the Camunda 7 API and database schema, so application code and data stay largely in place | Not applicable; the fork path avoids the Camunda 8 model, API and persistence changes, but the fork's own support window needs checking |
What makes the Camunda 7 to Camunda 8 move cost more or less
The effort of moving from Camunda 7 to Camunda 8 depends less on the engine itself than on what your processes and operations depend on. The cards below cover the drivers that push effort up or down, so you can size the work from your own inventory before asking for a quote.
Volume and complexity of model files
Every BPMN, DMN and form file is a unit the migration must analyze, convert and retest. The Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, lists the migration tasks it finds and converts them to the Camunda 8 format, so a large estate with many exotic elements means more manual review after conversion. Effort rises with the count of files that use constructs the converter flags. Ask for a per-file report from a trial conversion before committing to scope.
Depth of Java delegate code
Service tasks, execution listeners and task listeners written as Java delegates run inside the Camunda 7 engine's JVM. Camunda 8 runs job workers outside the engine and calls them through its client APIs, so each delegate needs a new worker design, and any shared state or transaction assumptions must be reworked. Effort rises with the amount of logic that lives in delegates rather than in the model. Ask the team to count delegates and classify them by what they call.
Dependence on the embedded relational engine
Camunda 7 persists process state through MyBatis into a relational database, and applications often query its tables directly for reporting or custom dashboards. Camunda 8 is built around Zeebe, which the camunda/camunda README describes as horizontally scalable without a relational database, so those queries, custom schema joins and database-level integrations have no direct equivalent. Effort rises with every system that reads Camunda 7 tables. List them early, because each one becomes a redesign rather than a configuration change.
Active instances that must finish or move
Running process instances, their history and open human tasks are the hardest part of cutover. You can let instances complete on Camunda 7 while new work starts on Camunda 8, which keeps two platforms running for as long as the longest instance lasts, or you can migrate in-flight state, which requires a tested mapping for every version of every model. Effort rises when instances are long-lived or cannot be drained. Ask how many instances will still be active on the cutover date and how long the longest one can run.
Kubernetes and operations skills
Camunda 8 Self-Managed is deployed by the customer on their own Kubernetes clusters or cloud infrastructure, and Camunda documents Helm, Docker and manual installation methods. The customer then deploys, scales, secures and updates the whole stack. Camunda 7 teams that have run an application server and a relational database often lack this skill set, so training, platform build and runbook work become part of the move. Effort rises when the team has no Kubernetes operating experience. Confirm which of these skills exist in-house before deciding who builds the platform.
Production licensing and Enterprise Edition
The Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation. Production use of Camunda 8 Self-Managed requires purchasing the Camunda Self-Managed Enterprise Edition. This is a recurring cost that the migration business case must carry, and it applies to every production environment you stand up during the move, including staging environments that mirror production. Licensing cost rises with the number of production environments and the duration of parallel running. Ask for the Enterprise Edition price in a written quote that covers each environment you plan to run.
What the Diagram Converter analyzes and what it leaves to your team
The Diagram Converter analyzes your Camunda 7 BPMN, DMN and form files, lists the migration tasks it finds, and converts those models into the Camunda 8 format. It also ships with an AI agent skill that can orchestrate the migration around it. Treat that output as the start of the work, not the end. Model conversion is not code conversion. The converter reads the diagrams and forms, but it does not rewrite the Java code that those diagrams call into, and it does not certify that a converted process behaves the same way in Zeebe as it did in the Camunda 7 engine.
Your team owns the review of every generated task list. For each one, check it against the actual implementations behind the model: Java delegates, JavaScript or Groovy scripts, execution and task listeners, external task workers, custom connectors, and calls to databases, message brokers and downstream services. A service task that the converter flags as needing a new implementation has no working equivalent until a developer builds one. Also confirm how each Camunda 7 expression, variable scope and error handling path maps onto Camunda 8, since the converter's list may not capture behavior that lives only in code.
Plan the review as a named deliverable with an owner, not as a side effect of the conversion run. Ask the Camunda team and your implementation partner which checks the converter covers and which are manual, and record that answer in the migration plan. Run the converted models against test cases derived from your production process instances, and include integration tests that exercise every external system a process touches. Read the Diagram Converter documentation before scoping, and confirm the supported element types and any limits for your model versions against the current page.
Where code and API changes hit hardest
The biggest code changes come from the engine model itself. Camunda 7 is a Java-based framework whose process engine persists to a relational database through MyBatis, and it exposes both Java and REST APIs, so many teams call the engine directly from their application code. Camunda 8 is built around Zeebe, a cloud-native process engine that reacts to Kafka and other message queues and scales without a relational database. Any embedded engine call, such as starting a process, completing a task or querying history from inside a service, has to be re-expressed against Camunda 8's model rather than carried over line for line. Inventory every place your code touches the engine API, the task service and the history service before estimating anything, and confirm the exact method-to-API mappings against the current migration documentation in the Camunda migration tools guide.
Transaction boundaries deserve separate review because the persistence model changes. In Camunda 7, a service task and the surrounding database work can commit together in one relational transaction, which many teams rely on for consistency between process state and business data. Camunda 8 does not use a relational database for process state, so code that assumed a shared commit must be redesigned around asynchronous messaging, retries and idempotent handlers. Custom persistence is the other hard spot: any custom MyBatis mappers, direct queries against the Camunda 7 schema, or reporting that reads engine tables will not transfer and must be rebuilt on top of the APIs or exporters Camunda 8 provides. Confirm with Camunda which of these patterns have documented equivalents before you commit to a design.
The operator tooling also changes. Camunda 7 ships Tasklist, Cockpit and Admin as web applications, and teams often use Cockpit for incident investigation and Admin for user and group management. Camunda 8 replaces this set with its own components, including Tasklist and Operate, alongside Identity, so runbooks, support procedures and any custom dashboards built on Cockpit need to be mapped to the new screens and roles. Ask your operations and support leads to list every Cockpit and Admin task they perform each month, then check each one against the current Camunda 8 documentation to confirm where it is handled and who needs access.
How to size the migration effort in your own environment
This sequence turns a general migration question into measured facts about your own process estate, so the decision between staying on Camunda 7, moving to Camunda 8 or choosing a compatible fork rests on your inventory, your test results and your licensing quote rather than on any published estimate.
Build a full inventory of deployed artifacts
Export every BPMN, DMN and form file currently deployed to your Camunda 7 engines, and record each file's process or decision ID, version, the engine it runs on and whether it has active instances. Include files stored outside the engine, such as those in source repositories or shared drives, because they often drift from what is deployed. The team that owns the process engine usually does this, with the process owners confirming which definitions still matter. The step is done when every deployed definition appears on one list with an owner and a live or retired status.
Run the Diagram Converter on a copy
Run Camunda's Diagram Converter against a copy of the inventory, never against the originals, and save the task list it produces for each file. The converter analyzes Camunda 7 BPMN, DMN and form files, lists migration tasks and converts them to the Camunda 8 format. Have a developer review each listed task and mark whether it is automatic, needs manual rework or is outside the tool's scope. The step is done when every file has a converted copy and a reviewed task list that your team has signed off.
Tag Java delegates, listeners and external calls
Search the Camunda 7 application code for Java delegates, execution and task listeners, scripts, expression-language calls, custom history handlers and every outbound call from a service task. Tag each one by type, whether it depends on the engine's Java API, whether it touches the relational schema directly, and whether it calls an external system. These items drive most of the rework because Camunda 8 does not run the embedded Java engine in the same way. The step is done when each tagged item has a rework category and an owner.
Migrate one representative process end to end
Choose one process that uses the most common patterns in your estate, such as user tasks, timers, message events, a call activity and a DMN decision, and migrate it through a non-production Camunda 8 environment. Run it with test data, complete its user tasks through your real front end, and compare outputs with the Camunda 7 behavior. Record each deviation, the code changed and the time your developers spent. The Camunda License 1.0 limits use to non-production environments, so keep this work in development, testing or evaluation. The step is done when the pilot runs with recorded deviations and a measured rework log.
Map active and historical instances
List every running and recently completed instance, group them by definition, and decide for each group whether it runs to completion on Camunda 7.24 or is migrated. Check how your team would query history after cutover, because history stored in the Camunda 7 schema does not move automatically to Camunda 8. Confirm this with Camunda's migration guidance before deciding. The step is done when each group has a documented disposition, a cutover window and a named owner for historical data access.
Price licensing and the Kubernetes operating model
Before committing, ask Camunda for a written quote covering the Self-Managed Enterprise Edition needed for production, the Kubernetes clusters, the Helm or other installation method you will run, and the staff needed to deploy, scale, secure and update the stack. Compare that with the Camunda 7 Enterprise maintenance and extended support terms, and with the cost of a compatible fork. Camunda's documentation says Self-Managed customers run the whole stack themselves, so ask who in your organization owns each component. The step is done when you hold a written quote and a staffing plan you can compare against the other options.
How the effort compares with staying on a compatible fork
Choosing Camunda 8 is not the only way forward for a Camunda 7 estate, and the trade-off is easiest to judge by what each path leaves unchanged. A compatible fork keeps the Camunda 7 API, database schema and models, so the code changes and the data migration are smaller than a move to Camunda 8, where the engine, persistence model and deployment change. The cost of that smaller change is a different support and release model: you depend on a community project or a vendor-backed fork for patches, and you need to check its release cadence and support windows yourself. Read the sibling Camunda 7 vs Operaton vs CIB seven comparison and the migration steps in the fork-specific pages for their current support windows, and confirm those figures directly with each project before you plan around them.
The fork path wins under two conditions. The first is when process logic and stored data must stay stable until a later decision is made, for example while a regulator, a board or a dependent system review is pending, or while the team is still building its skills for a BPMN platform change. The second is when the team does not yet need Camunda 8 features such as horizontal scaling on Kubernetes or Kafka-based messaging, and so has no near-term reason to take on a new engine. In both cases, the fork is a holding position: it preserves options, but it does not remove the eventual move.
Before deciding, run a short inventory: count the process definitions, decision tables and forms in use, list any custom Java delegates or listeners that depend on the Camunda 7 API, and identify which history and audit data must survive. Then ask each candidate path for its written migration scope, the support it will provide for your Camunda 7 version, and what a later move to Camunda 8 would reuse from the fork work. The decision to make now is whether you are buying time or buying a platform, and the answer determines which path carries less rework in the years ahead.
Questions buyers ask before a Camunda 7 to Camunda 8 migration
How much effort does a Camunda 7 to Camunda 8 migration take?
The effort depends mostly on how much of your Camunda 7 system is tied to the engine's Java API, database and web applications, not on the BPMN diagrams alone. Camunda 8 uses Zeebe rather than an embedded relational engine, so the work usually includes rewriting Java delegates and listeners, replacing Cockpit and Admin workflows, reviewing how human tasks and timers are modeled, and changing deployment to Kubernetes or another Self-Managed target. Camunda publishes a Diagram Converter for analyzing and converting BPMN, DMN and form files, but no supplied fact gives a duration or cost for a typical project. Ask any vendor or partner for a written inventory of your process models, delegates, integrations and data stores, and a scope that states which items are converted, rewritten or retired.
Does the Diagram Converter handle the whole migration?
No. The Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, lists the migration tasks it finds and converts those files to the Camunda 8 format, according to Camunda's migration tooling documentation. It does not rewrite Java code, change your integrations, move your data or redesign your deployment. Treat its report as the starting point for the engineering backlog, then check each converted model in Camunda 8 before relying on it. Review the Diagram Converter guide and confirm with Camunda which constructs it reports as needing manual work.
What does our team need to supply for the migration?
You supply the knowledge of your own processes and systems, plus access to the environments where the work happens. In practice that means the Camunda 7 source code and deployed BPMN, DMN and form artifacts, the Java delegates and external task workers, the database and history data you need to keep, the identity and authorization setup, and the upstream and downstream systems each process calls. You also supply the target infrastructure, including the Kubernetes clusters, the messaging components and the test environments, and the people who approve business behavior. Make these inputs explicit in the quote, because missing inventories are a common reason fixed-scope work changes after it starts.
Do running process instances carry over to Camunda 8?
Assume they do not carry over automatically. Camunda 7 persists engine state to a relational database through MyBatis, while Camunda 8 runs on Zeebe with its own storage, so in-flight instances and history need a deliberate plan. Typical options are to let active instances finish on Camunda 7, to migrate selected instances with custom tooling, or to restart them in Camunda 8 with a documented data mapping. Flowable has published a claim that Camunda 7 data can move to Flowable in place, but that is a statement about a different engine and should not be read as a Camunda 8 path. Ask for the instance-handling strategy, the cutover plan and the list of data that will be archived rather than migrated.
What does production use of Camunda 8 Self-Managed require?
Production use of Camunda 8 Self-Managed requires a commercial license. Camunda's licensing documentation says the Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation, and that production use requires purchasing the Camunda Self-Managed Enterprise Edition. Some connectors and components use Apache-2.0, but the core Zeebe, Operate, Tasklist, Identity and Optimize source is under the Camunda License v1. Confirm the exact license terms, the included support and the commercial terms directly with Camunda before you budget, and ask your legal team to review the license text.
Can our own team run the migration without outside help?
A capable team can do it, but the question is whether it has the time and the depth in Camunda 8 without pulling engineers off production work. Your team needs Zeebe and Kubernetes skills, experience with the Camunda 8 worker model and a way to test migrated processes end to end. Outside help is most useful for the inventory and risk review, the Diagram Converter output triage, the Kubernetes deployment and the parallel running and cutover plan. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms, and most engagements are fixed-scope with scope and timelines agreed in writing before work starts. Ask any provider to split the quote into assessment, conversion, rewrite, testing and cutover so you can take on the parts you can staff.
When is staying on 7.24 with Enterprise support the better choice?
Staying on 7.24 with Enterprise support is the better choice when your processes are stable, your team lacks Camunda 8 skills, and you need time to plan a move. Camunda extended Camunda 7 Enterprise end of life to April 9, 2030, with 7.24 as a long-term support release that receives updates in April and October, and paid extended support from April 2030 through April 2032. Community Edition received no releases or security patches after 7.24 was scheduled for October 14, 2025, so the decision is mainly about paying for support rather than about features. Ask Camunda for the support terms in writing, and compare them with the fork options covered on the sibling comparison pages before you commit.
How DeployOpen helps scope and run a Camunda migration
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Camunda 7 to Camunda 8 move, we start by reading your process estate and the rework it implies, then agree the work in writing before any migration begins.
How we scope
- Inventory your Camunda 7 BPMN, DMN and form files, Java delegates, listeners, REST clients and database tables before estimating anything.
- Separate what the Diagram Converter can analyze and convert from what needs manual redesign, and record that split in the scope.
- Agree scope, deliverables and timelines in writing before work starts, with a quote following from that written scope rather than a list price.
How we build
- Run the Diagram Converter on representative process models, then review the generated Camunda 8 output against the original behavior.
- Rework code and API integrations for the Camunda 8 client model, and test them in a non-production environment that matches your target setup.
- Plan the data path for in-flight instances and history, since data that does not carry over must be handled explicitly and tested before cutover.
How we hand over
- Deliver documentation of converted processes, changed interfaces, deployment steps and the data decisions taken during the migration.
- Document the Self-Managed deployment on your Kubernetes clusters or cloud infrastructure so your team can deploy, scale and update it.
- Walk your engineers through the test results and open items so ownership of the migrated processes transfers cleanly to your team.
How we support
- Ask about ongoing support, upgrades and continuous testing, which DeployOpen offers as retainers after the initial engagement ends.
- Confirm with Camunda which production license your Self-Managed deployment needs before go-live, since production use requires a commercial license.
- Agree in the written scope which upgrade, patch and testing responsibilities sit with DeployOpen and which stay with your own platform team.
