Migrate from Activiti to Flowable

Migrate from Activiti to Flowable: what the move involves

Teams running Activiti 5 or 6 process applications need a supported engine, and the good news is that the move does not have to be a rebuild. Flowable's engineering team has documented that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history. That makes the work a planned upgrade of process models, Java delegates, configuration and runtime, with the existing data carried forward. Most of the effort sits in the platform baseline rather than in the diagrams. Flowable's open source engines for BPMN, CMMN and DMN are licensed under Apache 2.0, so the target platform carries no license cost, but the surrounding Java, Spring and Jakarta changes are where the schedule is decided. The first practical step is the free Flowable LEAP report, which Flowable offers to show ahead of time what a migration involves. Ask for it before estimating anything, and confirm its scope against your own inventory of deployed definitions, custom listeners and external dependencies.

The baseline changes depend on the target version. Flowable 7.0.0 moved the engines to Java 17, Spring Boot 3 and Jakarta EE, and removed the UI applications, the form and content engines, Mule integration and async history. If your applications use any of those, they need a replacement decision before cutover. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, made Jackson 3 the default JSON library with a Jackson 2 compatibility layer, and removed JUnit 3 and 4 support. Teams that skip 7 and go straight to 8 must therefore upgrade their JDK, Spring stack, JSON handling and test framework together. Your engineers should list every javax import, Spring Boot starter, Jackson annotation and JUnit 4 test in the current code base, since these drive the rework and the regression test effort. Decide early whether to target the 7.x line or 8.0.0, because that choice sets the Java and Jakarta changes for every other workstream.

Which Activiti capabilities map to Flowable and which need rework

This table compares the Activiti features most process applications depend on with their Flowable counterparts. Each row gives a classification and the items to check in your code and models before cutover. Most rows call for adaptation, but history, identity, REST clients and the UI tooling need closer review because Flowable 7 removed several components.

Capability	Flowable equivalent	Classification	What to verify
BPMN process execution	Flowable BPMN engine executing BPMN 2.0 process definitions	Needs adaptation	Redeploy every definition, run regression paths, and confirm in-flight instances resume after the in-place migration
Service tasks and Java delegates	Java delegate classes and service task bindings in the Flowable engine	Needs adaptation	Delegate class names, imported interface packages, and any Activiti-only base classes against the Flowable version you target
Expressions and variables	Flowable expression language in sequence flows, listeners and tasks	Needs adaptation	Expression syntax, variable scope, and any calls to Activiti-specific expression functions or beans
User tasks and assignment	Flowable task service with candidate users, groups and assignees	Needs adaptation	Candidate group names, assignment listeners, and task queries that depend on Activiti identity tables
Timers and async jobs	Flowable async executor using thread pools and lock owners stored in the database	Needs adaptation	Job and timer definitions, lock expiry settings, and thread pool sizing for each node
History	Flowable history service, with async history removed in Flowable 7	Needs redesign if async history is used	Whether your Activiti application relies on async history, history retention rules, and queries against history tables
Identity and users	IdmIdentityService interface or an overridden IdmIdentityServiceImpl, with an LDAP reference implementation	Needs redesign if identity logic is custom	Custom user and group lookups, and whether they can move into an IdmIdentityService implementation
REST access	Flowable REST application and REST APIs for engines	Needs redesign	Client calls to Activiti REST paths, payload shapes, and authentication setup for each consuming system
Modeler, forms and UI tools	No equivalent in Flowable 7 or later for the UI applications and form engine	Needs redesign	Which Activiti UI screens and form definitions your users depend on, and the replacement you will build or buy

Documented migration paths and tools for Activiti to Flowable

Flowable documents a small set of paths for moving Activiti work onto current engines. The cards below cover the advance assessment tool, the in-place migration approach, the target runtime documentation and the interfaces your migrated application will call. Read them together before you commit to a migration scope.

Flowable LEAP report

Flowable offers the free LEAP tool to report ahead of time what a migration involves. Run it against a copy of your Activiti database and deployed process definitions before estimating work. Review the output for unsupported elements, custom listeners and data that will not carry over cleanly. Treat the report as the input to your scope, and confirm with Flowable which Activiti version and release line the tool covers for your environment.

In-place migration of active instances

Flowable's September 7, 2022 engineering post says Activiti data can be migrated in place, including active process instances and history. In-place migration avoids draining running work, but it changes the data your operations team depends on during cutover. Decide how long in-flight instances may stay on the old engine, who signs off on the migrated data, and how you will roll back if counts or variables disagree after the move.

