Flowable vs Camunda 7 vs Activiti

Flowable documents an in-place migration path for both Camunda 7 and Activiti data, covering active process instances and history, so the question for most teams is whether that path is cheaper and lower risk than rebuilding on a different engine. In its September 7, 2022 engineering blog post, Flowable says this data can be moved without restarting processes, and it offers the free Flowable LEAP tool to report ahead of time what a migration involves. Treat both statements as vendor claims. Before committing, run LEAP against a copy of your production database, then confirm the result with a full migration on that copy. Check how your custom Java delegates, listeners, expressions and forms reference Camunda 7 classes, because those are the usual sources of rework that a data migration does not fix.

Camunda's route is different in kind. Camunda 8 uses a different runtime and process model, so the Camunda 7 migration tooling is a conversion project rather than an upgrade. The Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, lists the migration tasks it finds and converts them to the Camunda 8 format. Camunda also documents an AI agent skill that orchestrates the migration. Both tools handle diagrams and assets, not your Java service code or the running instances, so plan those as separate work. The conversion is also tied to a licensing decision: the Camunda License 1.0 limits use to non-production environments such as development, testing and evaluation, and production use requires a commercial license from Camunda. Ask Camunda for the production license terms and pricing in writing before you scope the conversion.

For Activiti, the decision depends on which version you run and how far it has moved from the engine's original API. Activiti 8.8.1, published on July 14, 2026, is the current release line in the Activiti GitHub releases, and the Activiti README says contributions to version 6.x go to a separate branch. Confirm with the project which line your application can use and whether the current code base, which targets Java 21, matches your runtime. Whichever destination you choose, run a pilot migration of a representative process set, including one long-running instance with timers and one with a call activity, and record the effort in your own environment. That pilot will tell you more about cost and risk than any vendor summary.

The first implementation decision is where the engine runs. Flowable's engines can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications and Java EE servers, or used over HTTP through the Flowable REST application. Embedding keeps process state inside your application's deployment, transactions and release cycle, so your team owns upgrades of the engine along with the application. The REST application moves that ownership to a separate service that other systems call, which changes how you secure, scale and patch it. Flowable's getting started guide describes both models. Activiti follows the same embedding pattern and its README says it runs in any Java application, on a server, on a cluster or in the cloud. The Activiti code base targets Java 21 as its language level, so confirm your runtime JDK before planning. Confirm the Java level required by Flowable 8.0.0 in its release notes, since this section does not state it.

If you use Spring Boot, Flowable 8.0.0 drops Spring Boot 3 support and is built on Spring Framework 7 and Spring Boot 4, so an existing Spring Boot 3 application needs a planned upgrade first. Flowable provides starters for all engines, for REST and for the individual process, CMMN and DMN engines, and exposes the /actuator/flowable endpoint for monitoring running processes. Inside the database, the async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times. Each node must share the same database, and your test plan should include stopping a node mid-job to confirm that expired locks are recovered and the work is picked up elsewhere. Flowable documents H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, so your database platform should be fixed early.

Identity is the last integration decision. Flowable documents that identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, with an LDAP identity service provided as a reference. Directory integration is therefore code your team writes and maintains, and you should check how your directory groups map to the engine's model before work starts. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. To scope an implementation, your team should supply the target JDK and framework versions, the database platform and hosting account, the identity source and its schema, existing BPMN, CMMN or DMN models, and a named owner for upgrades and test sign-off. A quote follows from that written scope.

DeployOpen plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a BPMN engine decision, that work can start before any code is written: agreeing which of the three engines fits the process estimates, Java and Spring versions, database platform and identity model, then recording those choices in a written scope. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. DeployOpen does not publish a price list, so ask each candidate to show which components, environments and handover documents its quote covers.

DeployOpen can work with any of the three engines, Flowable, Camunda 7 or Activiti, and the choice should follow your own requirements rather than a preference. The questions that usually decide it are whether you need CMMN or DMN alongside BPMN, which Spring Boot line your platform team runs, whether you are moving existing Camunda 7 or Activiti process data, and whether you need a commercial support contract. Confirm each of these against the current release notes and license terms for the version you plan to deploy, because support windows and editions change. DeployOpen is not an official partner, reseller or certified provider of Flowable, Camunda or Activiti, and it does not issue certifications or attestations. Any compliance evidence it prepares is for your independent auditor to assess.

Implementation work usually covers the engine configuration, the database and async executor settings, identity integration, hardening, backup and restore testing, and documentation for your operations team. Ask for each of these to be listed as a deliverable with an acceptance check, such as a tested restore of the process database or a documented upgrade path to the next engine release. Ongoing support, upgrades and continuous testing are available as retainers, so decide early whether you need a one-time delivery, a retainer, or both, and ask how each is priced and what it excludes.