Migrate from Camunda 8 to Flowable

What moving from Camunda 8 to Flowable involves

Most teams start this move at a renewal, when the Camunda 8 Self-Managed Enterprise license becomes the cost to justify, or when a team needs an embedded Java engine that the Camunda 8 remote cluster model does not offer. Since 8.6, Zeebe, Operate, Tasklist, Identity and Optimize are source-available under the Camunda License v1, and production self-managed use requires the Enterprise Edition, so the business case often turns on that license line. BPMN and DMN models transfer as standard files and can be imported into Flowable's engines with compatibility checks. Job workers, the Tasklist user task experience, and running process instances need planned rework rather than a file copy. Confirm the Camunda license terms that apply to your contract with Camunda directly, since the public documentation is the starting point, not a substitute for your agreement.

The work usually falls to the internal platform or engineering team that owns the Camunda 8 deployment, with an implementation partner brought in for the engine setup, worker rewrites or cutover. Effort depends mainly on how many job workers you have, how much your models rely on Zeebe-specific features, and whether you can drain running instances before cutover. The main risks are workers that behave differently under Flowable's execution model, user tasks that depended on Tasklist, and in-flight instances that must finish on Camunda 8 while new work starts on Flowable. Read the Flowable open source page for the scope of the open-source engines, and ask any partner for a written inventory of workers, models and open instances before agreeing on scope.

Which Camunda 8 capabilities map to Flowable and which need rework

This table maps each Camunda 8 capability to its Flowable counterpart and labels it clean, needs rework or gap. Read it as a migration scoping aid: rework rows are where most engineering time usually goes, and gap rows need a decision about a replacement component or a commercial Flowable product.

Camunda 8 capability	Flowable equivalent	Status and notes
BPMN process execution	Flowable BPMN engine, embedded Java or remote via REST	Needs rework: models are standard BPMN 2.0, but deployment, instance start and variable handling use Flowable APIs, not Zeebe's gRPC client
DMN decision tables	Flowable DMN engine	Clean for standard DMN tables: confirm each hit policy and FEEL expression in your models, since FEEL support must be checked against Flowable's expression language
CMMN case management	Flowable CMMN engine	Clean if you use it: Camunda 8 does not offer CMMN, so this row applies only if you added case models through another tool
Zeebe job workers	Flowable service tasks (Java delegates) or external workers through the REST API	Needs rework: each worker must be rewritten as a delegate, listener or external job client, and retry and error handling must be redone
Operate-style monitoring	Flowable REST API, Spring Boot actuator at /actuator/flowable, and history tables	Gap: Flowable's UI applications were removed in Flowable 7.0.0, so you must build or buy an operations view on top of the APIs
Tasklist (human tasks)	Flowable task API with a custom or third-party front end	Gap: no bundled task inbox in the open-source engines; plan a replacement UI and its identity integration
Identity and authorization	Flowable identity service interfaces, with LDAP reference implementation	Needs rework: map Camunda 8 Identity roles to your own directory and override the identity service interface
Optimize analytics	History tables and your own BI stack	Gap: no built-in process analytics; build dashboards from history data or use a separate BI tool
Commercial Flowable products (Work, Engage, Orchestrate, Design)	Separate commercial products built on the same engines	Not part of the open-source engines: confirm licensing and scope with Flowable if you need low-code modeling or visual debugging

What data and integrations can leave Camunda 8

Some Camunda 8 assets move cleanly, some need rebuilding and some finish in place. The cards separate these so the migration plan starts from what each asset needs. Models, history, identity, workers and the database each carry a different level of effort and risk.

BPMN and DMN models

Exported BPMN and DMN files are standard XML that Flowable's BPMN and DMN engines can deploy, but Zeebe-specific extensions such as task definitions, input and output mappings, and FEEL expressions need review. Flowable uses its own expression syntax, so every condition and mapping must be rewritten and tested. Run each model through a deployment test in a non-production Flowable instance before any cutover. Confirm which Zeebe extension elements appear in your models.

Process history through exporters

Zeebe history leaves through its exporters to Elasticsearch, OpenSearch or a relational database, not as a Flowable-readable history table. Historical data remains useful for audit and reporting, but Flowable does not read it back as its own history. Decide whether archived records stay in the old store under a retention plan or are loaded into a reporting database. Ask your legal and records teams what they must keep and for how long.

