Why a Flowable 6 to 7 upgrade is a platform change, not a library bump
A Flowable 6 application that has to move to version 7 is facing a platform change, not a dependency update. The move changes the Java baseline to 17, the Spring Boot baseline to 3 and the namespace from javax to Jakarta, and it removes the Flowable 6 UI applications, the form and content engines, the Mule integration and async history. Each of those changes touches code that compiles, deploys or stores data differently, so the team should plan one program covering the runtime, the framework, the application code and the database rather than a version bump in the build file. The Flowable 7.0.0 release notes confirm that version 7 moved to Java 17, Spring Boot 3 and Jakarta EE and focused on the BPMN, CMMN, DMN and event registry engines and their REST APIs. Your first task is an inventory: which of the removed components does your application actually use, and which Java, Spring and servlet APIs does your code import?
The supported path is a staged move. Treat version 7 as the destination for this topic and version 8 as a separate, later step with its own baseline change to Spring Boot 4, Jackson 3 and the end of JUnit 3 and 4 support, as described in the Flowable 8.0.0 release notes. Moving in one jump from Flowable 6 to 8 would combine several breaking changes in a single release window, which makes failures hard to attribute. Before you commit to a sequence, confirm with Flowable which maintenance and security fixes still reach version 6 on your target Java version, and check the current version list on the Flowable engine releases page before setting dates. Decide early who owns each decision: the platform team for the JDK and container image, the application team for the namespace and API changes, and the DBA for the schema upgrade.
Which Flowable 7 changes hit your application and what to do about each
This table maps each change in the Flowable 7.0.0 release to the part of your application it affects and the inventory or testing step that comes first. Read each row against your own codebase and deployment, and treat the action column as the starting checklist for your upgrade plan. Rows that involve a removed component matter most if your team depends on it today.
| Change | Impact on your application | Action needed before upgrading |
|---|---|---|
| Java 17 baseline | Application code, build tooling and runtime images built for Java 8 will not run on the version 7 baseline without changes | Inventory JDK versions in build pipelines and container images, then confirm which dependencies and libraries support Java 17 |
| Spring Boot 3 baseline | Spring Boot 2 applications and starters must move to Spring Boot 3 configuration, dependency coordinates and property names | List every Spring Boot starter and Flowable dependency, then map them to the versions the 7.0.0 release notes describe |
| Jakarta EE and javax to Jakarta namespace | Imports, servlet filters, JAX-RS and validation annotations in javax packages will fail to compile or load | Search custom delegates, listeners, REST clients and servlet code for javax imports and plan a package rename with compile-time checks |
| Removed UI applications | Modeler, Task and Admin apps from version 6 are no longer shipped, so users and administrators lose those screens | Identify who uses each app, document the tasks they perform, and decide the replacement before cutover |
| Removed form and content engines | Process or case models that call form or content engine APIs will break at compile time or runtime | Search models, delegates and expressions for form and content engine references and record each dependency |
| Removed Mule integration | Flows that rely on the Mule integration will stop working once the component is removed | Confirm whether any Mule-based flows exist, then redesign them on a supported integration point in the Flowable docs |
| Removed async history | Applications that depend on asynchronous history processing need a different history strategy | Review history configuration and reporting queries, then test how history is written and read under load |
| Database schema upgrade | Engine startup or a DBA-run script must move the schema to the version 7 structure, and a mismatch can block startup | Take a verified backup, agree on automatic versus script-based upgrade with your DBA, and rehearse the schema change in a copy of production |
How the Java, Spring and Jakarta changes split across your codebase
Flowable 7 moved to Java 17, so the first question is which parts of your build and runtime still assume an older Java. Start with the compiler target, the base container image, the JDK your CI agents use, and any build plugins pinned to versions that do not run on Java 17. Application servers, agents and monitoring libraries bundled into the deployable are part of the same inventory, because a runtime that starts the engine can still fail on a bundled tool.
- Compiler and toolchain settings: Check the source and target levels in your Maven or Gradle configuration and any toolchain declarations.
- Base images and hosts: List every JDK your containers, VMs and CI runners use, including those managed by a platform team.
- Bundled libraries: Identify libraries that use removed or changed JDK internals, such as reflection hacks or deprecated APIs.
- Build plugins: Confirm each plugin version runs on Java 17 and supports your build tool version.
- Test environments: Run the full build and engine startup on Java 17 in a non-production environment first.
Confirm the exact Java baseline required by the Flowable 7.0.0 release notes before you set targets, and check it against your vendor support matrix.
Flowable 7 moved to Spring Boot 3, which changes auto-configuration, starter names, and transitive dependency versions. Applications that use Flowable Spring Boot starters, or that wire the engine into Spring manually, need their dependency graph reviewed as a whole rather than one library at a time. Mixing Spring Boot 2 and Spring Boot 3 artifacts is a common source of startup failures and class loading errors.
- Parent and BOM versions: Find every place that imports a Spring Boot parent or bill of materials and align them to one version.
- Starter and auto-configuration names: Compare the Flowable starters you use with the Spring Boot docs for the target version.
- Transitive conflicts: Run a dependency tree report to catch Spring 5 or older libraries pulled in by other components.
- Configuration properties: Review
application.propertiesorapplication.ymlkeys that were renamed or moved between Spring Boot generations. - Actuator and monitoring: Check any endpoint exposure, since monitoring setups often depend on Spring Boot internals.
Test the application context startup, the process deployment step and the actuator endpoints in a staging environment that mirrors production configuration.
The move to Jakarta EE replaces the javax package namespace with jakarta in servlet filters, JPA entities, validation annotations and any other Java EE API your code imports. The change is mechanical in most files but easy to miss in custom code, generated code, XML descriptors and third-party libraries that still expect javax. Compile errors catch many cases, while reflection, string-based class names and configuration files can fail only at runtime.
- Source imports: Search for
javax.servlet,javax.persistence,javax.validationand similar prefixes across all modules. - Descriptors and resources: Check
web.xml,persistence.xml, orm mappings and validation message bundles for old namespaces. - Custom delegates and listeners: Review Flowable Java delegates, event listeners and servlet filters that touch HTTP or persistence APIs.
- Third-party jars: Confirm each library has a Jakarta-compatible version, since a
javaxdependency can load alongsidejakartaclasses and cause subtle conflicts. - Runtime reflection: Look for class names stored in configuration or the database as strings, which the search will not find.
Run the full integration suite and exercise the servlet and persistence paths directly, because compilation alone does not prove the runtime wiring is correct.
Flowable 7 focuses on the BPMN, CMMN, DMN and event registry engines and their REST APIs, and it removed the Flowable REST application's bundled UI apps. Any client that calls the engine REST API from another service, a front end or a script needs an inventory, because response shapes, endpoints and authentication behavior can differ from version 6. Clients often depend on details nobody documented, such as date formats or the exact order of returned fields.
- Endpoint inventory: Log which REST paths and HTTP methods each client calls, using gateway or access logs over a representative period.
- Payload contracts: Capture sample request and response bodies for each endpoint and compare them against the target version.
- Authentication setup: Confirm how clients authenticate and whether any of them rely on the default users or accounts you plan to change.
- Removed UI dependencies: Identify any browser pages or embedded frames that loaded the Modeler, Task or Admin apps.
- Consumer tests: Write contract tests for the calls you keep, so each client has a regression check before cutover.
Schedule these tests with the owners of each consuming service, since they hold the expectations the engine team does not see.
What to back up and inventory before touching the engine
Most Flowable 6 to 7 upgrades that go wrong fail on something the team could have listed before the first build. The cards below cover the data you must be able to restore, the custom code and identity wiring you must map, the removed components you depend on, and a staging environment that behaves like production. Work through them in order, because the inventory determines what the staging tests need to prove.
Database backups before the schema upgrade
Take a full, restorable backup of the Flowable database before any engine version changes, and test the restore on a separate instance. Version 7 brings its own schema changes, so a backup taken after the upgrade starts does not protect you from a failed migration. Confirm the backup covers the runtime, history and identity tables, and record the Flowable version it was taken from. Ask your DBA whether the upgrade will run automatically at engine start or through scripts they run, because that decision changes who owns the rollback. Restore testing is the step most teams skip.
Inventory of delegates, listeners and identity services
List every Java delegate, execution or task listener, event listener, script task, expression and custom identity service your processes reference. Flowable's docs allow identity management to be replaced by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, so record which classes override it and which LDAP or database sources they read. For each item, note the Flowable API it calls and whether it compiles against Jakarta packages. This list becomes the work breakdown for the namespace change and the test plan.
Removed components in use
Identify which of the components version 7 removed your organization actually uses: the Modeler, Task and Admin UI applications, the form and content engines, the Mule integration and async history. Search process definitions, deployment pipelines, bookmarks, runbooks and scheduled reports for each one, since usage is often hidden outside the engine. Record the owner and the replacement decision for each item. Anything without a named replacement becomes a blocker on the upgrade schedule rather than a note for later.
Java and Jakarta baseline assessment
Record the JDK version, application server or servlet container, and every library that imports javax packages. Version 7 moved to Java 17, Spring Boot 3 and Jakarta EE, so a dependency scan for javax imports and a check of third-party jars for Jakarta-compatible releases will show the size of the code change. Note any custom servlet filters, REST clients or JAX-RS resources that will need namespace updates. Ask your platform team which runtime images and build agents must move to Java 17 at the same time.
Staging with production-like data and databases
Build a staging environment that matches production on database engine and version, such as PostgreSQL, Oracle or Microsoft SQL Server, and on the number of active process instances, timers and history rows. Copy a recent production snapshot with personal data masked, then run the upgrade on it end to end. Confirm the staging database type appears in the supported list for the target version, and that any MySQL version you run meets the millisecond precision requirement in the configuration docs. Staging results are only useful if the data volume and database type match what you will upgrade in production.
The upgrade sequence, with checks and rollback points at each stage
The sequence moves a Flowable 6 application to version 7 in controlled stages, so each change is verified and reversible before the next one starts. Every stage closes with a check and a defined point to return to the last known good state.
Freeze scope and back up everything
Pause deployment of process definitions and changes to the Flowable 6 application, then take a full backup of the production database, the deployed application artifacts, and the configuration. Record the current Flowable and Java versions, the list of deployed process, CMMN and DMN definitions, and any use of the Modeler, Task or Admin apps, the form or content engines, Mule integration or async history. The step is done when a restore from the backup has been rehearsed on a copy of the database and the inventory has been reviewed by the application owners. Rollback point: the untouched production environment and the verified backup.
Move to Java 17 and Spring Boot 3 on a branch
Create a version control branch and move the build to Java 17 and Spring Boot 3, along with the Flowable 7 dependencies and starters your application uses. Resolve compiler errors, changed dependency coordinates and removed APIs before touching the namespace. Run the existing unit and integration tests on the branch against a disposable database. The step is done when the application compiles, starts against the test database, and the test suite results are recorded as a baseline. Rollback point: the main branch, which still runs the Flowable 6 build.
Apply the Jakarta namespace change
Convert the javax packages used by your delegates, listeners, servlet filters, REST clients and security configuration to jakarta, and review any XML, properties or script files that reference the old packages. Confirm the Flowable 7 release notes match the packages you import, since the change touches every custom class that extends or calls the engine. Run the test suite again and start the application in a servlet container or Spring context to confirm the classes load. The step is done when no javax references remain in application code and the tests that passed in the baseline still pass. Rollback point: the Java 17 baseline commit, before the namespace edits.
Replace or retire the removed components
For each item removed in version 7, decide whether it is retired or replaced: the Modeler, Task and Admin UI applications, the form and content engines, Mule integration and async history. Replacements typically call the REST API from a new front end or an integration you build, and async history needs a documented decision about which history data you still need. Verify each replacement with a test that exercises the same user or system behavior the removed component provided. The step is done when every removed component has a recorded owner, a disposition and a passing test or accepted retirement. Rollback point: the branch state before the first removal, kept as a separate commit.
Run the schema upgrade in staging
Restore the production backup into a staging database that matches production's engine, version and size as closely as possible. Run the database schema upgrade using the method your DBA approves, either automatic upgrade at engine start or the upgrade scripts run by the DBA, and check the engine logs for version mismatch or failed statements. Confirm the schema version recorded by the engine matches the Flowable 7 release you deployed. The step is done when the upgrade completes without errors on the staging copy and the DBA signs off on the change. Rollback point: the restored staging database, which can be recreated from the backup at any time, and the production backup if the change is ever needed in production.
Verify running instances and async jobs
Start the upgraded application against the staging database and check the state of existing work: confirm that active process, case and decision-related data loads, that running instances can be queried and advanced, and that timers and asynchronous jobs are picked up by the async executor. Confirm lock owners and lock expiration are being handled as expected when more than one node runs. Compare counts of active instances and open jobs before and after the upgrade. The step is done when the counts match, sample instances complete end to end, and no jobs remain stuck or failed. Rollback point: the staging database restored from backup and the Flowable 6 build, which can be redeployed against it.
Promote to production with a tested exit path
Schedule the production change using the same runbook you rehearsed in staging, with the backup taken in the first step still available. Deploy the schema change and the new application in the order the runbook sets for your topology, then repeat the instance and job checks against production data. Keep the Flowable 6 artifacts and backup until the application owners confirm that completed instances, timers and reports behave as expected. The step is done when the post-deployment checks pass and the owners sign off. Rollback point: the restored production backup and the previous application artifacts, with the trigger conditions for using them agreed before the change starts.
Replacing the Modeler, Task, Admin, Mule and form and content engine dependencies
Flowable 7 removed the Flowable 6 UI applications, the form and content engines, the Mule integration and async history, so every one of these dependencies needs a named replacement before the build starts. The removed components are not optional features you can keep on the old classpath. If your application calls the Modeler, Task or Admin apps, renders forms through the form engine, stores documents through the content engine, or routes messages through Mule, that code will not run on version 7 unchanged. Inventory each dependency first, including integrations your team may have forgotten because they run as scheduled jobs or shared scripts, and record who owns each replacement.
The supported integration surface in version 7 is the engine itself: the Java APIs of the BPMN, CMMN, DMN and event registry engines, and the REST APIs that sit on top of them. Plan new front ends as REST clients that call the engine's task, process instance and history endpoints, and check the Flowable 7.0.0 release notes for the exact scope of the REST APIs before you commit to a design. Decide three things early: who models processes after the Modeler app is gone, how form definitions move out of the form engine and into your front end or application code, and where document handling goes once the content engine is removed. Each choice changes the scope of your front end and the data your application must store.
Async history is also gone, so any reporting or audit logic that depended on it needs a new source, usually the standard history tables or an event listener you write. Confirm with your architects which decisions must be signed off before development, because they change the front end framework, the authorization model and the data flow. The Mule replacement also needs a decision: whether message routing moves to your existing broker or integration platform, and whether a process task calls that service directly. Ask your Flowable partner or internal team to write these decisions into the statement of work so the removed components have owners and acceptance criteria.
What makes a Flowable 6 to 7 upgrade take longer
This table lists the factors that expand the work of moving a Flowable 6 application to version 7, and the direction each one pushes effort. Read each row as a question to answer about your own application before estimating scope, since the drivers stack and a single heavy one often sets the critical path.
| Driver | Why it increases effort | How to keep it down |
|---|---|---|
| Custom delegates and listeners | Each Java delegate, task listener and event listener compiles against the version 6 API and must be checked for javax imports, Java 17 compatibility and Jakarta namespace changes. | Inventory every class referenced in BPMN and CMMN models, and group them by how often they change. |
| Dependence on removed UI apps | Teams that rely on the Modeler, Task or Admin apps must replace them with their own front ends or another tool before cutover. | Confirm which screens and users depend on those apps and plan replacements early. |
| Form engine and content engine use | Form and content engine definitions, and any code that calls them, have no direct equivalent in version 7 and need redesign. | Count active form definitions and content references, and decide what moves to your application. |
| Mule integration flows | Mule flows that call or are called by Flowable must be rebuilt on another integration path, which adds design, testing and cutover work. | List each flow, its owner and its message contracts before scoping. |
| Reliance on async history | Processes that depend on asynchronous history writes need a different history configuration and validation that the data still arrives as expected. | Identify which reports and audit queries read history, and test them against the new setting. |
| Database size and schema history | Large history tables and many prior schema upgrades lengthen migration rehearsals, backups and rollback planning. | Measure table sizes, confirm the upgrade path from your current schema version, and rehearse on a copy of production. |
| Identity service customizations | Custom implementations of the identity service, such as LDAP or organization directory adapters, must be reviewed against the version 7 interfaces. | Document each override and test authentication, group lookup and user lookup separately. |
| Test coverage | Thin automated tests mean more manual regression passes and more time to prove that process behavior is unchanged. | Add process tests for critical paths before the upgrade starts so regressions show up early. |
Questions teams ask before upgrading Flowable 6 to 7
What drives the cost of a Flowable 6 to 7 upgrade?
The cost follows the written scope, mainly how many applications and process, case and decision models you run, and how many custom delegates, listeners, scripts and integrations depend on javax APIs or on components version 7 removed. The main cost components are engineering time for the Java 17, Spring Boot 3 and Jakarta namespace changes, replacement work for the removed Modeler, Task and Admin apps, form and content engine usage and Mule integration, test effort, environment and database work, and cutover support. The code changes and replacement work are one-time costs. Ongoing maintenance of the upgraded platform recurs. Ask for a quote built from a written inventory of models, custom code, integrations and removed features in use, with assumptions and exclusions listed. The Flowable 7.0.0 release notes list the components that changed, which helps your inventory.
How long does a Flowable 6 to 7 upgrade take?
The timeline depends on how much of your Flowable 6 estate changes, and no fixed duration applies to every application. The main drivers are the number of removed features still in use, the size of the custom Java code, the quality of your existing test suite, and the Java 17 and Spring Boot 3 readiness of your platform. Schema work, change-freeze windows and business sign-off also set the pace. Ask for a plan with milestones: inventory, code changes, replacement of removed components, test rounds, schema rehearsal and production cutover. Each milestone should name an owner and an exit criterion. If a provider gives a single duration before the inventory is complete, ask which assumptions it depends on.
What does a Flowable 6 to 7 upgrade need from our own team?
The work needs decisions and access from several roles, whether an internal team or a partner does the build. Process owners must confirm which models are live, which versions are still in use and which business behaviors must not change. Developers who wrote the delegates, listeners and scripts must explain them and review the changes. The platform team must provide a Java 17 runtime, container or server updates and deployment pipelines. A DBA must own backups, schema rehearsal and the production schema change. QA needs regression cases for each process and decision. If you replaced the default identity handling, your security team must review the identity service, since Flowable documents overriding IdmIdentityServiceImpl or implementing IdmIdentityService.
Can an internal team upgrade Flowable 6 to 7 without outside help?
An internal team can do the upgrade if it already has working knowledge of Java, Spring Boot and the Flowable engines, has time in its plan, and can run a full regression cycle. The team should have done a Jakarta namespace migration before, or be ready to learn it, and should own the replacement of the removed UI applications and form or content engine usage. Teams with thin test coverage, few people who know the custom code, or a fixed cutover date often bring in a partner under a written, fixed scope. A hybrid model is common: internal staff own the business logic and sign-off, while an outside team handles the framework changes and the test harness. Ask any provider to name the deliverables, the handover and the items it will not cover.
Should we skip Flowable 8.0.0 and upgrade to the 7.x line?
For a Flowable 6 application, the practical target for this move is the 7.x line, and the latest 7 release supplied for this topic is 7.2.0, published on August 21, 2025. Flowable 8.0.0, released on February 27, 2026, moves to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. Combining the Flowable 6 to 7 change with those changes multiplies risk in one release window. Treat 8.0.0 as a separate, later step, and read the 8.0.0 release notes before you plan it.
What happens to async history when we move to Flowable 7?
Flowable 7.0.0 removed async history, so any application that depends on it needs a configuration change before it runs on version 7. Confirm the exact settings and classes affected in the release notes, and then check where your application reads history: reports, dashboards, audit exports and compliance evidence. Measure the write cost of the history level you choose under realistic load, since moving history off the asynchronous path can change response times. Keep the async executor separate in your thinking. It still runs timers and asynchronous jobs from a thread pool, and it coordinates nodes through lock owners and lock expiration times in the database. Add tests that confirm history is written where your reports expect it.
How do database schema upgrades fit into the Flowable 7 sequence?
Schema changes should be sequenced before the application that needs them, and each step should be rehearsed on a copy of production. Start with a verified backup and a restore test. Then confirm whether your Flowable version upgrades the schema automatically at engine start or expects a DBA to run upgrade scripts. The configuration docs list the supported database types, including H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and note that MySQL versions below 5.6.4 lack millisecond precision. Check that your database version is supported before you start. Plan for a version mismatch error if an old node starts against a new schema, and decide whether the rollout is rolling or a single window. Ask the team to write down the rollback point for each step.
Who should stay on Flowable 6 for now and who should move
Staying on Flowable 6 is a reasonable short-term choice for some teams, but the decision turns on one question: how much runway does your Java 8 estate have? Version 7 moved the engines to Java 17, Spring Boot 3 and Jakarta EE, and it is a jump from the javax namespace to jakarta, which touches every servlet, validation and persistence import in your application. Teams with a locked Java 8 runtime, or with delegates and listeners that depend on removed or deprecated APIs, face the largest change. Teams that already run Java 17 or later, use only the BPMN, CMMN, DMN and event registry engines through their own code, and have no dependency on the removed UI apps, form and content engines, Mule integration or async history are in the best position to move early.
Before committing, confirm with the Flowable project what it will support for version 6 and for how long. The public release history on the flowable-engine GitHub repository shows the current line, but your decision needs the project's stated maintenance position for the 6.x branch, including whether security fixes will ship and on what timeline. Ask the same question about your database and driver versions, because a Flowable 6 upgrade on an older Java runtime can also force a driver or application server change. Put the answers in writing with your risk owner, since a support gap is a risk to accept or plan for, not a detail to find later. If you stay on Flowable 6 for now, treat it as a funded, dated transition rather than a freeze. Inventory which removed components you use, which libraries pin Java 8, and which teams own the delegates and tests. Record the date you will reassess, and make sure the Flowable 7 work is sized against the same inventory so the move does not restart from zero when the support question is answered.
How DeployOpen scopes, delivers and supports the Flowable upgrade
DeployOpen approaches the Flowable 6 to 7 upgrade as a written, fixed-scope engagement that starts with an inventory of your application, its engines and its database. We then plan and build the move to Java 17, Spring Boot 3 and Jakarta, replace the removed components, and hand over documented, tested results with optional ongoing support.
How we scope
- Inventory every Flowable 6 engine, model, delegate, REST client and UI app your application depends on.
- Confirm the Java, Spring and Jakarta baseline and the javax to Jakarta namespace changes your code and libraries need.
- Record in writing which removed components are replaced, retired or left out, with deliverables and timelines agreed before work starts.
How we build
- Move the application to Java 17 and Spring Boot 3, then convert javax imports and dependencies to Jakarta namespaces.
- Replace removed UI applications, form and content engines and Mule integration with designs you have approved, and test each one.
- Plan the database schema upgrade with backups, a tested rollback path and a sequence that matches your deployment process.
How we hand over
- Document the upgraded architecture, configuration, dependency changes and the async history removal decisions for your team.
- Run regression tests on processes, cases, decisions and REST clients, and deliver the results with the code and scripts.
- Walk your engineers through the runbook for schema upgrades, failed jobs and version mismatch errors before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope upgrade is complete.
- Confirm with us in the written scope which support hours, response expectations and upgrade paths the retainer includes.
- Plan later moves, such as Flowable 7.x to 8.0, as separate scoped work so each upgrade keeps its own testing and handover.
