Why a Flowable 7 to 8 upgrade is a platform-wide change
Flowable 8.0 requires Spring Framework 7 and Spring Boot 4, and the release notes state there is no backward compatibility for Spring Boot 3. A Java team running Flowable 7.x therefore cannot upgrade the engine alone: the application stack moves with it. Treat the engine upgrade as a change to the whole application platform, not as a library bump. Flowable 8.0.0 was released on February 27, 2026, after 7.2.0 on August 21, 2025 and 7.1.0 on October 7, 2024, so teams on the 7.x line have had a series of minor releases to plan around before this one.
The supported path is described in the Flowable 8.0.0 release notes, which list the Spring and Boot upgrade, the move to Jackson 3 with a Jackson 2 compatibility layer, and the removal of JUnit 3 and 4 support. Read the Flowable 8.0.0 release notes before estimating work, and confirm which 7.x release your application is currently on, since the upgrade sequence starts from there. Your first decision is whether your current Spring Boot 3 application can reach Spring Boot 4 in a single step, or whether it needs an intermediate stage on Flowable 7.x while the rest of the application catches up.
What changes in Flowable 8.0 and what each change requires
This table lists the four changes in the Flowable 8.0.0 release notes and the Java 17 and Jakarta baseline inherited from version 7. Read each row as a question for your own build: which framework versions, JSON libraries and test runners does your application depend on today, and which of them must move before or with the engine.
| Change | Impact on a Flowable 7 application | Action to confirm in your build |
|---|---|---|
| Spring Framework 7 and Spring Boot 4 | Flowable 8.0.0 drops Spring Boot 3 compatibility, so the application's Spring Boot parent and starters must move to a 4.x line with the engine. | Confirm the Spring Boot version your build inherits, every Spring starter it pulls in, and any Spring Boot 3 only library that cannot run on Spring Framework 7. |
| Jackson 3 as the default JSON library | Jackson 3 becomes the default, with a Jackson 2 compatibility layer. Scripts, expressions and JSON variables that call Jackson 2 APIs may fail or behave differently. | List every custom delegate, script and expression that touches JSON, and confirm whether the team will use the Jackson 2 compatibility mode first or move to Jackson 3 directly. |
| Removal of JUnit 3 and 4 support | Flowable 8.0.0 no longer runs process test suites written against JUnit 3 or 4, so existing tests fail to execute after the upgrade. | Count the test classes still using JUnit 3 or 4 annotations and runners, and confirm the JUnit 5 approach the team will adopt before the engine upgrade. |
| Java 17 and Jakarta EE baseline from version 7 | Version 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE. Version 8 builds on that baseline, so an application still on Java 8 or javax packages has not reached the 8.0 starting point. | Confirm the JDK your runtime images and CI agents use, and confirm the application has already completed the javax to Jakarta namespace change from version 6. |
Which parts of the stack move together
Flowable 8.0.0 moves the platform to Spring Framework 7 and Spring Boot 4, and the release notes state there is no backward compatibility for Spring Boot 3. That means the Flowable starters, your Spring Boot parent version and any Spring-managed beans or configuration classes must move in the same change set. A team that keeps Spring Boot 3 while bumping the Flowable artifacts will not get a clean start, and a team that upgrades Spring Boot first will hit Flowable 7 starters that do not match it. The Flowable Spring Boot docs list support for Spring Boot 4.x starters for the engines and the REST application, so confirm the exact starter coordinates for your chosen modules.
- Parent and starter versions: Change the Spring Boot parent, the Flowable BOM or starter versions and the Spring Framework version together in one build change.
- Configuration classes: Review any custom
@Configurationclasses that override engine beans, especially identity service or delegate registration. - Actuator endpoint: After the upgrade, confirm that the
/actuator/flowableendpoint that monitors running processes is exposed and that your management settings still allow it. - Embedded and REST deployments: Servlet container and REST application hosts follow the same Spring baseline, so check them in the same window.
- Java and Jakarta baseline: Check that your runtime and Jakarta dependencies match what the new Spring line requires before the first test run.
Confirm the supported Spring Boot and Java versions against the Flowable 8.0.0 release notes before you fix the target baseline.",
Flowable 8.0.0 uses Jackson 3 as its default JSON library and keeps a Jackson 2 compatibility layer. Anything that serializes or reads JSON inside the engine is affected: script tasks, expressions that touch JSON variables, custom listeners, and REST request and response bodies. These parts cannot wait, because a process that deserializes a variable differently can fail at runtime on a path the build never exercised. The compatibility layer is a way to keep old code running during the transition, not a permanent setting that removes the need for review.
- Script and expression code: Inventory every script task, expression and listener that imports Jackson classes or calls JSON methods on process variables.
- Compatibility mode: Decide whether to run in the Jackson 2 compatibility mode for the first release and set a date to remove it.
- REST payloads: Compare request and response JSON from the REST application against your API clients, since serialization changes can alter field shapes.
- Stored JSON variables: Test that existing serialized variables in running instances still deserialize after the change.
- Shared libraries: Check that custom delegates and shared utility jars do not pull in a conflicting Jackson version.
For the detailed package and method changes, the separate Jackson 3 migration topic covers the work in depth.
The Flowable 8.0.0 release notes state that support for JUnit 3 and JUnit 4 is removed. Process test suites that rely on JUnit 4 runners or rules will not compile or run unchanged against the new baseline. Tests are part of the same window because they are the only automated proof that your models, delegates and deployment resources still behave the same after the framework and JSON changes. Leaving tests on the old runner means the team has no fast signal during the upgrade itself.
- Runner and rule changes: Find every test class that uses JUnit 3 base classes, JUnit 4 runners or JUnit 4 rules and plan the move to JUnit 5.
- Engine test support: Move test setup to the Flowable test support classes for the new line, and check the current names in the Flowable docs.
- Deployment resources: Confirm that
@Deploymentresources still point at the BPMN, CMMN and DMN files you expect. - Green baseline: Run the existing suite on the old version first and record which tests pass, so each failure after the change can be traced.
- Spring test context: Verify that Spring test contexts load with the new Spring Boot 4 test support before judging process behavior.
Confirm the exact test annotations and extensions with the Flowable 8.0.0 release notes before you start rewriting.
Because the framework, JSON and test changes all touch the same codebase, the engine upgrade needs a defined order rather than a single switch. The team should set the sequence before the build starts, including which environments move first, how running instances are handled and when the database schema changes. Flowable 8 release notes and the Flowable 7 to 8 sequencing guidance should be read together with your own deployment pipeline. The point of the sequence is that no layer runs on a version the others have not been tested against.
- Pilot environment: Upgrade a non-production copy with production-like data before any shared environment.
- Schema changes: Decide between automatic schema upgrade at engine start and DBA-run scripts, and align that with your rollout.
- Running instances: Confirm how in-flight process instances will behave across the version boundary before cutover.
- Rollback path: Keep a tested restore point for the database and the previous application artifacts.
- Dependency freeze: Lock other library upgrades for the window so that failures can be attributed to the Flowable change.
Check the sequence with your DBA, platform team and application owners before the first environment is changed.
How to prepare before touching the engine version
Most Flowable 7 to 8 upgrade delays come from work done before the version number changes. The five items below give your team a fixed inventory and a tested recovery path, so the engine and application changes can be sequenced with known risk rather than discovered during the upgrade.
Inventory JSON-touching models
List every BPMN, CMMN and DMN model, delegate, script task and expression that reads or writes JSON variables. Flowable 8 uses Jackson 3 as the default JSON library and keeps a Jackson 2 compatibility layer, so each item needs an owner and a decision: migrate now, or run under the compatibility mode first. Record the package imports used in custom Java code, since those are the lines that break at compile time.
Inventory JUnit 3 and 4 suites
Count every process test class that extends JUnit 3 test cases or uses JUnit 4 runners and rules. Flowable 8 removes support for both, so these suites will not run after the engine change. Mark which tests exercise deployments with @Deployment resources and which depend on engine rules, so the team can plan the move to JUnit 5 and keep a green baseline on Flowable 7 before the switch.
Back up and rehearse restore
Take a full backup of the Flowable database, including running process instances, history and the job tables, and restore it into a separate environment. Time the restore and confirm that the engine starts against the restored data on the current version. A backup that has never been restored is an assumption, and the restore rehearsal is the only evidence that recovery works before the schema changes.
Match the test environment database
Build the test environment on the same database product and version family as production, chosen from the types the configuration docs list: H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server. Behavior differs by database, so an H2 test run does not prove a production upgrade. Confirm the MySQL version as well, because versions below 5.6.4 lack millisecond precision, which affects timer and history comparisons.
Confirm identity service overrides
Find every custom identity service, such as a subclass of IdmIdentityServiceImpl or an implementation of the IdmIdentityService interface, and any LDAP integration built from the reference implementation. Check each one against the Spring Framework 7 and Spring Boot 4 baseline, since bean wiring and dependency changes can break an override silently. Document which override controls user and group lookup so that the post-upgrade test plan covers it directly.
Sequence the application and engine upgrades
The sequence moves the tests and the application baseline first, so each later change is checked against a known-good state, and leaves the Flowable 8.0.0 engine swap until the application can prove its behavior on 7.x.
Freeze the current baseline and capture evidence
Before changing code, the team records the running Flowable version, Spring Boot version, Java version, database type and schema version, and exports a representative set of deployed process, CMMN and DMN definitions. The owner of the application signs off a list of critical flows and the expected outcomes for each. Done means the baseline is stored in version control and a full database backup has been taken and restore-tested, so that the rollback point at this step is a verified backup and the unchanged application build.
Migrate the test suite to JUnit 5
Flowable 8.0.0 removes support for JUnit 3 and 4, so the process tests must run on JUnit 5 before the engine moves. The team converts test classes to the Flowable test support on JUnit 5, keeps @Deployment resources unchanged, and runs the suite on the current Flowable 7.x build until every test passes with the same results as before. Done means the full suite is green on 7.x. Rollback point: the pre-migration commit, since the test changes do not alter production code.
Move the application to the Spring Boot 4 baseline on 7.x
The team upgrades Spring Framework and Spring Boot in the application while still on the Flowable 7.x engine, where the team can verify each change. Flowable 8.0.0 has no backward compatibility for Spring Boot 3, so this step must complete before the engine change. Developers resolve compile errors, starter and property renames, and actuator changes, then run the full test suite and start the application in a staging environment. Done means the application starts, the suite passes and the staging smoke tests match the baseline. Rollback point: the pre-step branch and its build artifact, which still run on Spring Boot 3.
Handle the Jackson 3 change with the compatibility layer
Flowable 8 uses Jackson 3 as its default JSON library and provides a Jackson 2 compatibility layer. The team first enables the compatibility layer so that existing scripts, expressions, JSON variables and REST payloads keep working, then runs the tests that touch JSON. Migrating code to Jackson 3 packages is a separate, later change tracked in its own plan. Done means JSON-dependent process tests and REST contract tests pass with the compatibility layer enabled. Rollback point: the step's commit, which can be reverted without touching the database.
Upgrade the Flowable 8.0.0 engine dependency
With the application on the Spring Boot 4 baseline and the test suite passing, the team changes the Flowable dependency and starter versions to 8.0.0 in a feature branch and builds the application. Engine configuration properties and any custom identity service, delegate or listener code are checked against the 8.0.0 release notes. The database schema upgrade is run only as the approach agreed in the schema plan, whether automatic at startup or by a DBA script. Done means the build succeeds, the suite passes against 8.0.0 and the staging application starts cleanly. Rollback point: the 7.x application artifact plus the pre-upgrade database backup, because the schema change may not be reversible by redeploying the old build alone.
Run database and process-instance checks
In a staging copy of production data, the team confirms that the schema version matches the engine, that the async executor acquires and releases locks as expected across nodes, and that a sample of running process, case and decision instances can continue, complete or be queried. Failed jobs and history rows are counted before and after. Done means the counts reconcile with the baseline from the first step and every critical flow from the sign-off list completes in staging. Rollback point: the staging restore from the step one backup, which lets the team rerun the checks.
Deploy in a controlled production window
The team deploys the verified build to production with the database backup taken immediately before the change, a monitored start of each node, and a documented decision owner who can stop the rollout. After deployment, operators confirm node health, the monitoring endpoint reports running instances, timers fire, and the critical flows complete with the same outcomes as the baseline. Done means the sign-off list is checked in production and the owner accepts the result in writing. Rollback point: the 7.x artifact and the backup taken before the change, with the rollback decision defined in advance.
Testing and rollback for a stateful engine
Rolling back a Flowable 8 upgrade is harder than rolling back a stateless application, because the engine's state lives in the database rather than in the deployed artifact. Running process instances, pending timers, async jobs and the history tables all persist across a redeploy. If the new engine has already written to the schema, restoring the previous WAR or container image does not return the data to the state the old engine expects. Your rollback plan therefore has to be written around the database first and the application second.
The plan must state, for each environment, whether the schema change is applied automatically when the engine starts or by a DBA running scripts, and who owns each step. It should name the backup or snapshot taken immediately before the upgrade, the point at which that backup stops being a valid restore target, and whether the previous engine version can read rows the new version has written. Confirm the schema upgrade behavior, and any version mismatch errors, against the Flowable configuration docs rather than assuming it from the release notes. Test the rollback itself on a copy of production data, not only the forward upgrade.
Test suites should cover more than the happy path. Run deployments of every process, case and decision definition that is in use, and confirm that running instances continue after the engine restarts. Exercise timers and async jobs across at least two nodes so lock expiry and job pickup behave as they did before. Call the REST API from every client you operate, comparing response shapes and date handling. Finally, run each model that touches JSON variables or scripts, since those are where the Jackson 3 changes are most likely to surface. Record the results so you can judge a failed run against a known baseline.
What makes a Flowable 8 upgrade take longer
The table lists the factors that most often stretch a Flowable 7 to 8 upgrade and the direction each one pushes the effort. Use it to size your own estimate by counting each item in your estate before asking a partner or your team for a quote.
| Effort driver | Why it changes the work | Direction and how to keep it down |
|---|---|---|
| Number of process and CMMN models | Each deployed BPMN or CMMN model must load and run on the new engine, and models using changed expressions or features need review. | Rises with model count. Group models by domain so test runs can cover each group in turn. |
| Custom delegates and scripts using JSON | Delegates, listeners and expressions that read or write JSON move to Jackson 3, so every JSON touchpoint needs a check. | Rises with JSON-heavy code. Start with the jackson2 compatibility mode and inventory all JSON access first. |
| JUnit 3 and 4 test volume | Flowable 8 removes JUnit 3 and 4 support, so every process test must be rewritten before the suite can run. | Rises with the number of legacy tests. Convert tests to JUnit 5 in the 7.x line while the old suite still passes. |
| Custom identity services | Implementations of IdmIdentityService or overrides of IdmIdentityServiceImpl must be re-checked against the engine and Spring changes. | Rises with custom code depth. Confirm the interface behavior in the 8.0.0 release notes and retest group and user lookups. |
| REST API clients | Consumers of the REST API depend on request shapes, response formats and JSON handling, so each client needs regression checks. | Rises with the number of external callers. Keep a contract test suite that every client team runs before cutover. |
| Database types and environments | Each supported database type and each environment (development, test, staging, production) needs its own schema check and upgrade run. | Rises with every extra database and environment. Confirm your database type against the configuration docs and standardize environments where possible. |
| Running instances that must survive the change | Active process and case instances carry state and variables that must still work after the engine and Spring baseline change. | Rises with the volume of in-flight work. Plan a drain window or test migration of live instances against a production copy. |
| Application stack beyond Flowable | Spring Boot 4, Spring Framework 7 and Jakarta baseline changes can reach other libraries in the same application. | Rises with the number of shared dependencies. Map the full dependency tree before setting the upgrade order. |
Questions teams ask before upgrading to Flowable 8
How much does a Flowable 7 to 8 upgrade cost?
No fixed price applies, because the quote follows from the written scope. The main cost drivers are the number of Flowable applications, how many use BPMN, CMMN and DMN engines, how much custom code touches the engine (delegates, listeners, scripts and expressions), how many test suites must move off JUnit 3 or 4, and how many environments need upgrading. The work is mostly one-time, but ongoing support or upgrades after the move can be contracted as a retainer. Ask for a quote that lists each application, each upgrade step, the test work, environment changes, and what the client team will do itself so you can compare options like for like.
How long does the upgrade take?
Duration depends on scope more than on the version number. The Flowable 8.0.0 release was published on February 27, 2026, but your timeline depends on how many applications share the engine, how much code depends on the Spring Boot 4 and Jackson 3 changes, how large the test estate is, and how often your release train allows production changes. Plan the work in phases and ask any partner to show the phases, dependencies and the points where your own team must approve or test before the work can continue.
What must our team provide before the upgrade starts?
Expect to provide four things: read access to the repositories that hold process, case and decision models plus application code, non-production environments that match production closely enough to run the engines, representative test data that covers the process paths you rely on, and named owners who can make decisions on behavior changes. Also confirm who holds database access for schema changes and who signs off production releases. Missing owners are one of the most common causes of delay, so agree these roles in the written scope.
Can our internal team do the Flowable 8 upgrade alone?
Yes, if your team has Java and Spring experience, can work with the Flowable engine APIs, and can run the tests that prove behavior is unchanged. The upgrade requires Spring Framework 7 and Spring Boot 4, a Jackson 3 move with a Jackson 2 compatibility layer, and removal of JUnit 3 and 4 support, so the team needs to be comfortable with those changes. Many teams keep ownership internally and bring in an outside partner for specific gaps, such as test migration or database work. Compare the effort of your own team against the written scope before deciding.
Can we keep Spring Boot 3 and only upgrade Flowable?
No. The Flowable 8.0.0 release notes state that the upgrade moves to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. Applications on Spring Boot 3 must move their Spring Boot baseline along with the engine. Plan this as one change set, and check every other library on your classpath that depends on the Spring version, because those dependencies can block the move even when Flowable itself is ready.
How does the JUnit move affect our timing?
Flowable 8 removes support for JUnit 3 and 4, so any process test suite still on those versions must be rewritten before or alongside the engine upgrade. The effort depends on how many test classes use the old runner, how many use Flowable test support, and how many rely on deployment resources. Because tests are the evidence that process behavior is unchanged, plan the test move early, keep the suite green on the current version first, and treat the test rewrite as a prerequisite rather than a final step.
What does the Camunda or Activiti migration have to do with this upgrade?
They are separate projects, but they can overlap. Flowable's engineering blog states that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history, and offers the free Flowable LEAP tool to report ahead of time what a migration involves. If you are moving from Camunda 7 or Activiti, decide the target version first, because the Flowable 8 baseline changes the Spring and test stack that the migrated application will run on. Run the LEAP report early so the migration scope is visible before sequencing the two efforts.
When staying on Flowable 7.x for a while makes sense
Staying on Flowable 7.x is a reasonable decision for a team that cannot yet move its Spring Boot 3 application to a Spring Boot 4 and Jackson 3 baseline, provided the team treats that choice as a dated decision with an owner rather than a default. Flowable 8.0.0 has no backward compatibility for Spring Boot 3, so a 7.x application stays on Spring Boot 3, Spring Framework 6 and its current Jackson 2 usage until the application itself moves. In practice this means the team keeps its own dependency patching, base image and JDK updates on the 7.x line, and it does not pick up any change that depends on the Spring Boot 4 stack.
Before deciding, confirm the project's maintenance status for the 7.x line directly against the Flowable release notes and the flowable/flowable-engine repository, including whether security fixes are still published for 7.x and for how long. Record the answer, the date you checked it, and who checked it. Also confirm which 7.x patch release your application should be on, since a team that stays on 7.x often lags several minor releases. The sibling Flowable 7.1 to 7.2 upgrade is only a related step on the 7.x line and does not remove the need for the 8.0 decision, so keep it separate in your plan.
Write the decision down as a short record with four parts: the reason the application cannot move now, the 7.x version it is pinned to, the security and maintenance check you accepted, and a revisit trigger. Useful triggers include the end of support for 7.x, a required library or platform update that drops Spring Boot 3, a planned Jackson 3 migration for scripts and expressions, or a rewrite of the process test suite. Assign an owner and a review date, and make sure the test suite plan for the eventual JUnit 5 move is already scheduled so the staying period does not become indefinite.
How DeployOpen delivers the Flowable upgrade
The sequence below takes a Flowable 7.x estate to 8.0 in a controlled order, so that test coverage, Spring and Jackson changes, and engine upgrades each reach a verified state before the next one starts. Every step closes with a written output the client can check.
Inventory the application and its Flowable footprint
DeployOpen reviews the Spring Boot, Java and Flowable versions in use, the engine modules and starters, the REST clients, custom delegates and listeners, scripts and expressions, JSON variables, and the test suites. We also record which databases and identity services the engines use. The output is a written inventory with each item tagged by the upgrade change it touches, such as Spring Framework 7, Spring Boot 4, Jackson 3 or the JUnit 3 and 4 removal. The client confirms the inventory matches production before work continues.
Confirm the target baseline with the release notes
DeployOpen checks the Flowable 8.0.0 release notes against the inventory, noting the Spring Framework 7 and Spring Boot 4 baseline, the absence of Spring Boot 3 compatibility, the Jackson 3 default with its Jackson 2 compatibility layer, and the removal of JUnit 3 and 4 support. Where a dependency or behavior is unclear, we record the question and confirm it with the Flowable project or in a test build. The output is an agreed target matrix of Java, Spring, Jackson, JUnit and Flowable versions that the client signs off in the statement of work.
Move the test suites before the engine changes
Because JUnit 3 and 4 support is removed in 8.0, DeployOpen rewrites process tests on the current 7.x line first, moving them to JUnit 5 with the Flowable test extensions and keeping @Deployment resources intact. Tests are run against the 7.x application until they pass unchanged, so any later failure can be attributed to the upgrade rather than the test rewrite. The output is a green 7.x suite running on JUnit 5 and a list of tests that still depend on removed behavior.
Upgrade the application stack in a branch
DeployOpen moves the application to the Spring Boot 4 and Spring Framework 7 baseline in a separate branch, updating the Jakarta and dependency changes and resolving compile errors in custom delegates, listeners and configuration classes. Jackson usage in scripts, expressions and JSON variables is handled under the compatibility layer first, with the package and method changes tracked as a separate work item. The output is a building application on the target baseline with a documented list of every change made outside the Flowable engine itself.
Verify the engine behavior on a production-like copy
DeployOpen runs the upgraded application against a restored copy of the production database, covering process start and completion, timers and async jobs, CMMN case transitions, DMN decisions, REST responses and identity integration. We compare outputs against the 7.x baseline recorded earlier and log every difference. Database schema changes are applied to the copy and checked for errors before any real environment is touched. The output is a signed regression report with each difference either fixed or accepted by the client.
Sequence the rollout and schema changes
DeployOpen plans the cutover order for application nodes, the database schema upgrade and any client-side REST changes, using the async executor's lock behavior to avoid two versions processing the same jobs. The plan states which step is reversible, where backups are taken and who approves each stage. The output is a runbook with rollback points and named owners, reviewed by the client's operations team before the change window is scheduled.
Deploy, monitor and hand over
DeployOpen carries out the agreed rollout in the client's infrastructure, watches job execution, failed jobs, monitoring endpoints and logs during the first working period, and confirms the engines start cleanly on each node. We then deliver the updated documentation, test suite, runbook and change record. The output is a closed change with written handover and the client's acceptance of the production state.
Support the upgrade through optional retainers
After handover, the client can keep DeployOpen on a retainer for ongoing support, patch review, later Flowable releases and periodic regression runs against new versions. Retainer scope, response expectations and any reporting are agreed in writing, and the upgrade itself stays under a fixed-scope agreement with its own deliverables. The output is a support arrangement the client can start, pause or end on the terms in the contract.
