Camunda 7 vs Camunda 8: which to choose

Camunda 7 vs Camunda 8: when staying on 7.24 is the right call and when the move pays off

If your Java team runs Camunda 7 on 7.24 with a relational database and a fixed deadline, staying is the right call while the estate is stable, embedded and must run to 2030. Moving to Camunda 8 pays off when you need horizontal scale, Kubernetes-native operation or event-driven work that the embedded relational engine does not serve well. The page question comes down to three drivers: how much rework your team can absorb, whether production licensing is acceptable, and how long the process estate must keep running. Camunda 7 Enterprise Edition is the lower-change path. Camunda's announcement extends 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 through April 2032. Choose it if your processes, Java applications and relational database are working, and your priority is a predictable runtime with no change to BPMN models, the engine API or the data model. Confirm with Camunda which 7.24 patch level and Enterprise terms cover your environment, and whether your Java runtime and application server are on the supported list. Camunda 8 Self-Managed Enterprise fits teams whose processes need Zeebe's clustering, Kafka or other message queue integration, and deployment through Helm or Kubernetes. Production use requires the Self-Managed Enterprise Edition, because the Camunda License 1.0 covers non-production use only, so budget for that licence and for the migration itself. The Diagram Converter helps analyze and convert BPMN, DMN and form files, but code, API and data changes remain your work. Ask Camunda for a written list of what does not carry over before committing a date.

Which platform fits which Camunda 7 scenario

This table maps common Camunda 7 situations to the option that fits them better, Camunda 7 Enterprise on the current engine or Camunda 8 with Zeebe. Read each row for the condition that would change the answer, because most rows flip once the team's constraints shift.

Scenario	Better fit	Why, and when it stops being the better fit
A stable embedded Spring application that must run to 2030 with minimal change	Stay on Camunda 7 Enterprise (7.24)	Enterprise end of life runs to April 9, 2030 per Camunda's announcement, and the embedded relational engine keeps code and schema largely unchanged. It stops fitting if the business needs demand new capabilities beyond what 7.24 offers or if support after 2030 must be planned.
A team that needs Zeebe-style horizontal scaling and Kafka-driven events	Camunda 8	Camunda's README lists horizontal scaling, fault tolerance without a relational database and reacting to Kafka and other queues. It stops being the better fit if throughput needs are modest and the team has no event-streaming platform to connect to.
A team that wants to keep the relational database and Cockpit workflow	Camunda 7 Enterprise (7.24)	Camunda 7 persists to a relational database through MyBatis and ships Cockpit, Tasklist and Admin. Camunda 8 replaces this operating model, so this stops being the better fit once the team plans to retire its database-centric operations anyway.
A team preparing for a Kubernetes-first platform	Camunda 8 (Self-Managed)	Camunda documents Kubernetes with Helm, Docker and manual installation for Self-Managed, and the README lists Kubernetes deployment. It stops being the better fit if the team cannot yet staff platform operations, since Self-Managed customers run the whole stack on their own clusters.
A team whose processes are mostly human tasks with few integrations	Camunda 7 Enterprise (7.24)	Tasklist, Cockpit and the BPMN and CMMN support cover human workflow without the streaming stack. It stops being the better fit if the process estate grows into many service integrations that Camunda 8 connectors would handle.
A team whose production licensing budget is not yet approved	Camunda 7 Enterprise (7.24), pending a quote	Camunda 8 Self-Managed production use requires the Self-Managed Enterprise Edition, while the Camunda License 1.0 limits non-production use. Ask Camunda for the commercial terms before choosing; this stops being the better fit once that quote is confirmed as affordable.

How the embedded engine and Zeebe differ in operations

Camunda 7 runs as a Java engine on a relational database, while Camunda 8 splits the same process work across Zeebe and companion components. The cards below cover what each model asks of backups, upgrades and on-call staff, and what your team must learn before committing to a move.

Relational persistence through MyBatis

Camunda 7 persists process state to a relational database through MyBatis, so the database is the system of record your DBAs already back up and restore. Process instances, history and task data sit in tables you can query and snapshot with standard tooling. Before deciding, confirm your database engine and version are supported by the Camunda 7 release you run, and rehearse a point-in-time restore that includes the history tables, because a restore that misses them can leave the engine and its history out of step.

Embedded, shared or standalone deployment

The Camunda 7 engine can run embedded inside your Java application, as a shared engine serving several applications, or standalone. Each mode changes who restarts the engine, who patches the container and where the on-call page lands when a deployment fails. Map your current topology first. An embedded engine ties process availability to the application release cycle, which is a different operating model from the separate Zeebe cluster that Camunda 8 requires.