Identity through IdmIdentityService

Flowable does not use Camunda Identity. Users, groups and memberships must be supplied through the IdmIdentityService interface, which you can implement against your directory. Flowable provides an LDAP identity service implementation as a reference. Map each Camunda Identity role to a Flowable group and test task assignment for every candidate group before go-live.

Zeebe job workers as Flowable service tasks

Zeebe job workers poll for jobs by task type. In Flowable, the equivalent logic runs either as Java service tasks inside the application or as external workers that call the Flowable REST API. Choose embedded service tasks for code that already lives in the same JVM, and REST-driven workers for code in other languages or teams. Map every task type to one owner and test retries and error handling for each.

Flowable database types and MySQL precision

Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Confirm which database your platform team will operate, since it drives backup, failover and licensing. Flowable's configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, which affects timers and due dates. Confirm your MySQL version before choosing it as the Flowable database.

How the migration sequence runs from inventory to decommission

The sequence moves Camunda 8 workloads to Flowable in controlled stages, so each process family is proven on the target before any production traffic leaves Zeebe. Each step ends with a written output that the next step depends on.

Inventory models, workers and integrations
Your team lists every BPMN and DMN model deployed to Zeebe, every job worker and its job types, every connector, every exporter feeding Elasticsearch, OpenSearch or a relational database, and every identity link between Camunda users, groups and applications. The engineers who own each workload confirm the list, and an architect marks which elements use Zeebe-specific features that have no direct Flowable equivalent. The output is a signed inventory with one row per model and worker, and a gap register naming the features that need redesign.
Build a pilot on the Flowable target
DeployOpen or your engineers choose one low-risk process family and implement it on Flowable, selecting the database type from Flowable's supported list and an embedded Spring Boot or standalone REST setup that matches your platform standards. The pilot replaces each Zeebe job worker with a Flowable service task or an external worker and converts the BPMN model, recording every change the converter cannot handle. The output is a running pilot in a non-production environment, a conversion log, and a list of changes to the model and code conventions.
Prove operations and recovery on the pilot
Before any production traffic moves, your operations team tests the async executor behavior in a multi-node deployment, including lock expiry and job pickup by another node, and confirms that the monitoring endpoint exposes the metrics your on-call runbooks need. The team also rehearses backup and restore of the Flowable database and confirms identity integration with your directory. The output is a signed operations checklist and a tested restore procedure.
Run in parallel with new starts on Flowable
New process instances for the pilot family start on Flowable while instances already running on Zeebe finish there, and both engines feed the same reporting and audit requirements. Business owners compare outcomes, task routing and service-level behavior between the two runs, and the team logs every discrepancy with a root cause and a fix. The output is a parallel-run report that the process owner accepts, with no open defects that block cutover.
Cut over one process family at a time
Once the parallel run is accepted, new starts for that family route fully to Flowable, the Zeebe deployment for it is frozen, and the Tasklist replacement or the application's own task interface takes over human tasks. Teams repeat the same sequence for each family, working from lowest to highest business risk. The output is a cutover record per family listing the release, the routing change, the rollback point and the sign-off.
Decommission Zeebe, Operate and Tasklist
After the last family is cut over and the history retention obligations are documented, the team confirms with records and compliance owners which history must stay queryable and where it will be stored. Exporters are stopped only after that history has been retained in the agreed location, and Zeebe, Operate, Tasklist, Identity and Optimize are shut down in a controlled order. Your licensing contact confirms that no Camunda subscription or Enterprise license remains active for the environment. The output is a decommission record, an archived history store with a documented access procedure, and closed license entries.

Handling running instances without a state transfer

Plan for running Camunda 8 instances to finish where they are. Camunda's documented Data Migrator covers moving running Camunda 7 instances into Camunda 8. It does not document a supported runtime path that carries Zeebe process state into Flowable. The practical approach is a drain window: stop starting new instances on Camunda 8 for the processes you are moving, route new starts to Flowable, and keep the Zeebe cluster, Operate and the job workers alive until every existing instance completes, is cancelled or is handled by a documented decision. Before setting the window length, list the longest-running instances per process from Operate and agree with process owners what happens to instances that are waiting on human tasks, timers or external messages. Those are the cases where a drain can run for weeks, so the Camunda 8 license and infrastructure cost continues for that period.