Target runtime configuration

The Flowable configuration docs list the supported database types, including H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. They also note that MySQL versions below 5.6.4 lack millisecond precision, which affects timer and history ordering. Check your database version and schema settings against this list before the migration rehearsal, because a mismatch can surface only after instances move.

Spring Boot starters for the target

If your Activiti application runs as a Spring application, the Flowable Spring Boot docs describe starters for all engines, for REST and for the individual BPMN, CMMN and DMN engines. The docs also describe an actuator endpoint at /actuator/flowable for monitoring running processes. Map each Activiti starter or bean to its Flowable counterpart, and confirm the starter set for your exact target version with Flowable.

Engine APIs and REST interfaces

The migrated application will call the Flowable engine Java APIs, or the Flowable REST application over HTTP, depending on how you embed the engine. Inventory every Activiti service call, REST client and custom task that touches the runtime or history services. Confirm with Flowable which Activiti APIs have direct equivalents, which change names or signatures, and which must be rewritten before you test the migrated application.

Version-specific steps to confirm

Flowable 7 moved to Java 17, Spring Boot 3 and Jakarta EE, and Flowable 8 moved to Spring Framework 7 and Spring Boot 4 with Jackson 3 as the default JSON library. Each jump can break classpath, servlet and serialization assumptions in Activiti code. Ask Flowable which target release matches your Activiti version and runtime baseline, and plan the Java and framework upgrades as separate steps with their own tests.

How the migration runs from inventory to decommission

The sequence moves Activiti work from a documented inventory to a verified cutover and a removed Activiti runtime, with each phase producing evidence that the next phase depends on. Sign-off sits with named owners at each gate rather than at the end of the project.

Inventory process definitions and their dependencies
Start by listing every deployed process definition, each Activiti version in use, and the Java classes that run inside it: service task delegates, execution and task listeners, event listeners, custom expressions and scripts. Add the forms, REST front ends, message and HTTP integrations, identity lookups and scheduled timers that the processes depend on, and record which application or team owns each one. The output is a versioned inventory with an owner per item. The business process owner and the application lead sign off that nothing active has been left out, because items missing here will surface later as failures in production.
Run the LEAP report against a database copy
Take a copy of the Activiti database, not the production database, and run the Flowable LEAP tool against it. Flowable describes LEAP as a free tool that reports ahead of time what a migration involves, so the report shows which runtime data, history and configuration will need attention. Review each finding with the engineers who wrote the processes and classify it as a blocker, a manual change or a non-issue. The output is a signed gap list that the platform owner accepts before any code changes begin. Confirm the current LEAP version and its supported source releases with Flowable before you run it.
Port delegates, listeners and models to Flowable
Change the Java packages, imports and configuration that refer to Activiti so the delegates, listeners and BPMN models compile and deploy against the target Flowable engine. Confirm the Java and Jakarta baseline the target release requires, since moving to Flowable 7 or 8 also changes the runtime platform, and adjust the build and container images to match. Expression and script usage needs the same review because some constructs behave differently across engines. The output is a build that deploys every process definition from the inventory without errors. The application lead signs off the port once the deployment check passes on a developer environment.
Pilot on a non-production copy with in-flight instances
Restore a recent copy of the production Activiti database into a non-production environment and run the migration there, including the active process instances, timers, jobs and history. Compare counts of instances, open tasks, pending jobs and variables before and after, and drive a set of representative instances through to completion on the new engine. Record every discrepancy with its cause, and repeat the run until the pilot is clean for the cases the inventory marks as critical. The output is a pilot report with the migration steps, timings observed in that environment and the open issues. The operations owner and the business owner of each process sign off on the report.
Operate a parallel run with routed new instances
Keep Activiti serving existing instances while new instances start on Flowable under a routing rule that the application controls, such as a process category, a tenant or a start date. Monitor failed jobs, error rates, task completion and the response of each integration on both engines, and compare outcomes for equivalent work. Fix defects in the Flowable build and redeploy definitions through the same pipeline used in production. The output is a run log with routing decisions and a defect list that is empty for the critical processes. The application owner and the security or compliance reviewer both sign off before the cutover date is fixed.
Cut over active instances and history
During an agreed change window, stop new starts on Activiti, drain or pause its async executor, and run the in-place migration of active process instances and history against the production copy that the pilot validated. Flowable's engineering material says Activiti data can be migrated in place, including active instances and history, so the cutover is about verifying that the migrated state matches the pilot. Re-check the instance, task, job and history counts against the pre-cutover snapshot, then reopen Flowable for traffic. The output is a cutover record with counts, the rollback point and the timestamps of each action. The on-call engineer and the business owner confirm that work continues correctly before the window closes.
Decommission Activiti and retain the evidence
Once the cutover has run without open defects for the agreed observation period, remove Activiti from the runtime, stop its scheduled jobs, revoke the database access it used and archive its configuration. Keep the inventory, LEAP report, pilot and cutover records, and the history data needed for audit or regulatory retention, and document where each lives. The output is a decommission record and an updated architecture and runbook for the Flowable estate. The platform owner and the compliance lead sign off, and the Activiti artifacts are retired only after that sign-off is on file.