REST APIs and web applications

Camunda 7 ships REST APIs and the Tasklist, Cockpit and Admin web applications. Many teams script monitoring, incident triage and user task routing against these endpoints and screens. List every internal tool, runbook and integration that calls the REST API or opens Cockpit, because Camunda 8 replaces these surfaces with Tasklist, Operate and its own APIs. Each replacement is a change to runbooks and access controls, not only a version bump.

Camunda 8 Orchestration cluster components

The Camunda 8 Orchestration cluster in the camunda/camunda repository contains Zeebe, the cloud-native process engine, along with Tasklist, Operate, Identity and Optimize. Operators must learn how these components interact, how Zeebe partitions and brokers behave, and which component owns each failure mode. Ask the vendor for the current component list, the supported upgrade order between components and the monitoring each one exposes, since these determine what your on-call team must understand.

Kubernetes installation methods

Camunda documents Helm, Docker and manual installation as Self-Managed methods, and the Self-Managed model puts the customer on the hook to deploy, scale, secure and update the whole stack on their own Kubernetes clusters or cloud infrastructure. Helm charts shift routine work into values files, chart versions and cluster upgrades. Confirm which of these methods your platform team will standardize on, who owns cluster lifecycle, and how Helm chart upgrades will be tested against your own process workloads before production.

Fault tolerance and horizontal scaling

The Camunda 8 README lists horizontal scaling and fault tolerance without a relational database as core properties, which changes the backup question from restoring one database to coordinating the state of the cluster. Your team will need new procedures for scaling partitions, handling broker failures and verifying that a restored cluster resumes the correct process state. Ask for documented backup and restore steps for the Zeebe data layer, and test them before you migrate production instances.

A different data and component model

Moving to Camunda 8 is not a version upgrade of the same engine. Zeebe uses its own data model, exporters and event streams, and it adds components your operators have not run before. Plan training and runbook rewrites before cutover, and budget time for the migration tooling and data that does not carry over directly. Treat this as a new platform to learn, not a patch to the old one, because on-call engineers will meet unfamiliar failure modes in the first months.

Camunda 7 and Camunda 8 compared on the decision factors

This table compares the two Camunda generations on architecture, licensing, deployment and support. Read the first column as the decision question, then check the notes against your own environment. The main takeaway is that Camunda 7 keeps the embedded relational model until its 2030 end of life, while Camunda 8 changes the runtime and the licensing terms for production.