Version the models and keep both runtimes until the drain ends. Deploy each migrated BPMN and DMN model to Flowable under its own version and keep the Camunda 8 definitions unchanged, so an instance always resolves to the definition it started with. Confirm with the Flowable engine documentation how your chosen version handles deployed definitions and in-flight tokens, and test that behavior with a copy of a representative instance before cutover. For processes where a completed run is not required, you can restart selected instances in Flowable with a documented data mapping that copies business keys and variables that the new process needs. Write that mapping as a reviewed artifact, name an owner for each variable, and record which instances were restarted, cancelled or left to finish, because auditors and process owners will ask for that record.

Confirm the export path with Camunda before you rely on it. The drain strategy also depends on keeping history you may need after Camunda 8 is shut down. The data export options for Camunda 8 history, such as exporters to Elasticsearch, OpenSearch or a relational database, should be confirmed directly with Camunda against your installed version and license, since the documentation for those paths changes between releases. Ask Camunda in writing which history fields are exported, whether the export covers variables and incidents, and how long data is retained. Decide before cutover whether the audit trail will live in your retained store or in a new Flowable database, and test that a sample instance's history can be queried by the people who will need it.

What drives migration cost and duration

This table lists the factors that move effort when moving from Camunda 8 to Flowable, with why each one matters and how to keep it down. Read it before requesting a quote, because the size of your model inventory, worker estate and Spring skills will shape the scope more than any single platform choice.

Driver	Why it moves effort	How to keep it down
Number of BPMN models and DMN tables	Each model needs compatibility review for Zeebe-specific elements, task definitions and FEEL expressions, and each DMN table needs output checks against Flowable's DMN engine.	Inventory models by usage and retire unused ones first. Group similar models so one conversion pattern covers many files.
Count and type of job workers and connectors	Every Zeebe job worker must be replaced by a Flowable service task, a Java delegate or an external worker over REST, and each connector needs its own integration design.	Classify workers by type. Reuse one reusable Java delegate or client library for workers that call the same systems.
Camunda-specific expressions and FEEL details	FEEL syntax and Zeebe variable scoping differ from the expression languages used in Flowable, so expressions and input and output mappings need manual translation and testing.	Extract all expressions into a list early. Test each against sample variables before rewriting models.
Identity and access integration	Operate, Tasklist and Identity roles and users do not carry over, so authentication, group mapping and task assignment must be rebuilt against your directory.	Confirm the target identity model early. Flowable documents identity services that can be replaced, with an LDAP reference implementation.
History and reporting requirements	Zeebe history flows through exporters into Elasticsearch, OpenSearch or a relational database, while Flowable uses its own history tables, so dashboards and reports must be remapped.	List required reports before design. Decide which historical data must be kept and which can be archived read-only.
In-flight instance strategy	Running Zeebe instances rarely move cleanly into Flowable, so teams must choose between draining, restarting or building a bespoke transfer, each with different testing effort.	Ask whether the business can let short-lived processes finish on Camunda 8 while new starts go to Flowable.
Target database and hosting model	Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the async executor relies on database locks, so the chosen database and cluster design change setup and load testing.	Pick a database your team already operates. Confirm the database version and test the async executor on your target cluster.
Internal Java and Spring skills	Flowable is embedded or run as a service in Java, so teams without Spring or Java experience will need training or outside help, which shifts both timeline and cost.	Map existing Java and Spring skills before scoping. Ask for a fixed-scope plan that names who writes delegates and who tests them.

What usually goes wrong and how to prevent it

Most failed Camunda 8 to Flowable moves do not fail in the models. They fail in runtime behavior, operational visibility, identity data and cutover planning. The cards below cover the failure points we see most often and the check that prevents each one.

Worker semantics do not match Zeebe

Zeebe workers activate jobs, hold them for a timeout and retry them according to the retries value on the job. Flowable service tasks run inside the engine transaction, and an exception there rolls back the surrounding unit of work instead of re-queuing a job. Teams that port workers one to one often get duplicate side effects or silent retries. Before cutover, map each job type to either a Flowable service task with explicit error handling or an external worker, and test every failure path, including a call that succeeds but whose response is lost.

