Should you stay on Flowable 6 or plan a move to Flowable 7 or 8?
If your Flowable 6 application runs on Java 8 and the decision is still open, the first fact to hold onto is that Flowable 6 is still maintained and supports Java 8 and later, so staying is a valid option and not an emergency. The newer majors change the runtime baseline, though. Flowable 7 requires Java 17 or higher, and Flowable 8 moves the stack to Spring Framework 7 and Spring Boot 4. The supported path runs 6 to 7 to 8, and each step carries its own changes to Java, Jakarta and the removed components. Confirm the current maintenance terms for version 6 directly with the project, since support windows are a matter of project policy and not something this page can promise.
The decision depends on the application's dependencies, not only on the engine. Start by listing what the application pulls in around Flowable: the Spring or Spring Boot version, servlet container, JSON library, test framework, custom delegates, identity service and any code that still depends on the Flowable 6 UI applications or form and content engines that version 7 removed. Each of these may pin you to Java 8 or to a javax namespace, and an engine upgrade cannot proceed until those pins are cleared. Review the Flowable engine repository release notes for each target version, and check Flowable's versioning documentation, which says deprecated APIs are removed two minor versions after deprecation. A version 6 application that is quietly relying on deprecated calls will have a shorter runway than the release date suggests.
What changes between Flowable 6, 7 and 8
This table compares the platform baseline and removed components across Flowable 6, 7 and 8, with the action each change requires. Read each row as a question about your current application: if it touches something you use, that row sets the work. The main takeaway is that moving from 6 to 8 is not one step, because the Java, Jakarta and Spring changes arrive at different releases.
| Area | Flowable 6 | Flowable 7 | Flowable 8 |
|---|---|---|---|
| Java runtime | Java 8 or higher, still maintained per the project README | Java 17 or higher | Confirm the minimum Java version in the 8.0.0 release notes before planning |
| Spring and Boot baseline | Spring Boot 2 era applications are typical; confirm your version | Spring Boot 3 | Spring Framework 7 and Spring Boot 4, with no Spring Boot 3 compatibility |
| Jakarta namespace | javax packages | Jakarta EE, moving from javax to jakarta packages | Stays on Jakarta EE; check any custom code still importing javax |
| JSON library | Confirm the Jackson version your application uses | Confirm against the 7.0.0 release notes | Jackson 3 by default, with a Jackson 2 compatibility layer as a first step |
| Removed components | UI applications, form and content engines, Mule integration and async history are present | Removed: UI applications, form and content engines, Mule integration and async history | No further removals listed in the supplied facts; confirm against the 8.0.0 release notes |
| Test framework | JUnit 3 and 4 tests run as usual | Confirm test support in the 7.0.0 release notes | JUnit 3 and 4 support removed; port test suites to JUnit 5 before upgrading |
| Deprecated APIs | Deprecations are announced in minor releases | Check deprecation warnings in your build output and migration notes | Deprecated APIs are removed two minor versions after deprecation, so clear warnings early |
| Support status | Still maintained according to the project README | Supported by the project as the current line before 8.0.0 was released | Released February 27, 2026, per the GitHub releases page |
What staying on Flowable 6 means for support and security
The Flowable project states in the flowable-engine README that Flowable V6 is still maintained and supports Java 8 and higher, so staying on version 6 is a supported position today, not an end-of-life one. What the project does not give you is a dated support window or a guaranteed backport schedule for your particular 6.x release. Before deciding, confirm which 6.x release line you run, check the flowable-engine GitHub repository for the latest 6.x tags and security fixes, and ask Flowable or your vendor how fixes are delivered to the release you are on. Ask who will backport a security fix to your release and how quickly that happens, because an internal team that depends on upstream releases has a different exposure than one with a commercial support contract.
The larger risk often sits under Flowable. Java 8 and the framework versions around an older application, such as Spring Framework releases and the servlet container, receive their own security fixes on their own schedules, and those fixes can stop reaching your runtime even while Flowable 6 itself is maintained. Inventory the JDK build, the application server, the Spring or Spring Boot baseline, JSON and XML parsers, and any scripting components the process models use. Each one needs an owner, a patch source and a date by which a newer baseline is required. Use your vulnerability scanning and software composition results to show which components are out of support, since an auditor or security reviewer will ask about the whole stack rather than the engine alone.
Support options also differ by path. Community users work from the open source distribution, public documentation and the community forum described on the Flowable open source page, while the commercial products built on the same engines carry their own support terms. Professional services, including upgrade help, are offered separately from the product, so they are a quoted scope rather than an included benefit. Ask each party in writing what covers a 6.x security issue, what covers a Java 8 platform issue, and what an upgrade engagement would include, so that the cost of staying and the cost of moving are compared on the same terms.
Which decision path fits your application
Staying on Flowable 6 is a reasonable choice when your application runs on Java 8 or later, your release calendar cannot absorb a major upgrade yet, and you can document how and when you will leave. The Flowable project states that version 6 is still maintained and supports Java 8 and above, so the decision is about your risk tolerance and dependency health, not about a missing runtime. Treat this path as a time-boxed position with a written exit plan, not an open-ended default.
- Runtime baseline: Confirm the application runs on Java 8 or higher and that your application server, drivers and libraries also support that level.
- Maintenance scope: Ask the project which fixes and security updates apply to the 6.x line and how they are published, and record the answer.
- Removed components: Check whether you use the Modeler, Task or Admin UI apps or the async history feature, since those belong to the version 6 surface you keep.
- Exit trigger: Define the events that start the move, such as a new Spring Boot baseline, a library you need dropping Java 8, or a security finding you cannot patch.
- Staged path: Note the order in which you would test Flowable 7 or 8 later so the eventual move starts from a known position.
Before choosing this path, confirm with your engineering leadership and security team that the 6.x maintenance statement still holds for your deployment and that the exit trigger has an owner.
Moving to Flowable 7 is the step that changes the runtime and the namespace. Flowable 7 runs on Java 17 or higher, is built on Spring Boot 3 and Jakarta EE, and keeps the BPMN, CMMN, DMN and event registry engines with their REST APIs. It removes the UI applications, the form and content engines, the Mule integration and async history, so any application that depends on those pieces needs a replacement before the engine can start cleanly.
- Java runtime: Move the application and its build to Java 17, and confirm your container images, JVM settings and agents support it.
- Namespace change: Plan the move from javax to Jakarta packages across custom delegates, listeners, servlet filters and tests.
- Removed features: List every use of the UI apps, form or content engines, Mule integration and async history, and assign a replacement for each.
- Spring baseline: Confirm your Spring stack can move to Spring Boot 3 and that libraries on the classpath support Jakarta.
- Test suite: Check whether your tests run on JUnit 3 or 4 and whether that affects the Flowable 8 step later.
Before choosing this path, confirm which removed features you use and whether a Flowable 7 target gives you enough time before Flowable 8 becomes the next step for your team.
Moving directly to Flowable 8 combines the Flowable 7 changes with a second baseline shift. Flowable 8.0.0 was released on February 27, 2026, and it upgrades to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. A direct jump is only sensible when those prerequisites are already in place and your team has the capacity to change several layers at once.
- Spring and Boot level: Confirm the application already runs on Spring Boot 3 and can move to Spring Boot 4 and Spring Framework 7 without blocking third-party libraries.
- JSON usage: Inventory scripts, expressions and variables that touch JSON, and decide whether to start in the Jackson 2 compatibility mode.
- Test framework: Confirm your process tests are on JUnit 5 or have a rewrite scheduled, because JUnit 3 and 4 support is removed.
- Engine baseline: Verify that the Flowable 7 changes such as Java 17, Jakarta and removed features are already complete.
- Rollback: Confirm you can restore the database and application to the previous version if the Flowable 8 build fails in staging.
Before choosing this path, ask your team to demonstrate a passing Flowable 8 build on a copy of production process definitions, since that test is the clearest evidence that the direct move is ready.
Preparing the Flowable 6 estate before any move
Before choosing between staying on Flowable 6 and moving, the estate needs an inventory. The cards below cover the components that version 7 removed, the runtime and dependencies, custom code that touches identity, the database state, test coverage and the migration assessment for Camunda 7 or Activiti sources. Each one shows what to check and why it changes the cost of the decision.
Removed components still in use
Version 7 removed the UI applications, the form and content engines, the Mule integration and async history. Find out which of these your application relies on, whether through the Modeler, Task or Admin apps, form definitions, content storage, Mule flows or async history settings. Each dependency becomes a replacement item in any later plan, so list them by owner and by how users reach them.
Java runtime and dependency inventory
Record the JDK version on every node, the servlet container or Spring version, and the Flowable artifacts and their transitive libraries. Version 6 supports Java 8 and later, while version 7 runs on Java 17 or higher, so the runtime is the first hard gate. Confirm which application servers, base images and build plugins would also need changes.
Custom delegates and identity overrides
List every custom delegate, listener, expression and script, plus any override of IdmIdentityServiceImpl or any implementation of the IdmIdentityService interface, including LDAP wiring. These classes carry the business logic and identity behavior that the move must preserve. Mark the ones that use javax namespaces or depend on libraries that may change.
Database backup and schema state
Confirm the database type and version in use, which can be H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server, and take a tested backup of the Flowable schema. Record whether the schema was created by the engine or by DBA scripts, and check for running or failed jobs. The schema state decides how the upgrade is sequenced and how a rollback would work.
Test environment parity
Check whether the test environment runs the same Java version, database, identity source and deployed process definitions as production. Measure how much of the process behavior is covered by automated tests and which tests depend on the old runtime. Parity gaps are where upgrade defects go unnoticed, so note each difference before any version change is scheduled.
In-place migration assessment
If the estate came from Camunda 7 or Activiti, check whether the process instances and history can move to Flowable in place rather than through a rebuild. Flowable's engineering team describes an in-place path and a free tool named LEAP that reports what a migration involves. Ask the vendor or a partner to run that assessment against a copy of your data before committing to a timeline.
How the staged move runs, with rollback points
The sequence moves a Flowable 6 application in three checkpointed stages, so each change is verified and reversible before the next one starts.
Freeze the baseline and take database backups
Record the current Flowable 6 version, the Java and Spring versions, the database type and the list of custom delegates, listeners, identity services and scripts. Freeze deployments of process definitions, then take a full database backup and confirm it restores in a separate environment. Your application owner and DBA sign off that the baseline matches production. The rollback point is the restored backup and the tagged source commit, which together let you return to Flowable 6 at any later step.
Upgrade the JDK and build toolchain on Flowable 6
Move the application to a newer JDK while still on Flowable 6, which the project says supports Java 8 and higher. Update the build tool, plugins and test runner so the existing test suite builds and passes unchanged. This isolates runtime changes from the Flowable version change. Done means the full regression suite is green on the new JDK with no Flowable version change, and the build artifact is archived as the fallback.
Move from Flowable 6 to 7 with Jakarta and replacements
Upgrade to Flowable 7, which requires Java 17 or higher, Spring Boot 3 and Jakarta EE. Convert javax namespaces to jakarta, then address the components version 7 removed: the Modeler, Task and Admin UI apps, the form and content engines, Mule integration and async history. Each removed component needs a named replacement or a documented retirement decision. Done means the application compiles and starts against Flowable 7 in a development environment, with each removed component mapped to its replacement.
Run the engine schema upgrade in a test environment
Apply the database schema upgrade for Flowable 7 in a restored copy of production data, either by automatic upgrade at engine start or through DBA-run scripts, depending on your policy. Check the engine logs for version mismatch errors and confirm that running process instances, timers and history rows remain queryable. Rollback here means restoring the step 1 backup into the test environment, since schema changes are not reversed in place. Done means a timed, logged upgrade completes cleanly and sample instances advance through their next task.
Gate the release on regression and behavior tests
Run the full regression suite against Flowable 7, including process execution tests, custom delegate tests, REST API clients, scripts and expressions. Compare results with the Flowable 6 baseline and review any change in process outcomes, date handling or variable types. Your QA lead and application owners approve the gate in writing. Rollback is to keep production on Flowable 6 until the gate passes. Done means no unexplained differences remain and every open defect has a documented owner.
Move from Flowable 7.x to 8 with the framework changes
Once the Flowable 7 release is stable, upgrade to Flowable 8.0.0. This step covers the move to Spring Framework 7 and Spring Boot 4, which has no backward compatibility for Spring Boot 3, and the change to Jackson 3 as the default JSON library, with a Jackson 2 compatibility layer available. Test suites still on JUnit 3 or 4 must move to JUnit 5 before they run, since support for those versions was removed. Done means the Spring Boot 4 application passes the regression gate with JSON-touching models verified.
Promote to production with a documented fallback
Deploy the verified Flowable 7 or 8 build to production in a window your change process allows, with the schema upgrade already proven in step 4. Monitor failed jobs, the async executor and the monitoring endpoints during the first business cycles. Keep the step 1 backup and the Flowable 6 artifact available until the team agrees the rollback window has closed. Done means production processes complete normally, and the operations team has signed off the fallback decision.
What makes a Flowable upgrade take longer
This table lists the factors that most often extend a Flowable 6 move to version 7 or 8, along with how each one affects the work. Read each row against your own application inventory, since the same driver can be trivial in one system and expensive in another. The main takeaway is that the amount of custom code, removed components and test coverage matter more than the version number itself.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Custom Java delegates and scripts | Delegates, listeners and script tasks call Java APIs and may depend on Spring or Jackson types that change in later majors. | Inventory every delegate and script, group them by dependency, and migrate the most-used ones first with unit tests in place. |
| Removed components in use | Version 7 removed the UI apps, form and content engines, Mule integration and async history, so any dependency on them adds replacement work. | Check which removed features your processes actually use, and confirm with the project what replacement options exist for each. |
| Process and CMMN model count | Each deployed BPMN or CMMN model may need review for behavior changes, expressions and extension elements. | Prioritize models by business criticality and by how often they call custom code, and retire unused definitions before the move. |
| Running instance volume and history size | Long-running instances must survive the move, and large history tables increase migration and verification time. | Measure active instance counts and history table size early, and agree on a history retention policy before planning the cutover. |
| JUnit 3 or 4 test suites | Version 8 removed JUnit 3 and 4 support, so suites written for those frameworks must be rewritten before the engine upgrade can be verified. | Count test classes by JUnit version, and treat the rewrite as a separate workstream that runs before the Flowable 8 engine change. |
| Spring and Jackson customizations | Spring Boot 4 has no compatibility with Spring Boot 3, and Jackson 3 is the default JSON library, so custom configuration and JSON handling need review. | List custom Spring beans, auto-configuration overrides and JSON variable handling, then confirm the required Jackson path with the Flowable 8 release notes. |
| Number of environments and integrations | Each environment needs its own schema check and test run, and each external integration needs a contract check against the new engine. | Standardize environment promotion, script schema changes, and keep an integration test set that runs in every environment. |
Questions buyers ask before deciding to upgrade
Does Flowable 6 still get maintenance from the project?
Yes, according to the flowable-engine README, Flowable V6 is still maintained and supports Java 8 and higher, while Flowable V7 requires Java 17 or higher. Maintenance is not the same as a roadmap, though. The project's versioning strategy aims for source and binary compatibility within minor and micro releases, and it removes deprecated APIs two minor versions after deprecation. Ask your vendor or the project which Flowable 6 releases will receive fixes, how long they will be supported, and which security advisories apply to your version. Then compare that answer with your own Java and application server support dates, because the runtime often sets the deadline before the engine does. See the flowable-engine repository for the current maintenance statements.
What drives the cost and effort of a Flowable upgrade?
The main drivers are the size of your process, case and decision model inventory, the number of Java delegates, scripts, expressions and listeners that touch changed APIs, and how many integrations depend on the REST API or on removed components. The 7.0.0 release notes list removed pieces, including the UI applications, the form and content engines, Mule integration and async history, so any application that uses them adds replacement work. Upgrades to Java 17, Spring Boot 3 and Jakarta EE touch build files, dependencies and every package that imports javax. A quote should separate inventory and assessment, code and model changes, database schema work, test rewrites, environment changes and cutover support, with each item tied to a named artifact count. Ask for assumptions in writing.
How long does the upgrade take, and what sets that duration?
No duration figure is published in the sources for this topic, so the honest answer is that timing depends on scope and your release process. The biggest variables are how many applications share one engine, whether you run Flowable 6 on Java 8 with older frameworks, how well your tests cover process behavior, and how much of the work must wait for freeze windows or regulated change approvals. Staging the move in steps, such as Java and framework baselines first, then the engine, then schema and data, usually lengthens calendar time but reduces rollback scope. Ask the implementer for a dated plan with milestones, the test evidence required to exit each stage, and the dependencies on your own change calendar.
What does our internal team need to provide for the work?
The work needs named people who know the business processes behind each model, owners for the database and the production change window, and engineers who can run the existing test suite and deployment pipeline. Business owners confirm expected outcomes for running instances, since in-flight processes are the hardest part to validate. Platform or DBA staff provide access to non-production databases, backup and restore procedures and schema change approval. Security or compliance staff confirm evidence requirements for the change. Ask the partner to list these roles, the hours you should expect from each, and the decisions they need you to make before build starts, so the schedule does not depend on unspoken availability.
Can our own team do the Flowable upgrade in-house?
Yes, a capable Java team can upgrade Flowable without a partner, especially when the application is small, the tests are strong and the team has done a major framework upgrade before. The risk rises when the team has limited Spring, Jakarta or database migration experience, when custom delegates depend on removed components, or when there is no staging environment that mirrors production data. A practical test is whether your team can rerun a representative set of running and completed instances after the change and explain every difference. If you do bring in a partner, ask for a written scope, named deliverables and a knowledge transfer plan, so your team can own the result after cutover.
How should we handle a Camunda 7 or Activiti source system?
Treat Camunda 7 or Activiti as a separate migration decision rather than an extension of the Flowable upgrade. Flowable states in a September 7, 2022 engineering blog post that Camunda 7 and Activiti data can be migrated in place, including active process instances and history, and it offers the free Flowable LEAP tool to report ahead of time what a migration involves. Run that assessment first, then decide whether to move your data before or after the version change. Ask the implementer to document which source versions are in scope, how running instances will be handled, how history is retained, and what evidence will show that behavior matches the source system. See the escape from legacy blog post for the migration approach.
What DeployOpen delivers when you stage the move
Staging a move off Flowable 6 usually starts with a fixed-scope assessment that DeployOpen can deliver inside your own infrastructure, covering your cloud accounts, data centers or air-gapped networks. The assessment inventories every process, case and decision model, custom delegates and listeners, identity service overrides, REST clients, database types and deployment pipelines, and maps each one against the changes in Flowable 7 and 8. The output is a written inventory and a risk register that names which items need rewriting, which need only retesting, and which the removed components affect, such as the Modeler, Task and Admin apps, form and content engines, Mule integration and async history.
The main delivery outputs are an upgrade plan with an agreed sequence, a test strategy covering process tests and REST consumers, a schema upgrade approach that your DBAs can review, and a rollback plan for each stage. DeployOpen can also prepare a proof-of-concept upgrade branch and a test environment that mirrors your production database. Every deliverable, its acceptance criteria and its timeline are agreed in writing before work starts, so you know what you will receive and what you must provide, such as access to source code, sample data and named reviewers on your side.
Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that want a partner on call while they move Flowable versions in stages. Retainer terms, response expectations and the work they cover should be stated in the same written agreement. Before you request a quote, confirm with your own security and compliance leads which evidence your auditors will expect from the upgrade, because DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications.
How DeployOpen scopes and delivers a Flowable upgrade
DeployOpen approaches the stay-or-move decision as a written scope, not a sales question. We start from your running Flowable 6 application, its Java and Spring baseline, its removed-component exposure and your support obligations, then agree deliverables before any change is made.
How we scope
- The written scope lists the Flowable 6 applications, engines, delegates and REST clients in use, with their Java and Spring baselines.
- Scope records which removed components the application depends on, such as UI apps, form or content engines, Mule or async history.
- Engagements are fixed-scope, so decision criteria, deliverables and timelines are agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if you stay on Flowable 6 for a period.
How we build
- We prepare a staged move plan that separates the Java 17 or Spring Boot 3 step from any later Flowable 8 step.
- We build the target environment in infrastructure you control, with the same database types your current deployment uses.
- Test suites are reviewed for JUnit version, scripting and JSON usage so regression coverage travels with the upgrade.
- Process definitions, delegates and REST clients are checked against the target version before any production change.
How we hand over
- Handover includes the written decision record, the staged plan, the upgrade runbook and the rollback steps for each stage.
- Database schema changes are documented with backup points, the upgrade method chosen and the sequencing with application rollout.
- Your team receives the test evidence, configuration changes and open risks, so the decision can be reviewed by your own engineers.
- Documentation covers which Flowable 6 support questions remain with your team and which move to a new version.
How we support
- Support after handover can be covered by a retainer that tracks Flowable release notes and deprecation changes for your application.
- Continuous testing can be added so regressions in process, case and decision models are caught between Flowable releases.
- Re-review of the stay-or-move decision is scheduled when your Java, Spring or Flowable baseline changes, or support needs shift.
- Confirm with DeployOpen during scoping which support hours, response expectations and upgrade cadence the retainer includes.