Capability	Camunda 7	Camunda 8
Architecture and persistence	Process engine persists to a relational database through MyBatis	Zeebe process engine with horizontal scaling and no relational database required; confirm storage for Operate and Optimize in your design
Java embedding	Engine runs embedded in a Java application, as a shared engine or standalone	Zeebe runs as a separate cluster; the Java client and Spring Boot starter connect to it. Confirm any in-process option with Camunda
Deployment and Kubernetes	Installation on Kubernetes depends on your application packaging; confirm the supported approach with your team	Self-Managed on your own Kubernetes with Helm, Docker or manual install; SaaS is run by Camunda
BPMN, DMN and CMMN coverage	BPMN for workflow, DMN for decisions and CMMN for case management	BPMN 2.0 and DMN are listed; confirm CMMN support with Camunda before assuming it
REST and message integration	Ships REST APIs; message integration depends on your Java application design	Reacts to Kafka and other message queues; confirm connector coverage for your systems
Web applications	Tasklist, Cockpit and Admin web applications	Tasklist and Operate, with Identity and Optimize in the orchestration cluster; Console and Web Modeler are part of the wider stack
Source license	Apache-2.0; the repository is archived with 7.24.0 as its last tag	Zeebe, Operate and Tasklist source under Camunda License 1.0; clients and some protocol modules under Apache-2.0
Production license	Community Edition has no releases or security patches after 7.24; production support requires Enterprise Edition	Camunda License 1.0 covers non-production use; production Self-Managed requires the Enterprise Edition license
Support window	Enterprise end of life April 9, 2030, with paid extended support to April 2032 (per Camunda's announcement)	Confirm the support window for the release line you plan to run with Camunda's current policy and contract

What production use of each platform requires

The Camunda 7 Community Edition is the open-source path, and its source is licensed under Apache-2.0. Camunda's final feature release, 7.24, was scheduled for October 14, 2025, and after that Camunda makes no further releases or security patches for the Community Edition. The camunda/camunda-bpm-platform repository is archived on GitHub, with 7.24.0 as its last tag, so there is no upstream channel that will deliver fixes for new vulnerabilities in the Community code.

License: Apache-2.0 for the engine source, with no license fee for the software itself.
Support window: None from Camunda after the 7.24 release, so no patches for the Community Edition.
Repository state: Archived, with 7.24.0 as the last tag, so you cannot expect new tags to appear.
What you pay for: Your own engineering staff or an outside provider to patch, test and host the platform.
Production position: Usable in production under Apache-2.0, but you carry the security maintenance yourself or move to a supported path.

Before you rely on this tab, confirm with your legal team how Apache-2.0 applies to your plans and check whether your security policy accepts an unpatched engine.

How a move from Camunda 7 to Camunda 8 proceeds

The sequence turns a Camunda 7 estate into a Camunda 8 plan with a clear list of what converts automatically, what needs code changes and what the business must decide before cutover. Each step ends with an artifact the team can review.

Inventory BPMN, DMN and form files
Start by listing every BPMN process, DMN decision table and form file the Camunda 7 estate deploys, with the owning team and the Java application that calls each one. Note which processes are versioned, which are still in use and which are only kept for history. Platform engineering and process owners do this together, usually from the deployed artifacts and the engine's repository state rather than from memory. The step is done when every model has an owner, a status and a named application that depends on it.
Run the Diagram Converter to list migration tasks
Run Camunda's Diagram Converter against the inventory to analyze the Camunda 7 BPMN, DMN and form files, list the migration tasks it finds and convert the files into the Camunda 8 format. The converter output is a starting point, not a finished migration, so the team reviews each listed task and each converted file. The output is a task list per model, a set of converted files in version control and a record of anything the converter could not handle.
Review Java delegates, listeners and REST clients
Review the Java delegates, execution and task listeners, and the REST clients that the Camunda 7 processes call, and decide how each maps to the Camunda 8 model. Camunda 8 uses a different job-based worker model and different APIs, so this code usually needs redesign rather than a direct port. Developers and architects own this review, with the process owners confirming behavior. The step is done when every delegate and listener has a target design, such as a job worker, a connector or a retained service, and the team agrees on it.
Decide how active instances and history are handled
Decide what happens to process instances that are running on Camunda 7 at cutover and to the audit history that the engine stored. Options include letting running instances finish on Camunda 7, migrating some instances, or archiving history in a separate store. The Diagram Converter does not settle this choice, and the answer depends on how long instances live and what regulators or auditors need to see. Process owners, risk and compliance teams should sign off. The step is done when each process has a written instance strategy and a history retention decision.
Rebuild the deployment on Kubernetes
Rebuild the runtime for Camunda 8 Self-Managed, which the Camunda documentation describes as deployed with Helm, Docker or manual installation, and which you run on your own Kubernetes clusters or cloud infrastructure. Platform engineering owns the cluster, storage, identity, networking, backup and upgrade process, because Self-Managed customers operate the full stack themselves. Confirm the production licensing position for Camunda 8 Self-Managed before this build is treated as production, since production use requires the Self-Managed Enterprise Edition. The step is done when a non-production environment runs the migrated models, backups are tested and the operating runbook is written.
Run parallel validation before cutover
Run the migrated processes in parallel with Camunda 7 using representative inputs, and compare outcomes, decisions, timings and human task handling between the two engines. Test the failure paths and the integrations, including message queues and downstream systems, because these often differ most. Business owners approve the results against the acceptance criteria written in step one. The step is done when differences are either fixed or accepted in writing, and the rollback path to Camunda 7 is tested.
Cut over and retire the Camunda 7 runtime
Switch new process starts to Camunda 8 according to the instance strategy, monitor the first production runs and keep Camunda 7 available for the agreed rollback window. Retire the Camunda 7 runtime only after running instances have completed or been moved and history has been archived. Operations and the process owners confirm each stage. The step is done when the Camunda 7 runtime is switched off, its data is archived under the retention decision and the handover documentation is complete.

What drives the running cost of each option

Running cost for Camunda 7 and Camunda 8 is set less by the license line than by who operates the stack, which skills the team already has, and how much rework a move forces. The cards below separate the recurring items from the one-time items so you can ask each vendor or partner for a quote that covers both.

Infrastructure footprint

Camunda 7 runs as an engine inside your Java applications on a relational database that you already operate, so the recurring infrastructure is mainly database capacity, backups and application hosting. Camunda 8 Self-Managed runs Zeebe, Operate, Tasklist, Identity and Optimize on Kubernetes clusters you deploy and scale yourself, with Helm, Docker or manual installation as options. Ask for a sizing estimate for your peak process volume and the number of clusters per environment, including non-production copies.

Licensing for production

Camunda 7 Enterprise Edition support is a paid subscription that runs to April 9, 2030 for the 7.24 line, with paid extended support available through April 2032. Camunda 8 production use of Self-Managed requires the Self-Managed Enterprise Edition license, because the Camunda License 1.0 limits the software to non-production environments otherwise. Ask Camunda for the license scope, the number of environments covered and whether the price recurs annually.

Team skills and operations

A team that already runs Java applications and relational databases can keep most of its operating skills for Camunda 7, which keeps the staffing cost close to the current level. Camunda 8 asks for Kubernetes, Helm, event streaming and the operation of several cooperating components, which usually means training or new hires. Ask the implementation partner to state which roles they would fill during the project and which skills your staff would need to keep afterward.

Upgrades and support windows

Camunda 7 stops receiving community releases and security patches after the 7.24 release, so every future fix on that line depends on a paid Enterprise agreement. Camunda 8 is a faster-moving stack, and each minor line brings its own patch cadence that your operations team must follow across every cluster. Ask both sides for the patch schedule, the support window for each line you plan to run, and the effort your team will carry for each upgrade cycle.

Migration rework

The move from Camunda 7 to Camunda 8 is a one-time cost that covers converting BPMN, DMN and form files, rewriting code and API calls, and deciding what happens to active process instances and history. Camunda's Diagram Converter and migration tooling reduce the file conversion work, but they do not remove the code changes or the data questions. Ask for an assessment of the process inventory and a written statement of what data will and will not carry over.

Cost of staying longer

Staying on Camunda 7 with Enterprise support is a recurring subscription that buys time, and the cost of that time rises as the 2030 end of life approaches. A later migration may then face a bigger process inventory and fewer people who know the old engine. Ask Camunda for the renewal terms and any price change at each renewal, and build a comparison of two scenarios: migrating now or migrating before the support date.

Where Camunda 8 migration projects usually run long

Staying on Camunda 7 is not free of effort, and the work is mostly recurring. Enterprise Edition end of life was extended to April 9, 2030, with 7.24 as a long-term support release that receives updates in April and October, and paid extended support available from April 2030 through April 2032, according to Camunda's announcement. Your team still owns the Java baseline the engine runs on, the review of each twice-yearly patch against your embedded or shared engine deployment, and the security posture of the database and REST endpoints around it. Confirm with Camunda which Java and application server versions the 7.24 line supports for your runtime, and budget internal or partner time for each patch cycle rather than treating 2030 as a fixed endpoint. Ask whether extended support after 2030 is priced per year and what it covers.

A Camunda 8 move carries one-time work that is harder to size than it looks. Start with BPMN and DMN conversion review: the Diagram Converter analyzes Camunda 7 BPMN, DMN and form files and lists migration tasks, but every converted model still needs a process owner to confirm behavior. Code changes follow, including Java delegates and any client code that calls the engine, which must move to the Camunda 8 client and job worker model. Data needs an explicit decision: decide which active instances finish on Camunda 7, which are migrated, and how history is retained, because in-flight state and history do not move automatically. Kubernetes platform work covers the Self-Managed stack you will operate yourself, including Helm-based installs, storage, identity and upgrades. Testing long-running processes is often the longest item, since timers and human tasks may span weeks.

Common overruns come from underestimating the data decision, the number of converted models that need manual rework, and the Kubernetes operations skills the team lacks. Licensing can also add a late surprise: the Camunda License 1.0 limits use to non-production environments, and production Self-Managed use requires the Self-Managed Enterprise Edition, so confirm the commercial terms before the production cutover is scheduled. Confirm with Camunda the current support and patch windows for the Camunda 8 versions you target, the Self-Managed Enterprise terms, and which Camunda 7 features have no direct equivalent. In your own environment, inventory every Camunda 7 model, delegate, custom listener and integration, and run a pilot on one representative long-running process before committing to a date.

Questions teams ask before choosing Camunda 7 or Camunda 8

How long does Camunda 7 Enterprise support last?

Camunda 7 Enterprise Edition end of life was extended to April 9, 2030, and 7.24 is the long-term support release, receiving updates twice a year in April and October. Paid extended support is available from April 2030 through April 2032. Camunda 7 Community Edition receives no further releases or security patches after 7.24, which was scheduled for October 14, 2025, so a Community deployment already carries unpatched risk. No supplied source covers the period after April 2032, so confirm those terms with Camunda. Ask for the support terms in writing, including what the subscription covers and how it renews, before you plan a multi-year roadmap around them.

Can we run Camunda 8 in production without a commercial license?

No. The Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation, and requires a commercial license from Camunda for production use. Camunda's licensing page states that production use of Camunda 8 Self-Managed requires purchasing the Camunda Self-Managed Enterprise Edition. The Apache-2.0 components, such as the Java client, Spring Boot starter and protocol modules, do not change this for Zeebe, Operate and Tasklist, which fall under the Camunda License. Confirm the exact scope with Camunda before you commit, including which components your architecture uses and what the commercial agreement covers.

What does a Camunda 7 to Camunda 8 migration cost in effort?

Effort depends mostly on how much custom Java sits around your processes, such as delegates, listeners, Camunda 7 specific API calls, forms and history data, not on the diagram count alone. Camunda's Diagram Converter analyzes BPMN, DMN and form files, lists migration tasks and converts them to the Camunda 8 format, and an AI agent skill can orchestrate the migration. Conversion reduces modeling work but does not remove code rework, testing or cutover planning. The cost has three payers: your staff's time, Camunda licensing (recurring), and any implementation partner fees under written scope (one-time). Ask any quote to break out inventory, conversion, code changes, testing, cutover and licensing separately.

Can our own team migrate from Camunda 7 to Camunda 8?

A team with Java and Camunda 7 experience can attempt it, but the tooling converts files, not architecture. The Diagram Converter handles BPMN, DMN and form files, and Camunda's migration tooling documentation describes the steps for each. The engine changes from an embedded relational engine to Zeebe, so process code, persistence assumptions and integrations need review even when the diagrams convert cleanly. A small process inventory with few custom delegates is a contained project for an experienced team. A large estate with many integrations, a regulated audit trail or a fixed deadline usually becomes a planned program with dedicated testing and cutover work.

What skills does a Camunda 8 move require from our team?

Your team needs working knowledge of Java for process code and integrations, BPMN for modeling and review, and Kubernetes for operating the platform. Camunda's Self-Managed documentation says customers deploy, scale, secure and update the whole stack on their own Kubernetes clusters or cloud infrastructure, with Helm, Docker and manual installation as documented methods. In Camunda 8 SaaS, Camunda runs the infrastructure, availability, security and upgrades instead. Choosing Self-Managed therefore means someone owns cluster operations, upgrades and backups from day one. Check the storage and supporting components with Camunda's documentation before you size the platform team.

When does an outside partner add value to a Camunda migration?

An outside partner adds value when the work exceeds the team's capacity, when Kubernetes operations are new to the organization, or when regulated evidence must be produced alongside the migration. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or upgrades can run as a retainer. DeployOpen does not publish a price list, so ask for a quote built from the written scope and compare it with the internal effort you have identified.

What risk does staying on Camunda 7 Community Edition carry?

Community Edition receives no further releases or security patches after 7.24, so any vulnerability found after that point stays open unless you fix it yourself. The camunda-bpm-platform repository is archived on GitHub, with 7.24.0 as its last tag, which means there is no upstream development path to follow. Teams that must keep running Camunda 7 usually choose between paid Enterprise support, a community or vendor-maintained fork, or a move to another engine. Map your exposure first: count the production deployments, note which ones face the internet or hold regulated data, and set a decision date that fits your review cycle.

How DeployOpen helps teams choose and plan the move

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Camunda 7 vs Camunda 8, we help teams document the current process estate, decide whether to stay, move or switch paths, and carry the chosen path through written deliverables.

How we scope

We inventory the Camunda 7 process models, DMN decisions, forms, custom code and integrations before any recommendation is written.
The written scope states which decision paths are assessed, which deliverables are produced and what the client must provide.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We build the chosen target in the client's own cloud accounts, data centers or air-gapped networks, not on DeployOpen's infrastructure.
For a Camunda 8 move, we run the Diagram Converter on representative models and document the tasks it flags for manual rework.
Test plans cover process instances in flight, history data, connectors and the identity and persistence layers the client has chosen.

How we hand over

Handover includes architecture notes, deployment runbooks for the chosen Kubernetes or Helm setup, and a record of every migration decision.
We document which Camunda 7 data does not carry over, so the client's risk owners can sign off on it in writing.
Compliance evidence is prepared for the client's assessors, who issue any audit report or certification, not DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainer scope for Camunda 8 covers version upgrades, backup checks and security testing of the deployed stack.
Before any quote, we ask the client to confirm its Camunda license position, support contract and target production dates.

Camunda 7 vs Camunda 8