Timers and async jobs across nodes

Timers and asynchronous continuations in Flowable run on the async executor, which uses a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. If lock expiry is set too long, a crashed node holds jobs for too long. If it is set too short, two nodes can pick up the same job. Confirm the executor settings in your cluster, run a failover test during a timer-heavy window, and confirm that every node points at the same database and clock source.

Lost operational reporting

Operate and Optimize gave operations teams instance dashboards, incident views and process analytics without custom code. Flowable's open source engines expose REST APIs and, with Spring Boot, an actuator endpoint at /actuator/flowable for monitoring running processes, but they do not ship Operate-style cockpit or Optimize-style analytics. Before cutover, list every dashboard and report that stakeholders used, decide what replaces each one (queries against the history tables, an external BI tool or a commercial Flowable product), and build those views before the old ones are switched off.

Identity mapping gaps

Camunda 8 authorizations were tied to Identity groups, roles and tenant assignments, and Tasklist ownership followed those mappings. Flowable's identity layer is replaceable: you implement or override the IdmIdentityService interface, and an LDAP reference implementation is provided. Users, groups and candidate-group logic must resolve identically in the new engine, or tasks will go unassigned or to the wrong people. Export the current group membership, write a mapping table, and run a test where each role claims and completes its expected tasks.

Cutover without a rollback path

Running Camunda 8 instances usually finish in place, so a cutover that switches new starts to Flowable while Camunda 8 is decommissioned early leaves no way back. Keep Camunda 8 running in read-only or finish-in-place mode until the last in-flight instance completes, and keep the old models and exporter data archived. Define the go or no-go criteria, the owner of each, and the steps to route new process starts back to Camunda 8 if a defect appears in the first production weeks.

How the move differs by starting point

Teams with a handful of processes on Camunda SaaS usually own a small, well-bounded estate. Nothing runs inside your cluster, so the first work is hosting: you must choose where Flowable runs, which relational database backs it, and how it is reached by the systems that currently start instances or receive callbacks. Because the footprint is small, the migration can often proceed one process at a time, with each model converted and tested before the next one moves.

Hosting decision: Decide between an embedded Flowable engine inside an existing service or a standalone Flowable REST service that your own team operates.
Database selection: Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Confirm which of these your organization already operates and backs up.
Model conversion: Map Zeebe-specific task types and expressions to Flowable constructs and test each converted BPMN model against sample inputs.
Worker replacement: Replace each job worker with a Flowable service task, or keep an external worker that calls the Flowable REST API.
Cutover by process: Start new instances on Flowable for one process, keep running Camunda 8 instances where they are, and retire the SaaS subscription only after the last instance completes.

Before you start, confirm with your Camunda account team which SaaS processes have open instances, and whether your contract or data retention terms affect when you can stop using the service.

Questions teams ask before moving from Camunda 8 to Flowable

What drives the cost of moving from Camunda 8 to Flowable?

The cost depends mostly on how many process models, job workers and integrations you have, how much custom code calls Camunda 8 APIs, and how you will operate Flowable afterward. Migration costs are largely one-time: converting models, rewriting workers as Flowable service tasks or external workers, replacing Tasklist, and testing. Recurring costs are infrastructure, database administration, upgrades and support. Flowable's open source engines carry no license fee, but commercial Flowable editions and professional services are sold separately, so the comparison should cover who pays for each component. Ask any implementation partner for a quote built from a written scope that lists models, workers, integrations, environments and the support model you expect.

How long does a Camunda 8 to Flowable migration take?

No duration can be stated in general terms because it depends on the number of models and workers, the depth of Zeebe-specific logic, the number of systems that call the process APIs, and how much regression testing your organization requires. Teams with a small set of BPMN models and a few workers usually scope the work differently from teams with hundreds of models and a shared Tasklist. The most reliable way to get a timeline is to inventory the estate first, classify each model and worker by effort, and agree the scope and deliverables in writing before work begins. Ask for milestones and acceptance criteria in the quote rather than a single end date.

What does the internal team need to provide for the work?