What drives effort and cost in an Activiti to Flowable move

This table lists the factors that move effort and cost in an Activiti 5 or 6 to Flowable move, how each one behaves over time, and what to ask for in a quote. Read it before scoping, because the first three rows usually decide how much assessment work comes before any build work. The main takeaway is that a fixed-scope quote depends on an inventory of your definitions, instances, history and custom code, not on the Flowable version alone.

Driver	Why it changes effort or cost	One-time or recurring, and what to ask for
Activiti version (5 or 6)	Each source line has its own schema and API differences, so the migration path and test scope change with the starting version.	One-time. Ask the partner to confirm the exact Activiti version and the Flowable LEAP report results for it.
Deployed process definitions and versions	More definitions and older versions still in use mean more models to review, retest and map to Flowable deployments.	One-time. Ask for a definition inventory and which versions must keep running.
Active process instances	In-flight instances must move in place with their variables and job state, which requires checks on each affected flow.	One-time. Ask how instances will be counted, sampled and verified after cutover.
History volume	Large history tables extend data copy and verification time, and retention rules decide what must be carried over.	One-time for the copy, recurring for storage. Ask what retention applies and where history will live.
Custom delegates, listeners and expressions	Java code written against Activiti APIs must be rewritten or re-tested against Flowable classes and changed event behavior.	One-time. Ask for a count of delegates and listeners and the test approach for each.
Identity and LDAP customizations	Custom identity services, group lookups and user directories must be re-implemented against Flowable identity interfaces.	One-time build, with recurring directory maintenance. Ask which identity source and sync method are in use.
Target Flowable major version	Flowable 7 moves to Java 17, Spring Boot 3 and Jakarta EE. Flowable 8 moves to Spring Framework 7 and Spring Boot 4, with no Spring Boot 3 compatibility.	One-time. Ask which major version is targeted and which Java and Spring baseline the quote assumes.
Database platform	The supported database and its version affect schema creation, data copy and any precision or driver changes during cutover.	One-time. Ask which database is used now, whether it changes, and who runs the copy.
Test coverage and parallel-run length	Thin tests push verification into manual work, and a longer parallel run adds operations time on both platforms.	Parallel run is one-time but recurring in operations. Ask for the test plan, the parallel-run length and the exit criteria.

Why the Java and Jakarta baseline changes the work

The first decision in this migration is the target major version, because the baseline jumps are larger than a typical library upgrade. According to the Flowable 7.0.0 release notes, version 7 moved to Java 17, Spring Boot 3 and Jakarta EE, and it removed the UI applications, the form and content engines, the Mule integration and async history. Flowable 8.0.0 then moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, made Jackson 3 the default JSON library with a Jackson 2 compatibility layer, and removed JUnit 3 and 4 support. Confirm the target version against the Flowable 8.0.0 release notes before you estimate any other work.

Start with an inventory of what your Activiti application depends on. Look for javax.* imports, javax.servlet or javax.persistence references, Java EE application server deployment descriptors, and any use of the Activiti UI or form components, since those were removed from the Flowable line. Check whether the application uses Mule, async history, or Spring Boot 3 starters, and whether custom tests use JUnit 3 or 4 runners or Jackson 2 annotations directly. Each of these maps to a specific change in one of the two major jumps, so a short list of matches tells you whether the work is a dependency update or a rewrite of parts of the application.

Ask your team and any partner to confirm three things in writing: the JDK and application server your runtime will use, the Spring Boot line your organization supports, and whether any Activiti component you rely on is still provided in the target Flowable major version. Where the answer is unclear, treat it as a risk to plan for rather than an assumption to accept. Confirm also the support status of your current Java runtime, because the baseline change may force a platform upgrade on servers and build pipelines that sit outside the Flowable project.

