Migrate from Camunda 7 to Flowable: what the move involves
Teams still running Camunda 7 need a supported engine without re-platforming to Camunda 8. Flowable is an Apache-2.0 licensed BPMN, CMMN and DMN engine with a documented in-place migration path for Camunda 7 and Activiti data, including active process instances and history. The effort depends on three things: how much custom Java code sits in delegates, listeners and scripts, how much history your reporting depends on, and which relational database you run. Platform engineers usually do the work, often with a migration partner who handles the assessment and cutover plan. The Camunda 7 Community Edition repository is archived and received its last release in October 2025, so the risk of staying put grows with every unpatched dependency. Camunda 7 Enterprise support runs to April 9, 2030, with paid extended support from April 2030 through April 2032, which gives Enterprise customers a window to plan but not indefinitely.
Start with the assessment, not the code. Flowable says its free LEAP tool reports ahead of time what a migration involves, so run it against a copy of your production database and treat the output as the first version of your scope. Ask the vendor or partner to confirm the LEAP version that matches your Camunda 7 baseline and the Flowable release you plan to target, because the current major line, 8.0.0, changed its Spring Boot and Jackson requirements. Inventory the Java delegates, expression language usage, custom history handlers and identity integrations, since these are the parts that will not convert automatically. Confirm with the database team that your chosen database type is on Flowable's supported list and that the migration window covers history tables, which often take the longest to move.
Plan the cutover around the running instances. Decide early whether in-flight processes finish on the old engine, migrate in place, or are restarted, and document the rules for timers and asynchronous jobs, since Flowable's async executor relies on lock owners and lock expiration stored in the database. Test the rollback path on a full-size copy of the database. Keep the Camunda 7 cockpit and Tasklist available read-only until history reporting is confirmed, and agree in writing with your partner which items are in scope, what evidence the rehearsal produces and who signs off the go-live decision.
Which Camunda 7 capabilities map cleanly to Flowable
This table compares the Camunda 7 capabilities that a Flowable migration depends on, with a status for each: clean, needs rework or gap. Use the status as a starting point for scoping, and confirm every row against your own models, endpoints, database and identity setup. The main takeaway is that the engine and model layers map well, while the REST, persistence, identity and web tooling layers need deliberate work.
| Capability | Camunda 7 today | Status on Flowable | What to verify |
|---|---|---|---|
| BPMN process execution | BPMN 2.0 executed by the embedded or shared Camunda 7 engine | Clean | Flowable executes BPMN; check extension elements, listeners and custom properties in your models |
| CMMN case management | CMMN supported in the Camunda 7 engine | Clean | Flowable provides a CMMN engine; test each case model against its runtime behavior |
| DMN decision tables | DMN evaluated by the Camunda 7 decision engine | Clean | Confirm hit policies, input and output types, and the expression language used in each table |
| Embedded engine model | Engine runs inside a Java application, as a shared engine or standalone | Clean | Flowable embeds as a JAR in Java SE, servlet containers, Spring and Java EE; check Java delegate class names |
| REST API | Camunda 7 REST API used by external systems and custom clients | Needs rework | Do not assume Camunda-compatible resources or payloads; test every endpoint your clients call against Flowable's REST application |
| Relational persistence | Engine persists through MyBatis to a relational database with the Camunda 7 schema | Needs rework | Flowable supports several relational databases and states in-place migration is possible; run LEAP to confirm schema and data steps |
| Tasklist and Cockpit | Web applications for user tasks and process monitoring | Gap | Flowable removed its UI applications in version 7; plan a replacement task list and monitoring UI |
| Admin tooling | Admin application for users, groups and permissions | Gap | Flowable's commercial products add visual debugging and governance; Spring Boot actuator at /actuator/flowable covers monitoring only |
| Identity integration | Camunda 7 identity service and its user and group lookups | Needs rework | Flowable documents replacing identity management through IdmIdentityService, with an LDAP reference implementation to adapt |
What data and integrations move, and what you rebuild
A Camunda 7 to Flowable move splits into data you can carry across and integration code you rewrite. Running instances and history have a documented in-place path, while Java delegates, REST clients, Tasklist dependencies, identity wiring and scripts need deliberate rework. Check each group against your own inventory before scoping.
Running instances and history
Flowable's 2022 engineering post says Camunda 7 and Activiti data can be migrated in place, including active process instances and history. This is the main reason a Camunda 7 team may stay on the same database model rather than restart every case. Confirm with Flowable whether your exact Camunda 7 version and history level are covered, and test with a copy of production data before choosing a cutover window. Treat history volume as a sizing input, since it drives migration runtime and storage.
Pre-migration report with LEAP
Flowable offers the free LEAP tool to report ahead of time what a migration involves. Run it against a representative copy of your Camunda 7 database before estimating effort, because it surfaces data and schema differences that a code inventory will not show. Ask Flowable which findings they treat as blockers and which as manual tasks. Keep the report with your change records so the decisions are traceable.
Supported target databases
Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. Match your current database vendor and version to that list, or plan a database change as a separate project. MySQL versions below 5.6.4 lack millisecond precision, which affects timer and history timestamps. Confirm the database choice before you run LEAP, since the report depends on it.
Java delegates and listeners
Camunda 7 Java delegates, task listeners and execution listeners implement Camunda interfaces and import org.camunda classes. Each one must be rewritten against Flowable's delegate and listener APIs and retested with the same process variables. Build a list of every delegate class, its variables and its transaction behavior, because embedded Java logic often carries the business rules. Assign owners to each class before development starts.
Camunda REST clients and Tasklist dependencies
Any service that calls Camunda 7 REST endpoints, or a user interface built on Tasklist, Cockpit or Admin, must be rebuilt against Flowable's REST application or your own front end. Flowable's REST API differs from the Camunda API, so client code needs mapping, not just a URL change. Identify which user tasks depend on Tasklist behavior, such as task filters and assignment views, and decide what replaces them.
Identity, LDAP and custom scripts
Flowable says identity management can be replaced by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and it provides an LDAP identity service as a reference. Map every group lookup, role check and directory call in your Camunda 7 setup to that interface. Custom scripts in BPMN and in Java also need review, since expression languages and script engines may behave differently. Validate BPMN and DMN files in Flowable before deployment, because models written for Camunda 7 may not load unchanged.
The migration sequence from inventory to decommission
This sequence takes a Camunda 7 estate from a documented inventory to a verified Flowable production system, with each step producing an artifact that the next one depends on. It keeps the cutover reversible until the evidence supports decommissioning Camunda 7 and its archived dependencies.
Inventory models, custom code and database
Your team, with DeployOpen if you engage us, lists every deployed BPMN and DMN model, CMMN case, Java delegate, listener, script task, custom form, external task worker and REST client that touches the Camunda 7 engine. The same pass records the relational database, schema version, history level, job executor settings and any dependencies on the Cockpit, Tasklist and Admin applications. The output is a dependency inventory with an owner and a business criticality for each process. The step is done when every running definition appears in the inventory and someone outside the team has reviewed it.
Run a LEAP assessment
Run Flowable's free LEAP tool against the inventory and a copy of the Camunda 7 database, so the migration effort is reported before any change is made. Flowable's engineering post describes this as a way to see ahead of time what a migration involves. The output is a migration report that lists unsupported constructs, expression and API changes, and data that needs special handling. Confirm the tool's current version and output format with Flowable before you rely on it for planning, and treat the report as the input to the scope agreement.
Pilot one non-critical process on Flowable
Choose one process with low business risk, few custom classes and a clear success measure, then rebuild it on a Flowable engine in a non-production environment. Rework its Java delegates, expressions and job configuration, and run it against representative test data, including timer and asynchronous job behavior. The output is test evidence: a record of test cases, results, defects and the fixes made. The pilot is complete when the team has a repeatable build and deploy path and the open issues are understood.
Run a parallel period with both engines
Keep Camunda 7 running for existing work while new process instances start on Flowable for the pilot and then the next agreed processes. Compare outcomes, audit records, database growth and job execution between the two engines, and reconcile any differences before expanding scope. The output is a parallel run log and a reconciliation report that shows where results match and where they do not. Expand the scope only after the reconciliation has no unexplained differences for the processes in question.
Cut over and handle in-flight instances
For each process, decide whether in-flight instances drain on Camunda 7 to completion or are migrated to Flowable with their state and, where agreed, history. Migration of running instances needs a tested mapping and a reconciliation count on both sides before traffic moves. The output is a cutover runbook with a signed-off instance strategy, a verified count of migrated and drained instances, and a rollback plan that states the trigger, the owner and the steps to return traffic to Camunda 7. The step closes when the rollback has been rehearsed in a non-production environment.
Decommission Camunda 7 and archived dependencies
After the agreed drain period and the final reconciliation, stop the Camunda 7 engine, remove its web applications and REST endpoints from service, and retire the scheduled jobs and integrations that pointed at it. Archive the Camunda 7 database under your retention policy, then remove the archived Camunda 7 repository and library dependencies from build pipelines so no team rebuilds against them. The output is a decommission record listing each retired component, the retention location of the data and the access controls applied to it. Confirm with your compliance owner which retention and access requirements apply.
What drives the cost and duration of this move
This table lists the components that set the cost and duration of moving Camunda 7 to Flowable, who typically pays for each, and what keeps it down. Use it to structure a written quote, since no figures are given here and each row names what to ask for.
| Driver | Who pays | What keeps it down |
|---|---|---|
| Running instances and their complexity | Internal team and any migration partner | Drain or complete instances before cutover where the business allows, and keep the number of in-flight versions small |
| History volume and depth | Internal team, with storage and DBA time paid by the operator | Decide which history must move and which can be archived, and run a LEAP assessment to size it before scoping |
| Custom Java delegates and listeners | Internal developers or a partner on a fixed-scope rewrite | Keep delegates thin, isolate Camunda imports behind adapters, and count classes that reference org.camunda APIs early |
| Tasklist and Cockpit usage | Internal team for replacement UI or operations tooling | Confirm which Camunda web applications users depend on, since Flowable's UI applications were removed in version 7.0.0 |
| Identity integration | Internal identity team, plus developers for the IdmIdentityService | Reuse an existing LDAP or directory setup, using the LDAP reference implementation Flowable documents where it fits |
| Database platform and migration tooling | DBA team and infrastructure owners | Use a database Flowable supports, such as PostgreSQL or Oracle, and test the schema migration on a copy of production data |
| Spring Boot 4 upgrade | Internal developers, since Flowable 8.0.0 requires Spring Boot 4 and Spring Framework 7 | Stage the Spring Boot 3 to 4 upgrade separately from the engine move, and confirm that all libraries support Jackson 3 defaults |
| Testing and compliance evidence | Internal QA and compliance teams, or a partner for regression and evidence packs | Reuse existing process tests, define acceptance criteria for migrated instances, and ask the auditor which evidence they expect |
| Support contracts | Organization pays Flowable or a partner for commercial support, or the internal team carries it | Compare community support against a paid contract in writing, and confirm response terms and the Flowable version window in the quote |
How the path differs by starting point
When the Camunda 7 engine runs inside your Spring Boot application, the engine version is a library dependency that ships with the application. Engine hosting stays in the same deployable, so moving to Flowable means replacing the Camunda starters, the Java delegates and the configuration beans with their Flowable equivalents, then redeploying the application as one unit.
- Engine hosting: The engine, its job executor and its database connection live in the application process, so Flowable's embedded model is the closest fit and the async executor settings move with the code.
- Upgrade path: The application team controls the timing, but the Spring Boot and Java baseline of the new Flowable release must be checked against your current stack before any code changes. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so an application on Spring Boot 3 may need a platform step first.
- Testing scope: Process tests, delegate unit tests and any Camunda-specific test utilities need rewriting, and the full set of user tasks should be exercised against Flowable's Spring Boot starters.
- Data path: In-place migration of running instances and history is the main data question, so run Flowable LEAP against a copy of the production schema early.
- What to decide first: Confirm the target Flowable major version, the Spring Boot baseline and whether in-flight instances must survive the cutover or can drain.
Confirm the Spring Boot baseline and the Flowable release line in writing before estimating the rework.
When one Camunda 7 engine runs as a shared or standalone service and several applications deploy process definitions into it, the engine is a platform component with its own owners, schedule and data. A migration moves that platform, and every consuming application depends on the cutover window, so the work is coordinated rather than local.
- Engine hosting: The engine is typically run as a separate service with REST access, so Flowable's REST application or a deployed engine service replaces the Camunda REST layer and client calls need new endpoints or a compatibility shim.
- Upgrade path: All consuming teams must agree on a cutover date, and the new engine must be stood up beside the old one before any application is switched. Plan for a period where two engines run in parallel.
- Testing scope: Contract tests for every application's REST calls, deployment pipelines that push BPMN and DMN files, and the authorization model shared across tenants all need verification.
- Data path: Shared databases hold instances from many applications, so the migration tooling and LEAP report should be run per schema and per tenant, not once for the whole estate.
- What to decide first: Name one owner for the cutover, agree the freeze window with each consuming team, and decide whether identity moves to Flowable's identity service or stays external.
Ask each consuming team to list the REST endpoints and deployment steps they use, because that list defines the test scope.
When the estate has custom listeners, many history consumers, custom job logic and reporting that reads history tables directly, the migration is mostly about the things around the engine. Engine upgrades are the easy part, while the downstream readers of history data and custom code decide the schedule.
- Engine hosting: Custom engine plugins, event listeners and extensions must each be classified as portable, rewritten or retired, and their deployment unit may need to change.
- Upgrade path: Reports and dashboards that query Camunda history tables need a new source, because Flowable's history schema differs from Camunda 7's and the history migration path needs verification for your version. Plan a parallel run for reporting.
- Testing scope: Each history consumer needs a test against the target data model, and custom listeners need regression tests with real process variables.
- Data path: Confirm with Flowable and your own data team how history migration will be handled for your volume, and whether reporting will move in the same wave.
- What to decide first: Inventory every history consumer and custom class, then decide which reporting continues from a warehouse copy rather than the live engine tables.
The inventory of history consumers is the document that sets the timeline, so build it before any engine work starts.
What usually goes wrong and how to prevent it
Most Camunda 7 to Flowable projects stall on the same few issues: state that does not carry over cleanly, upgrade dependencies, clustered job handling, hidden API coupling and unclear ownership during coexistence. Each card names one failure and the check that catches it early.
In-flight instances stranded by model changes
Running instances are bound to the process definition version they started on. If the BPMN models, variable names or service task implementations change during the move, instances can stop at a token that no longer exists or fail when a delegate expression cannot resolve. Before cutover, run the LEAP assessment on the real database and list every definition that has active instances. Decide per definition whether instances finish on the old engine, migrate in place or restart, and test one stranded instance end to end in a staging copy.
History gaps mistaken for data loss
Flowable's in-place migration covers active process instances and history, but reports and audit views built on Camunda 7 tables or Cockpit queries can return fewer rows after the move if column mappings or history levels differ. Teams often discover this during an audit request rather than during testing. Compare row counts and sample records for completed instances, variables and task history between the source and target databases, and record which historic fields are kept, transformed or dropped. Get the sign-off from the compliance owner in writing.
Spring Boot 4 upgrades that stall the project
Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 and does not support Spring Boot 3, while Flowable 7.0.0 moved to Spring Boot 3 and Java 17. A team moving from Camunda 7 on an older Spring stack may need to upgrade the application framework, Jackson and test tooling at the same time as the engine. Removed JUnit 3 and 4 support also breaks older test suites. Separate the framework upgrade from the engine migration, pick the Flowable major version first, and confirm the Java runtime and JUnit versions before estimating the work.
Async job locks misconfigured across nodes
Timers and async jobs run on a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. Camunda 7 clusters often ran with defaults that were never reviewed. If the lock duration is too long, a failed node holds jobs for too long, and if it is too short, slow jobs get picked up twice. Confirm the async executor settings on every node, verify that the database clock and MySQL precision meet Flowable's requirements, and load test timer-heavy processes on a cluster before go-live.
Undocumented Camunda API calls in other code
Front-end code, reporting jobs, partner integrations and scripts often call the Camunda 7 REST API or read its tables directly, and nobody lists them as dependencies. Once the engine changes, these callers fail silently or return different payloads. Search the source tree, gateway logs and database query logs for org.camunda references, REST paths and direct SQL against engine tables, and assign each caller an owner. Decide whether each one moves to Flowable's REST API, to a stable internal interface or is retired.
Two engines without an ownership rule
During a staged migration, some processes run on Camunda 7 and others on Flowable, often in the same application and sometimes sharing tasks, users or identity services. Without a rule, teams start a new process on the wrong engine, patch one engine and forget the other, or let identity data drift. Write down which engine owns each process definition, who approves changes to the shared identity service and when the Camunda 7 instances are expected to reach zero. Review that register at each release until the old engine is switched off.
Questions teams ask before moving from Camunda 7 to Flowable
Can running Camunda 7 process instances move to Flowable in place?
Flowable states that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history, according to its September 2022 engineering blog post. That is a vendor statement about its own tooling, so treat it as the starting claim to test. Confirm with Flowable which Camunda 7 versions and database types the in-place path covers, how it handles your custom Java delegates and listeners, and what cutover window it needs for your volume of running instances. Ask for the result in writing before you plan around it. The free Flowable LEAP tool exists to report ahead of time what the migration involves, so run it against a copy of your environment first.
How long does a Camunda 7 to Flowable migration take, and what drives it?
No supplied figure gives a duration for this migration, so the answer depends on your estate. The main drivers are the number of BPMN, CMMN and DMN models, how much custom Java code calls the Camunda API, how many running instances must finish or move, whether you need history, and how many integrations depend on the REST API. Each driver grows the work in a different way. A LEAP assessment gives you a list of what the migration involves, which is the best input for a fixed-scope estimate. Ask any provider to break the effort down by these drivers and to state which parts are assumptions.
What does our team need to provide for the migration?
The migration needs access to the Camunda 7 database and engine configuration, the full set of deployed BPMN, CMMN and DMN files, and the source code of any custom delegates, listeners, scripts and REST clients. You also need a non-production copy of the database, a representative set of running instances, and named owners in operations and the business who can approve test results. Flowable's embedded and REST models differ from Camunda 7 in some configuration and API details, so someone who knows your process applications must be available for testing. Ask any provider to list these inputs in the written scope.
Can our own engineers do the migration without an outside partner?
Yes, a capable Java team can run the migration in house, provided it has time to test and the skills to change code and configuration. Flowable's open-source engines are Apache-2.0 licensed and documented, and the engine is embeddable in Spring and servlet applications. The harder work is usually the custom code, the operational changes such as the async executor and database locking, and the regression testing across running instances. Consider which of these your team has done before. An external partner is one option for the fixed-scope parts, and that choice is separate from the license decision.
Is Camunda 8 still an option, and how does its licensing differ?
Camunda 8 remains an option, but its licensing is different. From Camunda 8.6, the core components Zeebe, Operate, Tasklist, Identity and Optimize are under the Camunda License v1, and production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. Without a commercial license, Camunda 8 Self-Managed may only be used for non-production purposes. Camunda 8 also uses a remote engine on Kubernetes rather than the embedded Java engine of Camunda 7, so the migration is a re-platform, not a version upgrade. Confirm current terms with Camunda in writing, since the license text and editions can change.
What does Flowable's commercial editions add over open source?
Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance, according to Flowable's open-source page. Open-source users get a community forum, while professional services and partners are offered separately. The open-source engines remain Apache-2.0 licensed, so the core engine does not depend on a commercial purchase. Decide which of the commercial features your operations team actually needs, and ask Flowable which of them are required for production support and which are optional.
Does the Camunda 7 end of life date change the decision?
Yes, the date sets the deadline for any plan. Camunda 7 Community Edition received no further releases or security patches after 7.24, scheduled for October 14, 2025, and its repository is archived. Camunda 7 Enterprise end of life was extended to April 9, 2030, with fee-based extended support from April 2030 through April 2032. If you stay on Enterprise, you still need a migration path before those dates. Plan your migration window against the support date for your edition and confirm the exact terms with Camunda in writing.
How DeployOpen scopes and runs the Flowable migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Camunda 7 move to Flowable, that means the engine, its database, the identity service, the job executor and the surrounding application are delivered as one operated system in your environment, not as a hosted service. DeployOpen is not a Flowable partner or reseller, so the engine itself is the open-source Apache 2.0 project, and any Flowable commercial product or professional services contract is a separate decision that you make directly with Flowable.
Most migration work is fixed-scope. Before work starts, the written scope should name the Camunda 7 version and its database, the in-flight process instances and whether their history must move, the Flowable LEAP assessment output that informs the plan, the custom Java delegates and listeners to port, the identity source to replace, the target database from the supported list, and the acceptance tests for each process. Deliverables should cover the migrated engine, cutover runbook, backup and restore procedure and documentation. Timelines are agreed in that same document, and any change to scope is handled as a written change request.
After cutover, many teams want ongoing support, upgrades and continuous testing. These can be covered by a retainer, which recurs, while the migration itself is one-time. Security testing of the workflow application and its APIs, and compliance readiness support that prepares systems and evidence for an assessment, can be scoped as separate work. DeployOpen prepares controls and evidence but does not issue audit reports or certifications, so ask your auditor early which evidence they will need from the engine, the database and the access model.
