Should a Camunda 7 team move from BPMN to Temporal?
Staying on modeled BPMN fits best when business analysts must read and change process models themselves, and when Cockpit and Tasklist are central to how operations watch and work instances. Camunda 7 is a Java BPMN, CMMN and DMN framework that persists to a relational database through MyBatis and ships REST APIs and the Tasklist, Cockpit and Admin applications. Its Community Edition stopped receiving releases after 7.24, so a team staying on the engine must choose between Camunda 7 Enterprise, where Camunda's announcement extended end of life to April 9, 2030, or a supported fork. Temporal fits a different situation: engineers own the process logic in general-purpose code, and durable execution with a complete ordered event history matters more to the business than a diagram that non-engineers can edit.
Because the two platforms differ on who maintains process logic, a useful first step is to list every process in the estate and mark which ones a business analyst changes without a developer. Those models carry the most migration cost, because BPMN diagrams, forms and human task definitions do not become Temporal workflows automatically. For each process, confirm how human tasks are served today. Tasklist and Cockpit give operations staff a ready interface, while a Temporal deployment generally requires you to build the task interface and its assignment logic in your own application. Temporal also has no bundled operator console in the way Cockpit provides one, so visibility will depend on the visibility store and tooling you choose.
Operating effort and licensing should be checked before any decision. Self-hosted Temporal runs Frontend, History, Matching and Worker services with a persistence store, and its supported persistence options include Cassandra, PostgreSQL and MySQL, with SQLite for development only. Advanced visibility needs its own store. Temporal Server is MIT licensed, and the Temporal documentation says its services should run on hosts not reachable from the public internet. Ask your security team to confirm the authorization setup, because with no Authorizer configured the default noopAuthorizer allows every API request. Ask Camunda 7 Enterprise and Temporal Cloud vendors for written terms on production use, support windows and exit obligations before committing.
Which platform fits which team scenario
This table maps common team situations to the platform that fits better and the condition that decides it. Read each row against your own process ownership, existing BPMN assets and Java skills, since those factors usually settle the choice before features do.
| Scenario | Better fit | Why and the condition that makes it so |
|---|---|---|
| Business analysts change approval steps and human sign-offs often | Camunda 7 | Camunda 7 models processes in BPMN with Tasklist for human tasks, so non-developers can read and adjust the diagram. This holds only if the process logic stays stable enough to be deployed as modeled artifacts. |
| Engineering owns long-running service orchestration across many internal services | Temporal | Temporal workflows are written as code in Go, Java, TypeScript or Python, and the complete ordered event history supports replay and resume after failures. This favors Temporal when developers, not process analysts, own the logic. |
| Existing Camunda 7 codebase with BPMN and DMN diagrams in production | Camunda 7 | Staying avoids rewriting diagrams and Java delegates. The trade-off is that Camunda 7 Community Edition has no further releases or security patches, so the choice depends on Enterprise support to 2030 or a fork, not on features. |
| Operations staff need to see running process instances and incidents without writing code | Camunda 7 | Cockpit gives operational visibility into running instances and is a web application shipped with Camunda 7. Temporal's visibility depends on its Web UI and visibility store, which you should confirm meet your operational needs. |
| Team has no Java skills and wants to build workflows in another language | Temporal | Temporal supports Go, TypeScript and Python as well as Java, so it fits teams whose skills lie elsewhere. Camunda 7 is a Java-based framework, so this scenario points away from it. |
| Regulated environment that must audit who can start, change or view workflows | Temporal | Temporal's default noopAuthorizer allows every API request until an Authorizer is configured, so access control must be designed in. Choose Temporal only if your team will build and verify the ClaimMapper, Authorizer and OIDC setup. |
| Workflows stay inside one data center with strict network segmentation | Camunda 7 | Camunda 7 runs embedded in a Java application against a relational database through MyBatis, which keeps the footprint small. Temporal needs Frontend, History, Matching and Worker services plus persistence and visibility stores, which adds operating effort. |
| Process rules must be readable and approvable by compliance staff as diagrams | Camunda 7 | BPMN diagrams give a shared artifact for review, which Temporal code does not provide directly. Temporal fits when code review is an acceptable substitute for diagram review. |
How Camunda 7 and Temporal are built and run
Camunda 7 is a Java process engine that stores state in a relational database, while Temporal is a set of cooperating server services that run code-defined workflows. The cards below show which architectural choices change who operates what, and what your team must check before committing to either model.
Embedded, shared or standalone engine
Camunda 7 persists process state to a relational database through MyBatis and can run embedded inside your Java application, as a shared engine, or standalone. Day two, the deployment mode decides who restarts what: an embedded engine ties process upgrades to application releases, while a shared or standalone engine adds a separate component to patch and monitor. Confirm which mode your current processes use before estimating operating effort.
Cockpit, Tasklist and Admin consoles
Camunda 7 ships REST APIs along with the Tasklist, Cockpit and Admin web applications. For operations staff, these consoles are the built-in way to inspect running instances, work human tasks and manage users, so the console is part of the runtime you must secure and upgrade. Temporal has no equivalent modeled-process console in the supplied facts, so check how your support team currently uses Cockpit before deciding what to replace.
Frontend, History, Matching and Worker services
A self-hosted Temporal Service runs Frontend, History, Matching and Worker services on top of persistence and visibility stores. Day two, this means several server roles to scale, monitor and upgrade, and Temporal's guidance is to upgrade one minor version at a time with schema changes applied before server changes. Your platform team should expect to own this service topology, and the Helm chart version must match the server image when running on Kubernetes.
Persistence and visibility backends
Temporal's tested persistence options are Cassandra, PostgreSQL and MySQL, with SQLite meant only for development and testing. Visibility, which powers search over executions, has its own store, and Elasticsearch or OpenSearch is recommended beyond a few workflow executions. Camunda 7 uses one relational database for engine state, so Temporal adds a second data tier to back up, size and keep in step. Confirm which backends your database team already supports.
Event history and replay
Temporal keeps a complete ordered event history for each workflow and uses it to replay and resume execution after failures. Process logic lives in general-purpose code in Go, Java, TypeScript or Python, so the people who maintain the workflow are developers rather than process modelers. For operations, the history is the recovery mechanism, which makes history retention and code-change compatibility part of release planning. Camunda 7 instead persists process instance state in its relational tables.
Capability comparison: Camunda 7 and Temporal
This table sets Camunda 7's modeled BPMN approach against Temporal's code-defined workflows across process definition, human tasks, visibility, persistence, access control, licensing and upgrades. Read each row as a question to answer for your own team, and use the notes on identity and edition checks as items to confirm before a decision.
| Capability | Camunda 7 | Temporal |
|---|---|---|
| Process definition | BPMN and DMN models, with decisions and process logic often maintained by analysts and developers together in the modeler | Workflows written as code in Go, Java, TypeScript or Python, so developers own the process logic in the same source control as the rest of the service |
| Human tasks | Tasklist and the REST API provide task lists, assignment and forms out of the box | Temporal leaves task lists, assignment and forms to your application, so you build and secure that interface yourself |
| Visibility | Cockpit gives operators a web view of running and historical process instances from the embedded engine | Temporal's Web UI reads from a visibility store, which can be Elasticsearch, OpenSearch or a supported SQL database; Elasticsearch or OpenSearch is recommended beyond a few executions |
| Persistence | Relational database accessed through MyBatis, so the engine and its history live in your existing database platform | Cassandra, PostgreSQL or MySQL for persistence, with SQLite for development only; the full ordered event history drives replay after failures |
| Authentication and authorization | Confirm identity options for your edition with Camunda, including how Tasklist and Cockpit users and groups are authenticated | Without an Authorizer, the default noopAuthorizer allows every API request; mTLS, a ClaimMapper, an Authorizer plugin and OIDC single sign-on for the Web UI must be configured |
| Licensing | Camunda 7 Community Edition is Apache-2.0 but no longer receives releases; Enterprise Edition is a paid subscription with support to April 9, 2030 | Temporal Server is MIT licensed, with Temporal Cloud as a separately paid managed service |
| Upgrade path | Confirm the upgrade route from 7.24 with Camunda and your fork or support provider, since the Community line has stopped | Upgrade one minor version at a time, moving to the latest patch of the current minor first, and run schema upgrades before server upgrades when release notes require them |
What each license and edition allows for production
Camunda 7 is licensed under Apache-2.0 in its Community Edition, but that license covers code, not ongoing support. Camunda's February 2025 announcement says the final feature release, 7.24, was scheduled for October 14, 2025, and that no further releases or security patches follow for Community Edition. The camunda/camunda-bpm-platform repository is archived on GitHub with 7.24.0 as its last tag, so a production team on Community Edition is running code that will not receive upstream fixes. The Enterprise Edition is the paid route that keeps the same codebase supported. Per Camunda's announcement, its end of life was 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 from April 2030 through April 2032.
- Community Edition: Apache-2.0 code with no releases or security patches after 7.24.
- Enterprise Edition: support to April 9, 2030 on the 7.24 line, sold by Camunda.
- Long-term support cadence: updates twice a year, in April and October, on 7.24.
- Extended support: paid, from April 2030 through April 2032, per the same announcement.
- Cost components: the Enterprise subscription is recurring, so ask Camunda for the quote covering your node count and support tier.
Confirm with Camunda which edition and support window apply to your contract, and whether any security fixes you rely on are included in the Enterprise updates.
The Temporal Server is MIT licensed, so a team can run it in production on its own infrastructure without a license fee for the server itself, according to the temporalio/temporal GitHub repository. Temporal Technologies also sells Temporal Cloud as a separate managed service, which is a different commercial product from the open-source server. The Temporal pricing page lists pay-as-you-go pricing starting at 50 US dollars per million actions, active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, with a 99.9% SLA or 99.99% with high availability and SAML SSO. Those figures apply only if you choose Temporal Cloud, not to a self-hosted deployment.
- Self-hosted server: MIT licensed, so production use carries no license fee for the server code.
- Temporal Cloud: a separately sold managed service, not part of the MIT license.
- Pay-as-you-go pricing: starts at 50 US dollars per million actions, per the Temporal pricing page.
- Availability terms: 99.9% SLA, or 99.99% with high availability, on Temporal Cloud.
- Identity on Cloud: SAML SSO is listed on the pricing page.
Before committing, confirm which Temporal offering your budget covers, and ask whether the SLA and SSO terms you need are included in the plan you choose.
Camunda 8 is a different product line from Camunda 7. Its Zeebe, Operate and Tasklist source files are under the Camunda License 1.0, and only the Java client, Spring Boot starter, exporter API and protocol modules are under Apache-2.0, per the camunda/camunda README. The Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation. Production use requires a commercial license from Camunda, according to the license text in that repository. A team moving from Camunda 7 should therefore treat the Camunda 8 path as a commercial decision for production, separate from the open-source client libraries.
- Source license: Zeebe, Operate and Tasklist are under the Camunda License 1.0, per the camunda/camunda README.
- Apache-2.0 parts: the Java client, Spring Boot starter, exporter API and protocol modules.
- Non-production use: development, testing and evaluation are the permitted uses under the license.
- Production use: requires a commercial license from Camunda, according to the license text.
- Migration tooling: the Diagram Converter and migration guides are documented by Camunda, but they do not change license terms.
Ask Camunda to confirm the production license terms, the scope of the commercial license and what it covers for your deployment model before you plan a production cutover.
What drives the running cost of each platform
The running cost of Camunda 7 and self-hosted Temporal comes from different places, so the first decision is which cost components apply to your team. A self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus a persistence store and, for advanced visibility, a separate visibility store. Temporal's documentation lists Cassandra, PostgreSQL and MySQL as tested persistence options, and Helm charts can place each service in its own Kubernetes pods. Your cloud or cluster bill, the database you operate, and the staff who size and monitor those services are the main recurring costs. Camunda 7 is lighter at the infrastructure layer: a Java application that embeds the engine and a relational database that MyBatis persists to. Its recurring cost is mostly the runtime and database you already run, plus Camunda 7 Enterprise Edition support fees if you buy them, which run through April 9, 2030 with paid extended support to April 2032. Confirm the Enterprise fee, its term and what it includes in writing with Camunda, because it is the largest line item you do not control.
Engineering effort is the cost driver most teams underestimate. Camunda 7 lets analysts and developers keep process logic in BPMN models that Cockpit and Tasklist can show operators, so the ongoing cost is mainly maintaining diagrams and the Java delegates behind them. Temporal moves that logic into general-purpose code in Go, Java, TypeScript or Python, so the cost shifts toward developers who understand determinism, versioning and replay. Temporal Cloud usage is billed separately: its pay-as-you-go pricing page lists charges per million actions and per GB-hour of storage, so the workflow volume, history size and retention period drive the bill. Self-hosted Temporal avoids those charges but adds on-call work for the services and stores. Upgrade effort also recurs. The Temporal upgrade documentation asks you to move one minor version at a time and run schema upgrades before server upgrades when release notes require them, which is a planned, staffed task each cycle.
One-time costs are the migration of running process instances, the rewrite of BPMN flows and Java delegates into code, the design of Temporal namespaces, persistence and security, and retraining for both developers and operators. Recurring costs are hosting, database operations, Enterprise or Temporal Cloud fees, upgrades and on-call. Ask any provider or partner for a written quote that separates these, names the Camunda 7 Enterprise term and support tier, lists each Temporal service and store you will run, states who performs the schema and server upgrades, and identifies which workflow volumes and retention settings the estimate assumes. Scope changes, such as moving from Camunda 7 Community Edition to a different support path, should appear as separate line items so you can compare options on the same basis.
How a Camunda 7 team moves to Temporal, step by step
The sequence turns a modeled Camunda 7 estate into Temporal workflows that run alongside it, with each process either moved or deliberately kept on 7.24 with Enterprise support.
Inventory BPMN, DMN and forms
Build a full list of every BPMN process, DMN decision table, form and Java delegate, service task and listener that the engine executes, and record which applications start each process. The engineering lead and the process owners sign off on the list. The step is complete when every deployed definition maps to an owning application, a business owner and a list of external systems it calls. Camunda's Diagram Converter analyzes these files, but it targets Camunda 8, so this inventory is a manual or scripted exercise for a Temporal move.
Decide which processes move
Sort each process into one of two groups: moves to Temporal, or stays on Camunda 7.24 with Enterprise support. Processes with heavy human task routing, many business users editing models, or frequent DMN changes by analysts are weak candidates for code-first rewrites. Processes with long-running, retry-heavy, code-owned logic are stronger candidates. The output is a signed decision register with a named exit path for each staying process, checked against Camunda's Enterprise end-of-life date of April 9, 2030.
Rebuild logic as Temporal workflows
Rewrite each moving process as a Temporal workflow with its activities in one supported language such as Go, Java, TypeScript or Python. Replace BPMN gateways and timers with code, move service task delegates into activities, and keep DMN decisions as tested library code or a separate rules service, since Temporal does not read DMN files. Standardize on one language per team to limit the skills needed to maintain the logic. Confirm that each workflow is deterministic and that non-deterministic calls are wrapped in activities. Done means each rebuilt workflow passes the same test cases that the Camunda 7 process passed.
Redesign human task handling
Tasklist has no direct equivalent in Temporal's core model, so decide how people will complete tasks before any workflow goes live. Options include a custom task application that stores assignments and signals the workflow, or a separate task or case management product connected through signals and activities. Confirm with the vendor and in your own environment how any third-party tool authenticates users and records completion. The step closes when a written design shows who sees each task, how it is claimed and completed, and how the workflow resumes after a human response.
Decide the handling of active and historical instances
Active Camunda 7 process instances and their history do not convert automatically into Temporal workflow histories. For each process, choose one of three paths: let running instances finish on Camunda 7 while new starts go to Temporal, migrate or restart specific instances through a custom script you validate, or archive history into a reporting store. Record the decision and the retention rule for audit data. The step is complete when no running instance lacks an owner and every archived record has a documented location and access rule.
Deploy Temporal and configure authorization
Deploy the self-hosted Temporal Service on infrastructure you control, choosing among Docker Compose, Go binaries, or Helm charts that run the services in Kubernetes pods. Choose a persistence store from the tested options (Cassandra, PostgreSQL or MySQL, with SQLite for development only) and an advanced visibility store if you need search. Before exposing any API, configure an Authorizer, since without one the default noopAuthorizer allows every request. Enable mTLS, a ClaimMapper and OIDC for the Web UI as your policy requires. Confirm Helm chart and server version pairs in the deployment documentation. Done means an unauthenticated request is rejected in your test environment.
Run both platforms in parallel
Route a small set of new process starts to Temporal while Camunda 7 continues to serve the rest, then widen the share once monitoring shows correct completions, retries and alerts. Compare outcomes, error rates and operator effort on both platforms, and keep the Camunda 7 rollback path open until the migrated processes have run through their normal business cycles. Assign owners for on-call, upgrades and Temporal Server version moves, which should proceed one minor version at a time. Done means the parallel run produces agreed results and a retirement date for each Camunda 7 process is approved in writing.
Where Temporal and Camunda 7 projects usually run long
Schedules on a Temporal move slip most often in the platform work that surrounds the workflow code. Teams must design workflow code that is deterministic, because replay from the event history only works if workflow logic produces the same decisions on every run, and that discipline takes review time from developers who are used to ordinary service code. The persistence and visibility choices also need an early decision: the tested persistence options are Cassandra, PostgreSQL and MySQL, with SQLite meant only for development and testing, and advanced visibility requires Elasticsearch or OpenSearch once executions grow beyond a few. On the security side, the default noopAuthorizer allows every API request until an Authorizer is configured, so mTLS settings for internode and frontend traffic, the ClaimMapper, OIDC for the Web UI and the network placement of the Frontend, History, Matching and Worker services all have to be designed, tested and documented before go-live. Finally, plan the upgrade path: move one minor version at a time, run schema upgrades before server upgrades when the release notes call for them, and confirm the Helm chart version against the server image. Confirm each of these with the Temporal release notes for the version you intend to deploy.
For a Camunda 7 team, the effort usually sits in keeping the embedded engine and its relational schema working on the platform you already run, not in writing new process logic. The 7.24 release was scheduled as the final feature release, and Camunda 7 Enterprise is supported to April 9, 2030, with paid extended support available through April 2032. Schedules slip when teams leave the post-7.24 support posture undecided, because security patches for the Community Edition stop after the final release and any fork or upgrade path needs its own compatibility test against your Java runtime, application servers and database. If the decision is a move to Temporal, the largest task is the human task rebuild: Tasklist, Cockpit and the process-level audit views have to be replaced with your own task assignment, inbox and reporting, and the modeled BPMN flows must be rewritten as code. DeployOpen plans, implements, hardens and documents this work inside your own infrastructure, and scope, deliverables and timelines are agreed in writing before any work starts.
Questions buyers ask before moving from Camunda 7 to Temporal
How much does moving from Camunda 7 to Temporal cost?
No supplied source gives a total migration price, so the cost depends on scope. The main drivers are the number of process models to rewrite as code, the number of human task flows and forms to rebuild outside Tasklist, the integrations that depend on Camunda 7 REST APIs, and the self-hosted infrastructure you add. Costs fall into one-time work (design, rewrite, testing, cutover) and recurring work (running Temporal Service, persistence, visibility and upgrades). Temporal Cloud is a separate option with published pay-as-you-go rates, starting at 50 US dollars per million actions according to the Temporal pricing page. Ask any partner for a fixed-scope quote that lists each process, each task interface and each integration separately.
How long does a Camunda 7 to Temporal move take?
No supplied source gives a duration, so the timeline is set by scope and risk rather than by a standard period. Work runs longer when many BPMN processes carry business logic that must be re-expressed in Go, Java, TypeScript or Python, when running instances must finish on the old engine, and when the team must build its own task inbox and reporting. Parallel running, where Camunda 7 and Temporal coexist during cutover, adds effort but lowers cutover risk. Ask for milestones tied to process groups, a plan for in-flight instances, and an explicit list of what is out of scope.
Can our own team migrate from Camunda 7 to Temporal?
A team can migrate in-house if it already runs production Java or Go services, operates Kubernetes or Docker-based infrastructure, and can own a new persistence layer. The Camunda 7 Enterprise Edition is supported to April 9, 2030, so there is no forced deadline, which gives an in-house team room to plan. Check whether your engineers have built durable workflows before, and whether anyone will own Temporal upgrades. Temporal's upgrade guidance says to move one minor version at a time and to run schema upgrades before server upgrades when release notes require it. If those skills are thin, a fixed-scope implementation partner can cover design, build and handover, with the knowledge transfer written into the scope.
What skills and staff does a Temporal migration need?
Plan for four skill groups: developers who write workflow and activity code in one of the supported SDK languages, platform engineers who run the Temporal Service and its persistence store, security engineers who configure access, and a process owner who defines the business rules. Self-hosted Temporal runs Frontend, History, Matching and Worker services plus a persistence store, and Temporal supports Cassandra, PostgreSQL and MySQL for production. Access control needs deliberate design, because if no Authorizer is configured, the default noopAuthorizer allows every API request. Temporal's own docs say services should not be reachable from the public internet. Confirm each skill and owner before the project starts.
Does Temporal's code-first model suit business-led process change?
Usually not on its own. In Camunda 7, analysts can read and sometimes edit BPMN diagrams, and operators can use Cockpit to inspect and act on instances. In Temporal, workflow logic lives in code, so a process change needs a developer, a code review and a deployment. Temporal's complete event history is a strong fit for durable, long-running logic, but it does not give business users a visual model. If business owners must change flows often, plan a separate definition layer, such as a rules service or a low-code tool, and confirm how that layer connects to Temporal before you commit.
Should we buy Camunda 7 Enterprise to 2030 before deciding?
Buying Enterprise support to 2030 buys time to plan, not a permanent answer. Camunda 7 Enterprise end of life was extended to April 9, 2030, with 7.24 as a long-term support release that gets updates in April and October, and paid extended support is available from April 2030 through April 2032, according to Camunda's February 2025 announcement. Use that window to inventory processes, measure how many instances run long, and test a Temporal prototype on one process. Ask Camunda for the current support terms in writing, since the Community Edition gets no further releases or security patches after 7.24. For a full comparison of the Camunda 7 paths, see the Camunda 7 announcement.
How DeployOpen helps choose, implement or migrate
DeployOpen works on Camunda 7 vs Temporal as a self-hosted engagement inside your own infrastructure, starting with a written scope before any work begins. The method covers the decision itself, the implementation or migration work, and the documentation your team needs to run the result.
How we scope
- Written scope agreed before work starts, covering which Camunda 7 processes, forms and human tasks are in or out
- Inventory of Java delegates, listeners, REST integrations and database dependencies that tie processes to the engine
- Confirmation of target hosting, persistence and identity requirements for Temporal or a retained Camunda 7 path
- Quote built from the written scope, with recurring and one-time components listed separately
How we build
- Prototype of representative workflows in both candidate platforms, tested against your own identity and audit requirements
- Rebuild of retained process logic as code, with tests for retries, timeouts, compensation and human approval steps
- Self-hosted Temporal deployment in your environment, including persistence and visibility store selection and hardening
- Security review of the default configuration, including authorization, network exposure and payload encryption choices
How we hand over
- Runbooks for deployment, upgrades and schema changes, following the minor-version upgrade order the vendor documents
- Architecture and decision records explaining why each process moved, stayed or was retired
- Operator training for your platform, development and operations teams on the new execution model
- Evidence packs of configuration, access controls and test results for your internal or external assessors
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Tracking of vendor release and support windows so upgrade work is scheduled before end of life
- Periodic security testing of the workflow platform and its integrations, scoped in writing
- Clear handover of responsibility between your team and DeployOpen for each operational task
