Flowable or Activiti: when each one fits
If you are choosing a Java BPMN engine for a new workload, or deciding whether an existing Activiti deployment should move, the decision turns on four things: how much of the standards stack you need, which Spring Boot line your platform is on, how often you need releases, and whether you will pay a vendor for support. Flowable fits best when your process design goes beyond BPMN. Its engines cover BPMN, CMMN and DMN in one open-source family, and the Flowable Spring Boot docs describe starters for the process, CMMN and DMN engines individually. Flowable 8.0.0, released on February 27, 2026, is built on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so teams already standardized on Spring Boot 4 have a direct match. Flowable also documents an in-place migration path from Activiti, which matters if you want to move without rebuilding your process data.
Activiti fits when the codebase already exists and works. If your processes, custom listeners and operational runbooks are built on Activiti, a move to Flowable is a project with its own test and regression cost, and staying put can be the lower-risk choice for a stable system. Activiti is also the better reference point if you plan to run Activiti Cloud, which the project describes as cloud-native building blocks with a quickstart for Kubernetes. The Activiti code base targets Java 21, so confirm that your runtime and build chain meet that baseline before you commit. The Activiti 8.8.1 release, published on July 14, 2026, should be checked against your own dependency and security review cadence. Confirm with the project which Spring Boot line your target version supports, since that determines your upgrade path.
Before you decide, write down four answers. First, do you need CMMN case management or DMN decision tables alongside BPMN, or is BPMN the only standard in scope? Second, which Spring Boot major version will your platform run over the next several years? Third, how often does your organization require upgrades, and does your security team expect a specific release cadence from the project? Fourth, will you buy commercial support, and if so, from whom? The Flowable open-source page notes that professional services and partners are offered separately from the community forum, and Activiti's sponsorship model is different. Ask each vendor for written statements on support scope and migration responsibility before you finalize the choice.
Which scenarios favor Flowable and which favor Activiti
This table maps common team situations to the engine that fits better and names the condition under which the other option wins. Read each row against your own estate, Spring Boot version and deployment model, since the two engines overlap on BPMN but differ on CMMN, DMN and current release activity. Use it as a starting shortlist, then confirm the specifics in a proof of concept.
| Scenario | Better fit and reason | When the other option wins |
|---|---|---|
| New BPMN plus case management build | Flowable. Its engines cover BPMN, CMMN and DMN under Apache-2.0, so case and decision logic can sit in one engine family. | Activiti wins if the project needs only BPMN 2 process execution and no CMMN case modeling. |
| Existing Activiti 6.x or 7.x estate | Flowable, if you plan a move. Flowable documents an in-place migration path from Activiti, including active instances and history. | Staying on Activiti wins if the current version meets needs and a migration window is not yet scheduled, and you confirm Activiti's support status with its maintainers. |
| Spring Boot 4 teams | Flowable 8.0.0, which supports Spring Boot 4 and Spring Framework 7. Confirm the Spring Boot starter for your exact versions. | Activiti wins if your application is pinned to an Activiti release that already runs on your Spring stack and an upgrade is not planned. |
| Spring Boot 3 teams | Flowable 7.x line, since Flowable 8.0.0 dropped Spring Boot 3 support. Pin the release that matches your Spring Boot 3 baseline. | Activiti wins if your Spring Boot 3 application already runs Activiti and you want to avoid changing the engine during a stack upgrade. |
| Kubernetes-first cloud deployment | Activiti, if you want Activiti Cloud building blocks and its published Kubernetes quickstart. Check fit with your own platform team. | Flowable wins if you run the engine embedded in your services or as the Flowable REST application, since containerizing your own Spring service needs no separate cloud framework. |
| Teams needing a vendor commercial platform | Flowable, which sells a commercial platform on the same engines with low-code modeling, monitoring and governance. | Activiti wins if you only need the open engine and no vendor platform, and you accept community or Alfresco-linked support paths you confirm directly. |
| Teams that need a current release line and frequent releases | Confirm release cadence on both release pages before deciding. Flowable's 8.0.0 release is dated February 27, 2026, and Activiti 8.8.1 is dated July 14, 2026. | Choose whichever project's release cadence and support policy matches your patching rules, since both are Apache-2.0 and the license does not decide this row. |
How each engine is embedded and deployed
Flowable and Activiti are both Java BPMN engines, but they reach production differently. The choice of embedding model shapes how you cluster, scale and operate the engine, so read these cards as deployment decisions rather than feature lists.
Embedded JAR in Java SE or servlets
Flowable can be embedded as a JAR in a plain Java SE application or in a servlet container such as Tomcat or Jetty, so the engine runs inside your own process. Activiti also runs in any Java application, on a server, on a cluster or in the cloud. Check which Java runtime and container versions your platform team supports, since Activiti's code base targets Java 21 as its language level. Confirm the exact runtime floor for the Flowable release you choose before you commit to a base image.
Embedded in Spring applications
Both engines integrate with Spring, which is often the deciding factor for teams already standardized on it. Flowable publishes starters for all engines, for REST and for the individual process, CMMN and DMN engines, and supports Spring Boot 4.x in Flowable 8.0.0. Flowable 8.0.0 dropped Spring Boot 3 support, so existing Spring Boot 3 services need a planned upgrade before adopting it. Confirm the Spring Boot line that Activiti 8.8.1 targets in its release notes.
Java EE server deployment
Flowable's documentation lists Java EE servers as one of the supported ways to embed the engines, alongside Java SE, servlet containers and Spring. This matters for organizations that still run application servers and cannot move to Spring Boot in the near term. Confirm with each vendor whether your application server version and the Jakarta EE generation of your current code are supported by the engine release you plan to use, because Flowable 7.0.0 moved to Jakarta EE.
REST application as a separate service
Flowable offers a REST application that exposes the engines over HTTP, so other systems can call the process engine without linking it into their own code. This separates process lifecycle from business applications but adds a service to secure, scale and monitor. Check the REST security configuration and the network path between callers and the engine before you adopt this model. Activiti's REST option should be verified in its own documentation rather than assumed.
Clustering through the async executor
Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates several nodes through lock owners and lock expiration times stored in the database. When a node fails, expired locks are recovered and other nodes pick up the jobs. Operationally, this means a shared, highly available database is part of the cluster design, and you should test lock expiry and failover before go-live. Confirm how Activiti handles job execution across nodes in its own documentation.
Activiti Cloud on Kubernetes
Activiti Cloud is a set of cloud-native building blocks designed for distributed infrastructure, with a quickstart for Kubernetes. This is a different operating model from embedding a library: you take on container images, cluster configuration and the services around the engine. Ask which Activiti Cloud components your team would need, which are maintained for your target release, and who owns upgrades across those services. Teams without Kubernetes operations experience should weigh this effort explicitly.
Standards, Spring Boot, database and identity support compared
This table sets the documented capabilities of Flowable's open-source engines beside what the supplied Activiti sources state, row by row. Where a cell says to confirm, the supplied material does not settle the point for Activiti, so check it against the Activiti release you plan to run before you decide.
| Capability | Flowable | Activiti |
|---|---|---|
| BPMN, CMMN and DMN coverage | BPMN, CMMN and DMN engines, all Apache-2.0, with CMMN and DMN included alongside BPMN | BPMN 2 process engine is the documented core; confirm CMMN and DMN support in the release you intend to use |
| Java and REST APIs | Java APIs plus a REST application over HTTP | Java engine embeddable in any Java application; confirm the REST surface and its version in the Activiti docs |
| Spring Boot starters and version support | Starters for all engines, REST and individual engines; Spring Boot 4.x supported in Flowable 8.0.0, which dropped Spring Boot 3 | Documented as integrating with Spring; confirm available starters and the Spring Boot line supported in your target release |
| Java language level | Flowable 8.0.0 is built on Spring Framework 7 and Spring Boot 4; confirm the Java baseline in the release notes before upgrading | Code base targets Java 21 as its language level |
| Supported databases where documented | H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server; MySQL below 5.6.4 lacks millisecond precision | Not stated in the supplied material; confirm the supported database list in the Activiti documentation |
| Actuator monitoring | Spring Boot actuator endpoint at /actuator/flowable for monitoring running processes | Not stated in the supplied material; confirm any actuator or monitoring endpoints with the Activiti project |
| Identity replacement points | Identity management can be replaced by overriding IdmIdentityServiceImpl or implementing IdmIdentityService; an LDAP reference implementation is provided | Not stated in the supplied material; confirm how identity is delegated in the Activiti release you run |
| Cloud quickstart | Embeds in servlet containers, Spring and Java EE servers; cloud deployment is your own packaging choice to confirm with your platform team | Activiti Cloud building blocks for distributed infrastructure, with a Kubernetes quickstart |
What is free and what is paid around each engine
Flowable's open-source engines for BPMN, CMMN and DMN are Apache-2.0 licensed and can be embedded in a Java application or run as a service with Java and REST APIs. Flowable also sells a separate commercial platform, built on the same engines, that adds capabilities the open-source distribution does not include. The commercial line is named Flowable Work, Engage, Orchestrate and Design.
- Free engines: The BPMN, CMMN and DMN engines carry no license fee under Apache 2.0, so the cost of running them is infrastructure, your own engineering and any services you buy.
- Commercial platform: Flowable Work, Engage, Orchestrate and Design add low-code modeling, visual debugging, security controls, monitoring and governance on top of the same engines.
- Community support: Open-source users get access to a community forum, which is the default support channel for the engines.
- Professional services: Flowable offers professional services and partners separately, so implementation help, custom work and production support are priced by scope.
- Shared engine base: Because the commercial products run on the same engines, moving from the free engines to the platform is a product decision rather than a re-implementation of process logic.
Confirm with Flowable which products, support levels and terms apply to your deployment before you assume any feature is covered. Ask for the license terms of each commercial product in writing.
Activiti is a BPMN 2 process engine for Java, distributed under the Apache license. The project's website is published by Alfresco Software, and the README describes the core as a lightweight workflow and BPM platform that runs in any Java application and integrates with Spring. The code is open source, so the engine itself carries no license fee.
- Apache license: The engine code is distributed under the Apache license, so you can use and modify it without a per-seat or per-core fee for the engine.
- Publisher: The Activiti website is published by Alfresco Software, which is the entity to ask about project ownership and roadmap.
- Activi Cloud building blocks: Activiti Cloud is a set of cloud-native building blocks with a Kubernetes quickstart, which is open-source material you assemble and operate yourself.
- Commercial support: The open-source materials do not describe a commercial support tier, so you should confirm directly with the vendor which support, subscription or consulting options exist and what they cover.
- Version lines: The master branch holds the current major version, while contributions to version 6.x go to a separate branch, so confirm which line your support terms cover.
Ask the vendor for written answers on support levels, supported versions and the contract terms for any commercial service before you rely on it in production.
Whichever engine you choose, most of the recurring cost sits in people and support rather than license fees. The two projects differ in how commercial help is packaged, so the same question, who answers a production incident, has different answers for each. Ask who is paid for what before comparing totals.
- Community channels: Forums and public repositories answer many questions, but they carry no response commitment, so check whether your incident process can depend on them.
- Vendor services: Flowable's professional services are scoped separately from the engine license, and you should request a written scope covering upgrades, support hours and escalation.
- Implementation partners: Third-party integrators can build and operate either engine, and their rates and terms are set by contract, not by the project.
- Internal skills: Upgrade effort, database administration and Spring or Java expertise are recurring costs that stay in-house whatever you license.
- Quote inputs: Ask for the scope, supported versions, upgrade responsibility and response targets in any quote, so the comparison uses equal terms.
Compare the written support terms from each vendor side by side, including what happens when a version reaches end of support.
What release cadence says about long-term maintenance
Release dates are the first signal of whether an engine will still be maintained when your process models have grown. The supplied dates show Flowable on a regular line: 7.1.0 on October 7, 2024, 7.2.0 on August 21, 2025 and 8.0.0 on February 27, 2026. Activiti 8.8.1 was published on July 14, 2026. Dates alone do not settle the question, though. Activiti's README says the master branch holds the current major version and that contributions to version 6.x go to a separate branch, so a team running 6.x is on a different maintenance path from one on master. Confirm which branch your version sits on, and which branch receives security fixes, on the Activiti releases page before you choose a line.
The upgrade cost on the Flowable side depends mostly on the framework stack, not on the BPMN models. Flowable 8.0.0 moves to Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 without backward compatibility, so any application on Spring Boot 3 must change its framework version in the same step. The release notes also make Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and remove JUnit 3 and 4 support. Custom serializers, JSON process variables, REST payload mapping and older test suites are the places where your own code will break. Teams still on the 7.x line also remember that Flowable 7.0.0 itself moved to Java 17, Spring Boot 3 and Jakarta EE, so a move to 8.0.0 may cover two stack changes.
Before you commit, turn these facts into checks. Ask each vendor for a written support policy that names the supported major lines, the end-of-support date for your current line and whether security patches are published for older branches. Confirm the Java baseline and the Spring Boot version that Activiti 8.8.1 expects, because the supplied facts state the Java 21 language level but not the Spring Boot line. Then run your own test suite against a Spring Boot 4 build of your application and record every failing serializer, test and REST contract. That list, not the release date, is the best estimate of what the upgrade will cost your team.
What drives running cost for each engine
Neither engine charges a license fee, so the running cost comes from people, databases, upgrades and any support contracts you add. The cards below show who gets paid for each of these items and what to request in a written quote from Flowable, Alfresco or a partner.
Engine license cost
Both Flowable and Activiti are Apache-licensed Java engines, so the engine itself carries no license fee for either option. Budget instead for the hours your team spends on the engine, the infrastructure it runs on and any paid support you buy. Confirm the license file shipped with the exact version you deploy, and check the terms of any add-on, connector or plugin you adopt, since those can differ from the core engine.
Database and hosting
Flowable documents support for H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the database choice often sets the largest recurring bill. Oracle, DB2 and SQL Server carry licensing paid to those vendors, while PostgreSQL and MySQL do not add a license line. Ask any quote to price the database, its backups and its high availability setup separately from the application hosting. Confirm which databases Activiti 8.8.1 supports in your environment.
Java and Spring upgrade effort
This is the cost that recurs. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and Flowable 7.0.0 had already moved to Java 17. Activiti's code base targets Java 21. Each major framework move means regression testing of your process models, custom listeners and integrations. Ask vendors and partners to quote upgrade work per framework major, not as a one-time project.
In-house skills
Running either engine well requires BPMN modeling skill, Java and Spring experience, and database tuning for the async executor, which uses lock owners and lock expiration times stored in the database to coordinate nodes. Those skills are paid through salaries, contractors or retainers. If your team lacks them, price training and a period of paired work into the first year. Ask a provider to name the roles and hours it assumes for run, upgrade and incident response.
Commercial support options
Flowable states that open-source users get a community forum, while professional services and partners are offered separately. Its commercial platform, including Flowable Work, Engage, Orchestrate and Design, is built on the same engines and adds low-code modeling, visual debugging and governance. Activiti's website is published by Alfresco Software, so confirm which support tiers Alfresco or a partner sells for Activiti and what response commitments each one includes in writing.
Custom identity integration
Flowable documents that identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, with an LDAP implementation provided as a reference. Any custom identity service is code your team owns and must retest on every engine and Spring upgrade. Ask Activiti's maintainers or a partner to confirm the equivalent extension points for the version you run, and quote the identity work as a separate line item.
Moving an Activiti workload to Flowable
This sequence takes an Activiti workload from inventory to production on Flowable, with process data and history carried over by Flowable's documented in-place path. Each step closes with a check your team can record, and none of them replaces the verification your own environment needs.
Inventory instances, history and custom code
Your team lists every deployed process definition, every active process instance, the history you must retain, and all Activiti-specific code, including custom listeners, identity services, delegate beans and direct calls to Activiti APIs. Record the exact Activiti version you run, because the current Activiti line is 8.8.1 and you should confirm with Flowable which migration path applies to your starting version. The step is done when engineering and the process owners both accept the inventory, with each item marked as transfers or needs rebuilding.
Run the Flowable LEAP assessment
Run Flowable's free LEAP tool against a copy of your Activiti database, not production, as described in Flowable's engineering blog. The platform or engineering lead owns this step and uses the inventory from the previous step to interpret the findings. The output is an assessment that separates what migrates cleanly from what needs manual work. The step is done when every finding is either resolved or written into the rebuild list with an owner.
Confirm database and Spring Boot targets
Confirm the target database and framework versions before any data moves. Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and they note that MySQL versions below 5.6.4 lack millisecond precision. Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3, so a team on Spring Boot 3 must plan that upgrade as part of the move. The architect owns this step, and it is done when a written target matrix is signed by the DBA and the application owner.
Run the in-place migration in staging
Run the in-place migration on a restored copy of production, following Flowable's documented path for Activiti data. Flowable states that Activiti data, including active process instances and history, can be migrated in place, so this step moves the live process state. Record counts for process instances, tasks, variables and history before and after the run, and confirm that they match. The step is done when the reconciliation shows no unexplained gaps. Use Flowable's documentation and any support you contract for the exact procedure, since the commands and settings depend on your environment.
Rebuild custom listeners and identity services
Rebuild the items that do not transfer, as identified in the inventory. Expect custom listeners, identity service implementations and any code that calls Activiti-specific APIs to need rewriting against Flowable's interfaces. Flowable's docs say identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. The development team owns this work. It is done when integration tests pass on Flowable and each rebuilt component matches the behavior recorded in the inventory.
Test process definitions and REST clients
Test every deployed process definition end to end, including timers, asynchronous jobs and error paths. Flowable's advanced docs describe how the async executor uses lock owners and lock expiration times in the database, so test failover by stopping one node during a running job and confirming another node picks it up. Flowable 8.0.0 uses Jackson 3 as its default JSON library with a Jackson 2 compatibility layer, so check how variables serialize. Then run every REST client against the Flowable endpoints and confirm that request and response shapes match what each caller expects. The step is done when results are recorded for each definition and client and operations signs off the failover test.
Cut over and keep a rollback path
Agree the cutover window with the business owners, freeze new deployments to the Activiti system, run the final data migration against production, and switch application traffic to Flowable. Keep the original Activiti database intact and read-only until the team has observed the new system through an observation period agreed in advance. Monitor that timers and jobs are running and that reconciliation counts still match on production. The step is done when the rollback decision owner has signed the go-live record.
Where Flowable and Activiti projects usually run long
Projects on either engine tend to run long for the same reasons: process modeling takes longer than planned, identity integration is underestimated, and the database and identity source have no clear owner. Start by asking the vendor or partner for a written scope that names who owns each of these, along with the deliverables for each. Flowable exposes identity through the IdmIdentityService interface, and its docs describe overriding IdmIdentityServiceImpl or providing a custom implementation, with an LDAP identity service offered as a reference. Decide early whether your directory will be read through that reference, a custom service or an existing bridge, because user and group mapping drives task assignment and candidate queries in every process. Confirm the same point for Activiti with your own team, since the sources supplied here do not describe its identity hooks in the same detail.
The async executor and clustering settings are the next source of delay. In Flowable, the async executor runs timers and asynchronous jobs from a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. Someone must own thread pool sizing, lock timing and the database configuration for each node, and that work is easy to skip during a proof of concept and expensive to repair in production. Upgrades add another layer. Flowable 8.0.0 is based on Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 support, so any application still on Spring Boot 3 needs its own upgrade plan before the engine moves. Confirm which Spring Boot line your platform team supports before the schedule is set. Testing migrated instances deserves its own line in the scope. Active process instances, history and open tasks must be checked against the original system, including timers and jobs that were pending during cutover. Ask the partner to define the test cases, the sample of production instances to replay, the owner who signs off, and the rollback procedure. Written scope with named owners for the database, the identity source and the test sign-off is the most reliable predictor of whether these projects finish on the original plan.
Questions buyers ask before choosing or migrating
Do the Flowable and Activiti engines cost anything to license?
Neither open-source engine carries a license fee, because both are Apache-2.0 licensed. Flowable sells a separate commercial platform, including Flowable Work, Engage, Orchestrate and Design, built on the same engines. Those products add low-code modeling, visual debugging, security controls, monitoring and governance, and Flowable offers professional services and partners separately. The costs that remain are infrastructure, the database, the engineering time to build and operate the solution, and any paid support or services you choose to contract. Before budgeting, confirm with Activiti's publisher, Alfresco Software, which support options are available for the Activiti line you plan to run, since the open-source license alone does not cover them.
What drives implementation effort for a Flowable or Activiti project?
Effort follows the architecture decisions more than the engine itself. The main drivers are:
- Embedding the engine in your Java or Spring application versus running the Flowable REST application as a separate service, which changes deployment and security work.
- The database: Flowable documents H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and your choice affects testing and operations.
- Identity integration: Flowable lets you replace identity management by overriding IdmIdentityServiceImpl or implementing IdmIdentityService, with an LDAP reference implementation, so directory work scales with your user model.
- Clustering and timers: the async executor coordinates nodes through lock owners and expiration times in the database.
- The volume and custom Java code of existing process models, delegates and listeners.
How long does an Activiti to Flowable migration take?
No duration for a migration is supplied in the research, so the honest answer is that it depends on your estate. The factors that move the timeline are the number of active process instances, the size of the history you must keep, the amount of custom Java code bound to the engine, how well the current processes are tested, and the Spring Boot and Java versions you must reach. Flowable offers the free LEAP tool to assess a migration, which is a sensible first step to size the work. Ask any provider for a timeline in writing that names the assumptions behind it. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope.
Can an in-house team run Flowable without outside help?
A team with solid Java and Spring skills can run the engines itself, because they are documented, embeddable and available under Apache-2.0. Running them in production still means owning the database, the clustered deployment, backups, monitoring and every upgrade. The Flowable Spring Boot documentation describes starters for each engine and an actuator endpoint at /actuator/flowable for monitoring running processes, which helps operations. Open-source users receive a community forum, so support for urgent incidents has to come from your own staff, a commercial Flowable agreement or an outside partner. Decide early which of these gaps you will fill. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your infrastructure, typically under a fixed scope or a retainer.
Does Flowable's in-place migration cover Activiti history?
Flowable states that Activiti data can be migrated to Flowable in place, including active process instances and history. That is Flowable's documented claim, published in its September 7, 2022 engineering blog, so treat it as a starting point rather than a guarantee for your system. Confirm it against your own Activiti version, any custom tables or extensions, and the history you need to keep for audit. Use the free LEAP assessment tool to check what your data needs before committing to a plan. Run the migration against a copy of production, compare process instance counts and history records afterward, and document the results as evidence for your change record.
Which platform should a Spring Boot 3 estate choose?
If you must stay on Spring Boot 3, Flowable 7.x is the line to plan around. The Flowable 7.0.0 release moved the engines to Java 17, Spring Boot 3 and Jakarta EE. Flowable 8.0.0, released on February 27, 2026, is based on Spring Framework 7 and Spring Boot 4, and its release notes state there is no backward compatibility for Spring Boot 3. Activiti's supplied facts confirm Java 21 as its language level and Spring integration, but they do not state which Spring Boot line each Activiti release supports. Check the Activiti 8.8.1 release, published July 14, 2026, and its dependency tree before deciding. Upgrading to Spring Boot 4 is a planned change with its own testing.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Work is usually fixed-scope under a written agreement, with retainers for ongoing support. DeployOpen is not a vendor partner of either Flowable or Activiti and gives the same assessment for both.
Engine selection and fit review
Before choosing between Flowable and Activiti, map your process models, decision tables and case management needs against what each engine covers. Confirm which BPMN, CMMN and DMN features your processes actually use, and which Java framework and Spring Boot version your platform team runs. The result is a written comparison tied to your own process inventory rather than a general feature list.
Embedded or service deployment design
Decide whether the engine runs embedded in your Java or Spring application or as a separate REST service that other systems call. This choice drives your deployment units, scaling model, and who owns upgrades. DeployOpen can document the topology, database connections and the async executor configuration so operations teams know how jobs are locked and recovered across nodes.
Activiti migration assessment
If you already run Activiti, confirm its version and database schema, then plan the move to Flowable with a written test scope. Check custom listeners, delegates and REST integrations that depend on Activiti class names. Flowable documents in-place migration of Activiti data, but the process models, custom code and history retention rules still need testing in your environment before cutover.
Identity and database integration
Wire the engine to your directory and database platform. Flowable documents replacing its identity management service with a custom implementation and provides an LDAP reference. Confirm which of your supported database types, such as PostgreSQL, Oracle or Microsoft SQL Server, your standards require, and test the identity service against your real user groups and role mappings.
Hardening, backup and upgrade runbooks
Harden the engine, REST endpoints and the actuator monitoring endpoint, then document backup and restore for the process database. Upgrade planning matters here: Flowable 8.0.0 moved to Spring Boot 4 and dropped Spring Boot 3 support, so any upgrade path needs its own test cycle. DeployOpen can produce these runbooks as part of a fixed-scope delivery.
Retained support and upgrades
After go-live, ongoing support, upgrades and continuous testing can run under a retainer. Ask any provider for the written scope of response, upgrade testing and who owns the process models and custom code. Clarify which costs are one-time implementation work and which recur through the retainer, so the total cost of running either engine is visible before you commit.
