Flowable vs Camunda 7 migration: which exit path fits your running processes
If your Camunda 7 estate must leave the Community Edition, which no longer receives releases or security patches after the final 7.24 feature release scheduled for October 14, 2025, you have two main exit paths. Flowable offers an in-place migration of process data and history, while Camunda 8 requires moving to a different engine and a production license under the Camunda License 1.0. The right path depends on whether your team wants to keep a Java embedded BPMN engine or change its runtime model, and on what your licensing position allows for production use.
Start by separating what each path keeps. Flowable's engines are Apache-2.0 licensed, support BPMN, CMMN and DMN, run embedded in a Java application or as a service, and expose Java and REST APIs. Camunda 8's Zeebe, Operate and Tasklist source files are under the Camunda License 1.0, which limits use to non-production environments such as development, testing and evaluation. Camunda's Enterprise Edition for Camunda 7 has a later end of life, April 9, 2030, with 7.24 as a long-term support release, so the Enterprise contract and the Community Edition may need separate decisions. Confirm the entitlement and support terms for your own contract with Camunda directly.
Treat the Flowable claim as a vendor claim to verify. In a September 7, 2022 engineering blog post, Flowable says Camunda 7 and Activiti data can be migrated in place, including active process instances and history, and offers the free Flowable LEAP tool to report ahead of time what a migration involves. Ask Flowable for the LEAP report against a copy of your production schema, and test the migrated data in a non-production environment before committing a cutover date. For the Camunda 8 path, review the Camunda migration tools documentation and confirm what the Diagram Converter does and does not convert for your BPMN, DMN and form files.
How the two exit paths compare on each migration factor
This table breaks the Camunda 7 exit into the factors that drive effort and risk, with Flowable's in-place migration in one column and Camunda 8 with its Diagram Converter in the other. Read each row as a question to answer for your own process estate, and treat items marked to confirm as open until a vendor or proof-of-concept answers them.
| Migration factor | Flowable in-place migration | Camunda 8 with Diagram Converter |
|---|---|---|
| Target architecture | Stays on the Java BPMN engine model, embedded in your application or run as the Flowable REST service | Moves to a separate platform of Zeebe, Operate and Tasklist, with the engine no longer embedded in your application |
| Data and history handling | Flowable says Camunda 7 data, including active instances and history, can be migrated in place (confirm the exact steps and history scope with Flowable) | Process instances and history are not carried over in place; confirm with Camunda how in-flight instances are drained or converted |
| Migration tooling | Free Flowable LEAP tool reports ahead of time what a migration involves (confirm current availability and output) | Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, lists migration tasks and converts them; an AI agent skill orchestrates the migration |
| Licensing for production | Flowable open source engines are Apache-2.0; confirm whether your use needs any commercial Flowable product | Camunda License 1.0 covers Zeebe, Operate and Tasklist and limits use to non-production unless you hold a commercial license from Camunda |
| Java and Spring Boot constraints | Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3, so your application upgrade path matters | Camunda 8 runs as a separate platform; confirm which Java and Spring Boot versions your client libraries require |
| Support options | Community forum for open source users; professional services and partners are offered separately (confirm scope and response terms) | Camunda offers commercial support tied to its production license; confirm support tiers and scope in writing |
| Effort and cost drivers | Effort depends on Spring Boot upgrade, database type and custom identity or listener code; ask for a written scope | Effort depends on the number of diagrams, custom Java delegates, forms and external integrations; ask for a written scope and a migration assessment |
How Flowable keeps active process instances and history in place
Flowable states that Camunda 7 and Activiti data can be migrated in place, including active process instances and their history. That position comes from a September 7, 2022 engineering post, Flowable's post on escaping legacy engines, and it is the core of the in-place argument in this comparison. Flowable also offers LEAP, a free tool that reports ahead of time what a migration would involve. For a team with running instances, that report is the first useful artifact. It shows which process definitions, open instances and history records the move touches, so you can size the work before committing to a path. The post predates Flowable 8.0.0, so ask Flowable which current release line the claim applies to.
The engine model determines what has to move. Flowable's open-source engines execute BPMN process models, CMMN case models and DMN decision tables, expose Java and REST APIs, and are licensed under Apache-2.0. They can run embedded as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers, or be used over HTTP through the Flowable REST application. Embedding means the migration touches your application's dependencies as well as its database. Check whether your Camunda 7 application runs on Spring Boot 3, because Flowable 8.0.0 drops Spring Boot 3 support, so an engine switch on that stack also becomes a framework upgrade. On the database side, the configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and note that MySQL versions below 5.6.4 lack millisecond precision. Confirm that your database and version appear on that list before scheduling any work.
Test the claim on your own stack before you rely on it. Rehearse the migration on a copy of production data that includes running instances, timers and history, using the exact database engine and version you run today. Then compare counts of active instances, open tasks and history records before and after, and confirm that asynchronous jobs and timers still fire. Record which Camunda 7 process versions are in flight, because those are the definitions the migration must carry. If a check fails, the in-place path may still be workable with extra effort, but the plan needs a fallback. Treat the 2022 post as the vendor's stated position, and ask Flowable for written confirmation covering your database, your Camunda 7 version and the Flowable release you would target, with the LEAP report attached.
What drives the effort and risk of each exit
The same Camunda 7 installation can be a small move or a large program depending on a few factors. The cards below cover the ones that most change the work on each path, and what to measure before you compare quotes or plans.
Active process instances and their age
Flowable's documented route moves Camunda 7 data in place, including active process instances and history, so the count and age of running instances shape how much data must be carried over and how long it must be validated. Long-running instances started on old model versions need the most careful review on either path. Inventory running instances by definition and start date, and identify which definitions have no planned end. Instances with old definitions are the first thing to size. Camunda 8 has no in-place path for the same data, so each instance type must be mapped to a new definition and cut over.
Custom Java delegates and listeners
Camunda 7 service tasks, execution listeners and task listeners often call custom Java classes that depend on Camunda 7 API types. Flowable keeps a Java engine API with a similar shape, so some of this code may port with changes to imports and context access, but the exact changes need a line-by-line check. Camunda 8 uses a different client and worker model, so delegates generally need rewriting rather than adapting. Count the classes that import Camunda 7 packages and list which engine services each one calls.
History retention requirements
History is where the migration risk concentrates for regulated teams. Flowable's in-place claim covers history, so retained audit trails can stay in the same database, which keeps reporting queries and retention rules intact. On Camunda 8, historical data is stored in a different architecture, so you need to decide which history is migrated, which is archived in a read-only store and which is dropped under a written retention policy. Confirm with your compliance owner what must be retrievable and for how long before choosing a path.
Database engine and version
Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, so an existing relational backend may stay in place. The documentation also notes that MySQL versions below 5.6.4 lack millisecond precision, which affects timer and history ordering. Camunda 8 persists to a different store set, so a relational Camunda 7 database does not carry over as a runtime. Check your current database engine, version and backup tooling, and confirm them against each vendor's support matrix before committing.
Identity integration
Camunda 7 applications often authenticate users and resolve groups through LDAP or a custom identity provider wired into the engine. Flowable documents that identity management can be replaced by overriding its identity service or implementing its interface, with an LDAP reference implementation provided. That makes an existing directory mapping easier to carry over, but custom group logic still needs testing. On Camunda 8, identity and authorization are configured through its own components, so group and role mappings must be redesigned. Inventory every candidate group lookup and assignment rule before estimating either exit.
Spring Boot and Java version targets
Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so a Flowable move that also upgrades Spring Boot is a larger change than the engine swap alone. Flowable 7.x runs on Spring Boot 3, which can be a stepping stone if your application is pinned to that line. Confirm the Java runtime your organization supports and the Spring versions your libraries require. Treat the framework target as a separate decision from the engine choice, and test each combination before it reaches production.
How to test each migration path on your own data
This sequence turns the Flowable and Camunda 8 options from vendor claims into measured results from your own process definitions, instance volumes and integrations, so the decision rests on evidence from your estate.
Inventory running instances and history volume
Start by listing every deployed BPMN, DMN and form artifact, the number of active process instances per definition, and the size of the history tables. Record which processes call custom Java delegates, scripts, listeners or external services, and which depend on user tasks assigned through your identity source. Your engineering lead and a Camunda 7 administrator should own this inventory. It is done when every definition has an owner, an instance count and a list of custom code references, and the team agrees on which processes must survive the move with in-flight instances intact.
Assess migration effort against a copy of production
Restore a copy of the production Camunda 7 database into a non-production environment and run an assessment against it. Flowable's documentation and its engineering blog describe an in-place migration of Camunda 7 data, including active instances and history, and the free Flowable LEAP tool to report ahead of time what that migration involves. Ask Flowable to confirm LEAP's current scope, supported source versions and the output format before you run it. Done means you have a written report of schema changes, unsupported constructs and instances that need manual handling, reviewed by your database and platform owners.
Run the Camunda 8 Diagram Converter on your models
Run the Camunda 8 Diagram Converter on the BPMN, DMN and form files from your inventory. Camunda's migration documentation says the converter analyzes Camunda 7 files, lists migration tasks and converts them to the Camunda 8 format. Keep the converter output separate from your originals, and have a modeler review every task it flags. Done means you have a per-process list of converted files, flagged tasks and elements that need manual redesign, and an estimate of the rework from your own review, not from the converter alone.
Prototype one representative process on each target
Choose one process that uses a user task, a timer, a call activity, a DMN decision and one external integration. Rebuild it on Flowable 8.0.0 and on Camunda 8 with the same inputs and expected outcomes, then run both through the same test scenarios, including a failure and restart. Confirm the Flowable Spring Boot version your platform needs before building, since Flowable 8.0.0 dropped Spring Boot 3 support. Done means both prototypes pass the same acceptance tests and the team has recorded every change it made to the design.
Measure rework in custom code and identity integration
Count the custom Java classes, listeners, delegates and scripts that must change on each target, and log each change by type. Separately, test how each option connects to your directory and role model, because Flowable documents identity management as replaceable through its IdmIdentityService interface, and Camunda 8 handles identity through its own configuration. Done means you have a per-target list of code changes, identity integration steps and any group or role mapping gaps, signed off by your security and identity owners.
Confirm licensing terms with each vendor
Before you compare costs, confirm the licensing terms in writing. Camunda 8's Zeebe, Operate and Tasklist source files are under the Camunda License 1.0, which limits use to non-production environments and requires a commercial license for production, so ask Camunda to quote the production license for your topology. Ask Flowable to confirm the terms of the Apache-2.0 engines for your deployment and what its commercial products would add. Done means both vendors have answered in writing and the team can attribute each cost line to a specific license or service.
Which exit path suits which team situation
Teams that embed the Camunda 7 engine inside their own Java or Spring services usually have the most to gain from an in-place path, because the engine, its API calls and its database tables already live in code they own. Flowable's engines are also embedded as JARs in Java SE applications, servlet containers and Spring applications, and its documentation describes Spring Boot starters for each engine, so the runtime model stays familiar. This path matters most when the process definitions are mostly standard BPMN and the team wants to keep its service boundaries intact.
- Code change scope: Replacing the engine dependency, the Spring configuration and the API calls is the main job, and the size depends on how much of the codebase calls the engine directly.
- Data migration: Flowable states that Camunda 7 data can be migrated in place, including active process instances and history, per its 2022 engineering post. Confirm this against your exact Camunda 7 version and schema.
- Spring Boot version: Flowable 8.0.0 requires Spring Boot 4 and drops Spring Boot 3, so an upgrade of the surrounding application may be needed too.
- Identity integration: Replacing custom identity logic may require overriding the identity service, which Flowable documents.
- Remaining risk: Custom listeners and Camunda-specific extensions will need rewriting.
Before committing, ask for a written inventory of the Camunda APIs your code calls and of the Spring Boot version your services run.
Teams that have already decided to run a distributed orchestration platform often treat Camunda 8 as the destination rather than a stepping stone. Camunda 8 uses a different runtime architecture from the embedded Camunda 7 engine, so the move is a re-platforming project with its own design work. Camunda publishes migration tooling, including a Diagram Converter that analyzes Camunda 7 BPMN, DMN and form files and converts them, and an AI agent skill that orchestrates the migration. This path matters when the organization is ready to adopt the Camunda 8 operating model.
- Architecture change: Expect new components to deploy, monitor and back up, and new skills for the platform team.
- Converter scope: The Diagram Converter lists migration tasks, but manual rework of listeners, forms and custom code is likely. Ask Camunda which artifacts fall outside automatic conversion.
- Licensing: Zeebe, Operate and Tasklist are under the Camunda License 1.0, which limits use to non-production environments. Production use requires a commercial license from Camunda.
- Running in parallel: Plan for both platforms during cutover, since in-flight instances need a defined handling path.
- Remaining risk: The license cost and the operating model both recur and both sit outside your code.
Ask for the license terms and fee structure in writing before you size the project.
Regulated teams in banking, healthcare and public sector bodies often need a supported production license and a clear support window before they approve a platform. The Camunda 7 Community Edition has stopped receiving releases and security patches after 7.24, so an unsupported engine in production is a finding that auditors and risk teams will raise. Camunda 7 Enterprise Edition has a longer window, with end of life extended to April 9, 2030, and paid extended support through April 2032. Flowable's engines are Apache-2.0 licensed, and its commercial platform is a separate product, which changes what you buy and when.
- Support window: Compare Camunda 7 Enterprise dates with the release cadence of whichever path you choose, and ask each vendor for its written support commitments.
- Production license: Camunda 8 production use requires a commercial license. Flowable's open-source engines carry no license fee, but commercial support and the enterprise platform are separate contracts.
- Evidence: Auditors will look for patch records and version inventories, which DeployOpen can help prepare but cannot certify.
- Vendor dependency: Each path creates a different dependency on a single vendor.
- Remaining risk: Support terms can change, so read the contract for renewal and end-of-life clauses.
Ask your compliance lead which evidence the assessor expects before you choose a path.
Some teams cannot change runtime models yet because process definitions, deployment pipelines or external systems depend on the current engine's behavior. In that case, the question is less about the final destination and more about how much change the first step can absorb. An in-place path keeps the BPMN process definitions and the engine's data model closer to what exists today, which can reduce the surface that must be retested. A move to Camunda 8 changes how processes are deployed and monitored, so it suits teams that can schedule that change.
- Schema compatibility: Flowable documents MySQL precision limits and supported databases such as PostgreSQL, Oracle and SQL Server, so confirm your database engine and version first.
- Async execution: Flowable's async executor uses lock owners and expiration times stored in the database, which affects how nodes must be sized and monitored.
- Test coverage: Retest timers, asynchronous jobs and history queries before any production cutover.
- Phased change: Keep the current engine running on the unsupported version only in a documented, time-limited exception, and record the approval.
- Remaining risk: Deferring the move leaves an unsupported engine in place for longer, so set a decision date.
For this situation, ask for a dependency map covering processes, timers and integrations before scheduling any change.
Questions teams ask before migrating off Camunda 7
How much effort does each Camunda 7 exit path take?
Effort depends mostly on the size and shape of your Camunda 7 estate, not on the target product alone. Count process definitions, DMN decision tables, forms, custom Java delegates, listeners and scripts, Cockpit and Tasklist customizations, and every system that calls the engine through Java or REST. Flowable keeps the engine lineage, but its 7.0.0 release removed the UI applications and the form engine, so any screens or forms you relied on need replacement. Camunda 8 runs on Zeebe, so expect Java code and BPMN to need rework before they run unchanged. Camunda's Diagram Converter analyzes BPMN, DMN and form files, lists migration tasks and converts them, which reduces manual conversion but does not replace testing. Ask each vendor or partner for effort estimates in writing, built from your inventory.
Can our internal team migrate off Camunda 7 on its own?
A small, well-tested estate with engineers who already know the target engine can often be migrated in-house. The deciding factors are test coverage, whether you have a production-like environment for rehearsals, how many integrations depend on engine internals, and whether the team can staff a parallel run without pausing other work. Flowable's in-place migration claim comes from a 2022 engineering post, so treat it as a vendor statement to verify, not a guarantee. Run at least one full rehearsal on a copy of production data before committing to a path. If the rehearsal exposes custom history handling, identity changes or UI replacements that nobody on the team has built before, that is the point to bring in outside help or add targeted training for the engineers doing the work.
What does a Camunda 8 production license require?
The Camunda License 1.0 covers Zeebe, Operate and Tasklist source files and limits use to non-production environments such as development, testing and evaluation. Production use requires a commercial license from Camunda. Only the Java client, Spring Boot starter, exporter API and protocol modules are under Apache-2.0, so budget for the commercial component separately from the open-source client code. Before you sign, ask Camunda in writing which components the production license covers, how it is priced and measured, what support tier is included, what happens at renewal, and whether your deployment model (self-hosted or otherwise) changes the terms. Have legal review the license text alongside your procurement terms.
Is in-place migration of Camunda 7 history safe?
In-place migration can work for history, but safety depends on your data and how well you test it. Flowable's 2022 engineering post says Camunda 7 and Activiti data, including active process instances and history, can be migrated in place, and it offers the free Flowable LEAP tool to report ahead of time what a migration involves. Run LEAP or an equivalent assessment first, then check your history level settings, serialized variables, custom history listeners and timestamp precision on your chosen database. The Flowable configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, which matters for history ordering. Flowable 7.0.0 also removed async history, so confirm your configuration does not depend on it. Test a full restore and rollback on a copy before cutover.
What does a Camunda 7 migration need from internal staff?
A migration needs named owners for several areas, and most teams underestimate the business side. Process owners confirm that each migrated process still behaves as intended. Application engineers rework Java delegates, listeners and integrations. A database administrator plans schema changes, backups and rollback. The identity owner decides how users and groups are supplied, since Flowable documents replacing identity management by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, with an LDAP implementation as a reference. Security staff review access, secrets and hardening. Operations staff own the async executor behavior, monitoring and upgrade windows. Agree who signs off each stage before the work starts, so decisions do not stall during cutover.
How long does a Camunda 7 migration take?
No reliable duration can be stated until you have inventoried the estate, so treat any figure you see without an inventory as a guess. The main drivers are the number of process and decision definitions, the depth of custom Java code, how many systems call the engine, the database platform, and how much testing and parallel running your change process requires. Deadlines matter too. Camunda's February 2025 announcement says no further releases or security patches are made for Camunda 7 Community Edition after 7.24, and Enterprise Edition end of life was extended to April 9, 2030, with paid extended support through April 2032. Ask each path for a written plan with milestones, test gates and a cutover window that fits those dates.
Does Flowable 8.0.0 change the migration plan?
Yes, if your Camunda 7 applications run on Spring Boot 3, because Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support. Its release notes also describe Jackson 3 as the default JSON library, with a Jackson 2 compatibility layer, and removal of JUnit 3 and 4 support. Plan the stack upgrade as its own work item, with dependency and test updates, before you move process data. Flowable 8.0.0 was released on February 27, 2026, so confirm the current stable line and its support window with Flowable before you choose a version. Pin the version in your build and test the Spring Boot upgrade in a non-production environment first.
When is outside help worth paying for during migration?
Outside help is worth considering when your team lacks recent experience with the target engine, when the estate has many integrations or custom extensions, or when the schedule against the Camunda 7 support dates leaves little room for failed rehearsals. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list. For ongoing upgrades and testing after cutover, retainers are available. DeployOpen can prepare systems and evidence for compliance assessments, but independent auditors issue any reports or certifications.
What to confirm with vendors before you commit
Before you choose an exit path, ask both vendors for written answers on the points that decide effort and risk. The first is Flowable's migration support for your exact Camunda 7 version. Flowable's 2022 engineering post says Camunda 7 and Activiti data can be migrated in place, including active process instances and history, and that its free Flowable LEAP tool reports ahead of time what a migration involves. Ask Flowable to confirm in writing which Camunda 7 releases its migration path covers, whether it covers your database engine and whether the LEAP report can be run against a copy of your production schema before any cutover date is set.
The second is Camunda 8 licensing and production fees. Camunda's license for Zeebe, Operate and Tasklist limits use to non-production environments and requires a commercial license for production. Ask Camunda for the production license terms, what they charge for each deployment, whether fees recur annually, and how they apply to your planned clusters and environments. Then ask for the support windows and what extended support covers: Camunda 7 Enterprise has an end of life date of April 9, 2030 with paid extended support through April 2032, and you should confirm whether that paid support includes security patches, bug fixes or only defined escalation.
The third is whether your custom Java code must be rewritten for the target. Ask Flowable which of your listener classes, service task delegates, custom Camunda APIs and identity integrations carry over unchanged, and ask Camunda whether the Diagram Converter and its migration tooling output include code changes or only BPMN, DMN and form conversions. Request these answers as a written migration assessment tied to your own process inventory, and treat any answer that depends on undocumented behavior as an open risk to plan for in your scope.
How DeployOpen helps evaluate and implement a Camunda 7 exit
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Camunda 7 exit is handled as a written, fixed-scope engagement rather than an open-ended project. We help you test both exit paths against your own process models, data and environment before you commit to one.
How we scope
- We agree a written scope covering which Camunda 7 processes, decision tables and history data are in and out.
- We inventory BPMN, DMN and form files, custom listeners, identity integrations and database types to size the migration work.
- We confirm target versions, Spring Boot baseline and licensing position for Flowable or Camunda 8 before build begins.
How we build
- We run a migration rehearsal in a non-production copy of your environment, including active process instances and history.
- We adapt or replace custom Java delegates, REST clients and identity services, then test them against the new engine.
- We check async executor, timer and lock behavior in a multi-node setup that matches your production topology.
How we hand over
- We document the migration runbook, rollback steps, data reconciliation checks and configuration decisions for your team.
- We deliver test evidence and a record of known differences between the old and new engine behavior.
- We train your operators on monitoring, upgrades and day-two tasks, then hand over administrative access and documentation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support covers patching the chosen engine line as new releases arrive, with the upgrade plan agreed in writing.
- Ask any quote to name what is one-time (scoping, migration, handover) and what recurs (retainer, licensing, hosting).