What usually goes wrong in an Activiti to Flowable migration

Most Activiti to Flowable problems come from assumptions made before the cutover: which instances are still running, which code depends on the old runtime, and what happens to timers during the switch. Each risk below maps to a phase in the migration sequence, so the check can be scheduled before it is needed.

Active instances on removed features

Instances that are still running may depend on components that did not carry forward, such as older UI or form elements, or history behavior that changed. Inventory every deployed process definition and the features its activities use during the assessment phase. Confirm with the Flowable LEAP report and the release notes which items need a decision before any instance is migrated. Plan how each affected instance will finish or be moved.

Delegates tied to Java EE APIs

Service tasks and listeners written against javax packages or Java EE container services will fail once the target line moves to Jakarta EE. Scan delegate classes, custom listeners and shared libraries for javax.* imports and container lookups. Set the Java and Spring baseline in a branch and compile delegates against it before the cutover rehearsal. Keep the scan output as a change record for the release.

Async history assumptions

Code or reports that expect history to be written synchronously, or that read history tables directly, may return incomplete data after the move. Review every query, dashboard and audit extract that reads history tables. Confirm how the target configuration writes history and retains it, and agree the reporting cutover with the owners of those reports. Test a completed instance end to end before go-live.

Timers and jobs during cutover

Timers and asynchronous jobs that fire while old and new engines both have access to the database can run twice or be lost. Decide the cutover window and drain or pause the source engine before migration starts. In the target, the async executor uses lock owners and lock expiration times in the database, so confirm that every node points at the same schema and that locks recover as expected. Verify the job count before and after the switch.

Identity mapping gaps

Users, groups and candidate assignments in Activiti may not match the identity source the new deployment uses. Tasks assigned to users who no longer exist or group names that changed will stall silently. Map every candidate group and assignee in running tasks to the target identity service, and decide whether to override the identity service or implement the interface. Run a report of unassigned or orphaned tasks after the migration.

Untested expression behavior and rollback

Expressions, script tasks and conditional flows can evaluate differently under the newer engine, and the change may only appear with real variable data. Build a test set from production-like instances covering each gateway branch, then run it against the target. Define the rollback path before cutover: keep the source database backup, the previous deployment artifacts and a tested procedure to return traffic to the old engine. Without a rehearsed rollback, a failed cutover becomes a data recovery project.

What your team does and what a partner can take on

This split suits an organization whose developers already know the Java delegates, listeners and identity code that the process applications depend on. Your team keeps ownership of the code that changes behavior, and a partner handles the planning and verification work that benefits from outside method and tooling. The partner typically runs the Flowable LEAP report against your current Activiti installation, produces a migration plan from its findings, and designs the parallel run that compares old and new engines on the same work. Your team then fixes delegates and identity integration against that plan.

Source code and build access: Provide the repositories for process applications, delegates, event listeners, custom expressions and any identity service code, plus the build pipeline that produces them.
Database access: Provide read access to the Activiti schema and a copy of the production data, or a masked extract, so the LEAP analysis reflects real instance and history volumes.
Test data and sign-off owners: Name the business owners who approve each process path and who accept the parallel run results. Without named owners, parallel run differences stall.
What you receive: A LEAP-based assessment, a migration plan, migrated process definitions, test reports from the parallel run, and a runbook for cutover and rollback.
Your internal effort: Your developers own the code changes to delegates and identity integration, so budget their time for the Flowable API differences and the Java and Jakarta baseline changes described in the upgrade topics.

Confirm with the partner which parts of the delegate and identity work they will review, and whether they will pair with your developers during the parallel run.

Questions teams ask before moving from Activiti to Flowable

How long does a migration from Activiti to Flowable take?

No single duration applies to every Activiti estate, and the length is set by a few factors you can measure. The main ones are the number of process definitions and case or decision models, how many instances are running at cutover, how much custom Java code sits in delegates, listeners and scripts, and how far your application depends on the Spring or Java baseline that changes between versions. Teams with few models, no in-flight work and little custom code move faster than teams with long-running processes and heavy integrations. Ask any partner, including DeployOpen, to break its estimate into inventory, code changes, data migration, testing and cutover, each tied to the factors above.

What does an Activiti to Flowable migration cost, and what should a quote include?