Your team needs people who own the business processes, people who know the Camunda 8 deployment, and people who will run Flowable after go-live. In practice that means access to the existing BPMN and DMN files and their version history, the Zeebe workers and their source code, the systems they call, and the Kubernetes and database environments where the new engine will run. Business owners must confirm expected process behavior and sign off test cases. Platform engineers need to decide how Flowable will be deployed, whether embedded in a Spring application or run as a standalone REST service. Confirm these responsibilities in the written scope so that gaps are visible before work starts.

Can our own engineers do this migration in-house?

Yes, many teams can, particularly where the process estate is small and the engineers already know BPMN and Java. The work is mostly engineering that needs careful testing: converting models, mapping Zeebe job types to Flowable service tasks or external workers, rebuilding the task management UI, and adjusting how expressions and variables are handled. Your team should check whether it has skills in Flowable's Java APIs, Spring Boot 4 and Spring Framework 7 if you target Flowable 8.0.0, database administration and async executor operations. If those skills are thin, a fixed-scope engagement can cover the parts you do not want to learn under deadline pressure, and your team keeps ownership of the processes.

What happens to running process instances during the move?

Running Camunda 8 instances usually finish on Camunda 8 rather than moving to Flowable, because the two engines store state differently and there is no general in-place conversion of Zeebe state to Flowable state. The common strategy is to stop starting new instances on Camunda 8, let existing instances complete, and route new work to Flowable. Where long-running instances must move, the work is case-by-case: you would map variables and current activities by hand and test each mapping. Decide early which instances are long-lived, whether any must be migrated, and how you will keep Camunda 8 running until the last instance completes. Your Camunda 8 history should be exported before the cluster is retired.

Does Flowable cover BPMN, DMN and CMMN?

Flowable's open source engines cover all three standards: BPMN for process execution, CMMN for case management and DMN for decision rules, each with Java and REST APIs under the Apache 2.0 license. Coverage of each standard should still be checked against your models, because Camunda 8 models may use Zeebe-specific extensions, FEEL expressions or job types that need an equivalent in Flowable. Run each DMN table and each BPMN model through a test suite on Flowable before deciding the cutover. Ask the implementation partner to produce a compatibility matrix that lists every element and extension your estate uses and its Flowable equivalent.

Which Flowable release should we target, 8.0.0 or 7.x?

Flowable 8.0.0 was released on February 27, 2026, following 7.2.0 on August 21, 2025 and 7.1.0 on October 7, 2024. The 8.0.0 release upgrades to Spring Framework 7 and Spring Boot 4 and does not support Spring Boot 3, so teams on Spring Boot 3 must plan that upgrade as part of the move. It also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE and removed the UI applications, form and content engines and async history. Check whether your application depends on any removed component before choosing a release line, and confirm the support terms for the version you select.

What should a Flowable migration quote include?

A useful quote lists the scope in writing: the inventory of BPMN and DMN models, the worker and integration list, the target Flowable version and deployment model, the database type, the replacement for Tasklist, the testing approach and the acceptance criteria. It should separate one-time work from recurring items such as support, upgrades and hosting, and state which items are your responsibility. Ask how running instances will be handled, what cutover and rollback steps are included, what documentation and knowledge transfer you receive, and what the post-go-live support window covers. Compare quotes on the same scope rather than on headline totals.

How DeployOpen scopes and runs this migration

DeployOpen plans and implements the move from Camunda 8 to self-hosted Flowable inside your own infrastructure, starting with an inventory of models, job workers and running instances. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every BPMN and DMN model, its Zeebe job types and the workers that serve them.
Classify running instances as finish in place, drain or migrate, and record the decision per process.
Agree in writing which Tasklist, Operate and Identity functions Flowable must replace or retire.

How we build

Test each converted model in Flowable against its Zeebe behavior, covering expressions, timers and error events.
Replace Zeebe job workers with Flowable service tasks or external workers, and test retries and failure paths.
Configure the chosen database, async executor and identity service, then run load and failover tests in your environment.

How we hand over

Document the target architecture, deployment steps, configuration keys and rollback procedure for your operations team.
Deliver test evidence for model parity and cutover, in a form your auditors and change board can review.
Walk your engineers through running Flowable, including upgrade steps between engine versions, before closing the engagement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after cutover.
Ask for a written scope that names the models, workers, databases and environments included before any work starts.
Confirm with your team which Camunda 8 licensing and contract dates drive the cutover window, and plan around them.