Cost comes from the people doing the work: assessment of your models and code, changes to delegates and build tooling, data migration and test runs, cutover planning, and documentation. Most of this is one-time. Recurring costs appear only if you add ongoing support, upgrades or testing, and Flowable's commercial products and professional services are separate purchases from the open-source engines. DeployOpen works from a written scope before any work starts and does not publish a price list. A quote should list the process and case models in scope, the custom code to change, the environments to migrate, the test cases, the cutover window support and any exclusions, so you can compare it with an internal estimate line by line.

Can our own team migrate from Activiti to Flowable without outside help?

A team that already owns its Activiti applications can migrate them, provided it has Java and Spring skills, access to the production database, and time to test. Flowable's engines are licensed under Apache 2.0 and documented, and the community forum is available to open-source users. The harder parts are usually the ones that depend on your history: undocumented delegates, custom expressions, identity code and scripts that only run in production. Decide early which of these your staff can explain and test. If the answer is few people and a fixed deadline, a fixed-scope partner engagement can cover the risky parts while your staff keep ownership of the business models.

Do active Activiti process instances move to Flowable without a restart?

Flowable's engineering team has said that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and their history. That is the basis for planning a migration without rebuilding running work from scratch. Confirm the details for your exact source and target versions, because the in-place path depends on them. Test it on a copy of production first, and check timers, asynchronous jobs, variables that hold custom objects and any delegate that changes its behavior. Plan the cutover window around jobs that are mid-execution, and keep a tested rollback path.

Can we move directly from Activiti 5 to Flowable 8?

The supplied Flowable material does not confirm a direct path from Activiti 5 to Flowable 8, so treat it as an open question to settle with Flowable before you commit. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, and it removed the UI applications, the form and content engines, the Mule integration and async history. Flowable 8.0.0 then moved to Spring Framework 7 and Spring Boot 4, dropped support for Spring Boot 3, made Jackson 3 the default JSON library and removed JUnit 3 and 4 support. An Activiti 5 application may need several of these changes at once, so your plan may pass through an intermediate version. Check the 8.0.0 release notes against your code before choosing a target.

What does the free Flowable LEAP report tell us before we commit?

Flowable offers the free LEAP tool to report ahead of time what a migration from Camunda 7 or Activiti involves. Use it as the first step in your inventory, not as the whole assessment. Ask whether the report covers your exact Activiti version and which artifacts it reads, such as process definitions, history tables and configuration. Then list what it cannot see on its own: custom Java delegates, listeners, expressions, scripts, identity services, REST clients and external systems that call the engine. Those items usually decide the schedule. Combine the report with your own list before you set a budget or a cutover date.

What does the migration need from our staff?

The work needs four groups of people. Process owners must confirm that each model still reflects how the business runs and approve the test cases that prove it. Developers need Java and Spring knowledge to change delegates, listeners and build files. Platform or database engineers must provide a backup, a test copy of production, a cutover window and rollback steps. Security staff should review identity integration, scripting and access to the engine APIs. Plan for these people to take part in assessment, test runs and cutover, not only at the start. Naming them before the quote is signed makes the scope and schedule easier to check.

How DeployOpen scopes and delivers an Activiti to Flowable migration

DeployOpen plans, builds, tests and hands over Activiti to Flowable migrations inside your own infrastructure, under a written scope agreed before work starts. We start from what your Activiti processes actually run today, then confirm with Flowable's published material which parts can move in place and which need engineering work.

How we scope

Inventory of Activiti version, process definitions, delegates, listeners and active instances in each environment
Written list of which running instances and history stay in place and which need a planned treatment
Confirmation of target Flowable version, Java and Spring baseline, and supported database type
Agreed test scope covering delegates, models, identity integration and REST consumers before work starts

How we build

Port custom delegates and expressions to the target engine API and update Spring or servlet wiring
Run the migration first against a copy of production data in a staging environment you control
Test process and history behavior with unit and integration tests, then rehearse the cutover runbook
Keep configuration, deployment scripts and model changes in version control with reviewed changes

How we hand over

Written runbook with cutover steps, rollback points and checks run before and after each step
Documented changes to models, delegates, configuration keys and database schema for your team
Test evidence and a record of instances and history verified after migration
Handover session with your engineers so they can run and change the Flowable deployment

How we support

Fixed-scope engagements with deliverables and timelines agreed in writing before work starts
Post-migration support, Flowable upgrades and continuous testing available as a retainer
Ask for a quote built from the written scope, including which items are one-time and which recur
Confirm version compatibility with your own platform owners and the vendor before scheduling cutover

Migrate from Activiti to Flowable