What an upgrade and support engagement covers
An upgrade to Flowable is never only a library bump. Flowable is an open source Java engine family for BPMN process execution, CMMN case management, DMN decision rules and the event registry, and you run it either embedded in your application or over its REST API. That means an upgrade touches your application code, your build, your database schema and your process models at the same time, and the engagement scope should name all four.
The current triggers are concrete. Flowable 8.0.0 was released on February 27, 2026, and its release notes describe a move to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. The default JSON library becomes Jackson 3, with a Jackson 2 compatibility layer, and support for JUnit 3 and 4 is removed. Teams that have fallen several releases behind, counting from 7.2.0 (August 21, 2025), face all of these changes at once. Ask your team to inventory every Spring Boot starter, Jackson-dependent class and JUnit test before estimating the work.
In short, teams with Java and Spring experience and an automated test suite that exercises their process models often upgrade in-house. Teams without regression tests for processes, or with thin Spring Boot skills, usually bring in a partner for the migration and set up support after go-live. Open source Flowable has no vendor support contract. Community help comes through the Flowable forum, so any response time you need after go-live must be bought from a partner under a written scope, not assumed from the open source project.
Decide before the quote: confirm which Flowable engines and REST services you run, which database and version they use, and whether your test suite can detect a changed process outcome. Those answers determine whether the engagement covers migration only, migration plus regression testing, or migration plus a support retainer.
What the work includes
A fixed-scope Flowable upgrade is split into assessment, build, test and cutover workstreams, followed by an optional support retainer. The items below show what is delivered, what each part depends on, and where the boundaries sit.
Dependency and API impact assessment
The assessment maps the move from Spring Boot 3 to Spring Boot 4 and Spring Framework 7, which Flowable 8.0.0 requires with no backward compatibility for Spring Boot 3. It also covers Jackson 3 as the default JSON library, the Jackson 2 compatibility layer, and removal of JUnit 3 and 4 support. The output is an impact report listing each affected class, configuration and test.
Java and Jakarta baseline check
Flowable 7 moved to Java 17, Spring Boot 3 and Jakarta EE, so the baseline check confirms the runtime Java version, servlet container and Jakarta namespace used by your application. Confirm the Java version required by Flowable 8.0.0 and Spring Boot 4 against the release notes before scheduling the work. Any gap becomes a prerequisite item in the scope.
Database schema upgrade scripts
Schema changes between Flowable releases are delivered as upgrade scripts for the database types your deployment uses, such as PostgreSQL, Oracle, MySQL or Microsoft SQL Server. Each script is tested on a copy of production data and paired with a rollback script that has been run in a rehearsal. Ask for the rollback test evidence, not only the script.
Process model regression testing
BPMN, CMMN and DMN models are executed on the upgraded engine against a database copy, comparing outcomes with the current production behavior. Tests cover in-flight process instances, timers, async jobs, decision tables and case plans that use custom Java delegates. The result is a test evidence pack that shows which models passed, which changed and why.
Cutover runbook
The cutover runbook sets out the ordered steps for stopping traffic, running schema scripts, deploying the upgraded engine and application, and verifying async executor and REST health. It names the go and no-go checks, the rollback trigger and the owner of each step. It is rehearsed before the production window so the timing reflects your environment.
Handover documentation
Handover covers the upgraded code and models, the impact report, the runbook and the monitoring setup, including the actuator endpoint for running processes. It records what changed in each dependency, what was deliberately left unchanged, and which items remain with your team. Ask for the handover format and the review session agreed in the written scope.
Post-go-live retainer scope
A support retainer covers monitoring, patch review, release tracking and incident response for the Flowable deployment after go-live. Each service is defined in the written agreement, including response expectations and which Flowable releases are tracked. It excludes new process development, custom delegates added after handover, and any change to licensed commercial Flowable products unless stated in scope.
What drives cost and duration
Each row names a factor that changes upgrade effort for a Flowable deployment, why it matters and how to keep it under control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Process, CMMN and DMN model count | Every BPMN, CMMN and DMN model must be deployed, read and regression tested against the new engine version, so the count sets the size of the test suite and the review backlog. | Inventory all models before scoping. Retire unused definitions and group the rest by business owner so testing can be staged. |
| Custom Java delegates, expressions and script tasks | Delegates and expressions call your own code and APIs. Changes to Spring, Jackson or Jakarta packages can break them, and script tasks need separate checks because they run as dynamic code. | Consolidate delegates into a shared service layer with unit tests. Ask for an inventory of every script task and expression and confirm which ones the upgrade touches. |
| Custom REST endpoints and event registry channels | Endpoints and channels depend on the REST and event registry APIs and on serialization. A JSON library change alters payloads that other systems consume. | Record current request and response samples and event payloads as contract tests. Confirm with consuming teams before the upgrade date is set. |
| Identity and security integrations | Integrations built on the IDM engine, a replaced IdmIdentityService or Spring Security configuration must be re-verified against the new Spring Security and Spring Boot baseline. | Document which identity service implementation is in use, including any LDAP reference code. Test sign-in, group mapping and REST authorization in a staging environment. |
| Database engine and version | Schema upgrades run against the chosen engine, and supported types include H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. MySQL versions below 5.6.4 lack millisecond precision, which can affect timer and history data. | Confirm the exact database version with your DBA and rehearse the schema upgrade on a copy of production. Plan the MySQL version check early if you run older releases. |
| Environments and node count | Each environment needs its own schema upgrade, configuration and smoke tests, and multi-node clusters need coordinated restarts so that async executor locks are not held by old nodes. | Use infrastructure as code so environments match. Agree a rolling or maintenance-window restart method with your platform team before testing begins. |
| In-flight process instance volume | Running instances, timers and history rows must still complete on the new version. Large volumes lengthen migration checks and raise the risk of stuck or failed jobs during cutover. | Ask for counts of active instances by definition. Drain or pause non-critical processes and confirm which instances continue on the old definition version. |
| Automated test coverage | Low coverage means each model and delegate is checked by hand. Strong automated tests shorten regression cycles and make failures easier to trace to a specific change. | Add tests for the highest-value process paths first. Freeze non-essential model changes during the upgrade window so test baselines stay valid. |
| Spring Boot 3 starters or the Flowable REST application | Flowable 8.0.0 has no backward compatibility for Spring Boot 3, so embedded applications on Spring Boot 3 need a migration to Spring Boot 4. The REST application route changes the deployment and configuration steps instead. | Confirm which packaging you run. Map starter and dependency versions against the Flowable 8.0.0 release notes before estimating the work. |
Upgrade and support phases
This sequence takes a Flowable deployment from an inventory of current use to a tested upgrade in production and a support plan that keeps it current after go-live.
Assess the current deployment
Your team or the partner inventories the dependency tree, Flowable API calls, Java delegates, execution and task listeners, custom REST endpoints and the database type in use. The output is a written inventory listing every item that touches a changed API or library, with an owner for each process model and delegate.
Set the target baseline
Decide the target Java and Jakarta versions, the Spring Boot line and the move to Jackson 3, using the Flowable 8.0.0 release notes and the Spring Boot documentation to confirm the exact Java requirement. Confirm that the Jackson 2 compatibility layer covers your custom serializers. The output is a signed baseline record that the build, runtime images and support plan will follow.
Change code and configuration
Update Java delegates, listeners, custom endpoints and Spring configuration to the new APIs, replace any JUnit 3 or 4 tests, and align BPMN XML extensions with the new engine. Datasource and async executor settings are reviewed in the same pass. The output is a build that compiles, passes unit tests and is checked against the assessment inventory.
Upgrade the schema on a production copy
Run the database schema upgrade against a restored copy of production, starting from the exact Flowable version your instance runs today. Take and verify a backup first, then compare active process instances, timers, jobs and history tables before and after the run. The output is a migration log and row-count comparison that the team reviews before production.
Regression test every deployed process
Run every deployed BPMN process, CMMN case and DMN decision table against recorded test inputs and expected outcomes, including timers, boundary events, error paths and decision tables with their hit policies. Record pass or fail results per model and version. The output is a regression report covering each deployed definition, with failures fixed or accepted in writing by the process owner.
Roll out through staged environments
Deploy the upgraded build to development, test and pre-production in order, checking each environment against the regression suite and monitoring. Confirm that async jobs are picked up correctly across nodes and that the Flowable monitoring endpoint reports running processes. The output is a signed checklist for each stage, completed before production approval.
Cut over and hand over support
Schedule the production cutover with a tested rollback path that restores the previous build and the pre-upgrade database backup, and watch running instances, jobs and error rates through the window. Afterward, transfer runbooks, monitoring, on-call contacts and the support plan, whether run internally or under a retainer. The output is a closed cutover record and an accepted handover.
What teams keep in-house and what they outsource
This table lists each Flowable upgrade work area, who usually owns it, and the skills it needs, so you can see where a partner adds capacity and where your own owners must stay accountable.
| Work area | Usually owned by | Skills each needs |
|---|---|---|
| Dependency and API impact analysis | Internal platform or engineering lead, with partner review | Java and Spring, Flowable Java and REST API knowledge, Maven dependency review |
| Spring Boot and Jackson code changes | Application development team, with partner help on upgrade-specific fixes | Java and Spring Boot 4, Jackson 3 and its Jackson 2 compatibility layer, test code moved off JUnit 3 and 4 |
| Database schema migration | Database administrator with the engine team | Database administration on your production database type, change control, rollback scripts |
| Process model regression testing | Process analysts and developers, with business testers | BPMN, CMMN and DMN modeling knowledge, test scenario design, process analysis |
| Performance checks on the async executor | Platform team, with partner load testing | Load testing, JVM and thread pool tuning, reading job and lock tables in the database |
| Cutover and rollback | Operations team, using a runbook agreed with the partner | CI/CD pipelines, change management, database and service restart procedures |
| Post-go-live monitoring and patch review | Operations and security teams, with engine owners | Monitoring through the Spring Boot actuator endpoint, log analysis, security patch assessment |
| Ongoing release tracking | Platform lead, or a partner under a support retainer | Reading release notes, dependency vulnerability scanning, planning upgrade windows |
| Business outcome validation | Process owners in each business area, even when a partner runs the upgrade | Process knowledge, acceptance criteria, sign-off on case and task results |
What usually goes wrong
Most Flowable upgrade problems are predictable and avoidable. The six failures below come up repeatedly in dependency, serialization, testing, data and cluster work, and each has a check that belongs in the plan before any code changes.
Upgrading Spring Boot before checking starters
Moving an application to Spring Boot 4 without confirming the Flowable starter versions and Spring Framework 7 compatibility is a common first mistake. Flowable 8.0.0 dropped support for Spring Boot 3, so a partial upgrade can fail at startup or in autoconfiguration. Check the release notes and starter matrix for every Flowable artifact before changing the parent POM.
Assuming Jackson 3 matches Jackson 2
Flowable 8.0.0 uses Jackson 3 as its default JSON library and ships a Jackson 2 compatibility layer. That layer reduces the change but may not remove it, so custom serializers, mixins, date handling and REST payloads can change shape or behavior. Capture sample requests and responses from the current system and compare them against the upgraded build before go-live.
Deploying models without regression tests
Changed expressions, delegate beans and listener logic can break silently when a process model is redeployed on a new engine version. Without regression tests that start real instances, drive them through every path and assert on variables and outcomes, the first sign of breakage is a stuck or misrouted case in production. Build the suite against the current version first, then run it on the upgraded engine.
Running schema upgrades without a tested backup
Running the schema upgrade against a database that holds in-flight instances is high-risk when no backup has been restored and verified. Flowable keeps running process, case and job state in the database, so a failed migration can leave work half-moved. Take a backup, restore it to a separate environment, run the upgrade there, and confirm that open instances and timers still advance before touching production.
Skipping the async executor check on multiple nodes
The async executor coordinates nodes through lock owners and lock expiration times stored in the database. If the upgraded version changes job handling and nodes run mixed versions or differing executor settings, timers and async jobs can be duplicated, delayed or left locked. Test expired lock recovery with at least two nodes and confirm that jobs are picked up by a surviving node.
Keeping JUnit 3 or 4 in the test suite
Flowable 8.0.0 removed support for JUnit 3 and 4, so test classes and runners written for them will not run on the new baseline. Teams often discover this late, after the production code compiles, and lose the regression safety net they need for the other checks. Inventory test dependencies and migrate to JUnit 5 before the engine upgrade, so the regression suite is running when the upgrade starts.
How the work differs by starting point
Your application imports the Flowable engines through Spring Boot starters and runs on Spring Boot 3. The move to 8.0 is a framework move as well as an engine move, because the 8.0 release notes describe Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3.
- Plan the framework move with the engine bump. Spring Boot 4 and Spring Framework 7 change together with Flowable, so one branch carries both.
- Check starter and property names against the Flowable Spring Boot documentation for 8.0.
- Review custom beans, delegates and listeners that use Jackson 2 APIs, because Jackson 3 is the default JSON library and a Jackson 2 compatibility layer is provided.
- Replace JUnit 3 and 4 tests, which 8.0 no longer supports.
- Confirm the /actuator/flowable endpoint and your monitoring dashboards after the upgrade.
Engines embedded as JARs in plain Java SE or in a servlet container such as Tomcat or Jetty have no framework to carry the upgrade. The work sits in your bootstrap code, dependency management and datasource wiring.
- Inventory the bootstrap code that builds the engine configuration and the connection pool.
- Confirm the Java and Jakarta baselines for 8.0 in the release notes before changing the build. Version 7 moved to Java 17 and Jakarta EE, so confirm your runtime meets what 8.0 requires.
- Check Jackson usage in your own delegates, listeners and REST clients.
- Assign ownership of dependency alignment, since no framework resolves transitive version conflicts for you.
- Test redeploys on the servlet container to catch classloader leaks and stale engine instances.
The Flowable REST application runs as its own service and other systems call it over HTTP. Upgrading means moving two things together: the service and every client that depends on its API.
- Diff the REST API contract between your current version and 8.0 for every endpoint your clients call.
- Inventory the clients, including business applications, scripts and integrations, and name an owner for each.
- Confirm JSON payload behavior for dates, nulls and numeric fields, since the Jackson change can affect serialization. Verify exact behavior in the vendor documentation and in your own contract tests.
- Agree whether old and new clients coexist during the window or whether writes are frozen.
- Run contract tests against a staging instance before cutover.
Several engine nodes share one database, so the schema upgrade and the restart order decide whether jobs keep running during the change.
- Confirm the schema upgrade path from your current version to 8.0, and whether it must complete before any node starts on new code.
- Plan the rolling restart order so that mixed versions never run against the same tables in a way the release notes do not cover.
- Review async executor settings. Lock owners and lock expiration decide how quickly another node picks up a job from a stopped node. Test this during the upgrade rehearsal.
- Decide how timers are handled during the window, such as draining nodes or pausing jobs, and confirm the effect in a test run.
- Back up the database and rehearse the rollback, including the schema, before the production window.
In an air-gapped or regulated environment, dependency mirroring and change approval often set the pace more than the engine work does. Confirm these points before the technical plan is fixed.
- Mirror all Flowable artifacts and the transitive Spring, Jackson and database driver dependencies for 8.0 into your internal repository before work starts.
- Ask your change board which approvers are needed, what evidence they require and how long their cycle takes. DeployOpen does not set those timelines.
- Retain release notes and regression evidence as change records so the approval trail is complete.
- Confirm how dependency security updates will reach the mirror after go-live and who approves them.
- Ask whether database drivers and base images need separate approval from the application change.
What you need to provide
Before DeployOpen can scope an upgrade of Flowable, the client has to supply a set of inputs and name the people who will decide. Source access to the application repository and build pipeline comes first, because the upgrade changes dependencies, build plugins and test harnesses. Alongside it, provide a copy of the production database with its current Flowable schema version, so the schema upgrade can be rehearsed against real data rather than a fresh install.
Provide a list of every deployed BPMN process, CMMN case and DMN decision model, with an owner for each. Pair that with an inventory of delegates, listeners, expressions, script tasks and custom REST endpoints, since these are where the 7.x to 8.0 changes to Spring Boot 4 and Jackson 3 are most likely to break behavior. Also supply a test environment that matches production in database type, Java runtime, identity configuration and network path. Share identity and security configuration, including how the REST API is authenticated, and the change windows and approvers who will sign off each cutover.
Two roles are the ones most often missing. The first is a named technical owner who can answer questions about the codebase, approve dependency changes and decide when a regression is acceptable. The second is a process owner who can confirm, for each model, that the expected outcome after the upgrade matches what the business needs. Without the process owner, regression tests check only what engineers remember, and business sign-off stalls at the end. Name both people, plus an on-call contact, before scoping starts.
Frequently asked questions
What drives the cost of a Flowable upgrade and how do I get a quote?
The cost depends on the size of the change, the number of process, case and decision models in use, how many custom Java delegates and integrations you run, and how much regression testing is needed before cutover. A move from 7.x to 8.0 touches Spring Boot, Jackson and test frameworks, so any custom code built on those layers adds effort. Most engagements are fixed-scope, so the quote follows a written scope that lists the models, integrations, environments and deliverables. Ask for the scope to name each assumption, the testing approach and what is one-time versus recurring support.
How long does a Flowable upgrade take?
Duration depends mainly on how many models and integrations are affected and how much of the test suite must be built or rewritten. Flowable 8.0.0 was released on February 27, 2026, according to the flowable-engine GitHub releases page, and its move to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3 means application code and build files need review. Ask your partner for a timeline tied to the written scope, and confirm which environments and approval gates it includes.
Can our internal team upgrade Flowable without a partner?
Yes, if your team has solid Spring Boot skills, experience with the Flowable APIs and a reliable regression testing practice for process models. The work involves updating dependencies, reviewing Jackson 3 changes, removing JUnit 3 and 4 tests, checking database schema upgrades and replaying representative process instances. Teams without automated regression coverage usually find that building it is the largest task. A partner can fill gaps in testing, cutover planning or specific skills while your engineers keep ownership.
What does the upgrade need from our team?
You need access to source code, build pipelines and non-production environments, plus a copy of the production database for rehearsal. Name an owner for each business process, someone who can confirm expected outcomes, and a platform owner for deployment. Agree on change windows early, since schema upgrades and cutover often need a planned outage or a controlled maintenance period. Also confirm who approves production changes and who can access logs during the rollout.
Does Flowable open source need a license fee, and what about commercial products?
The open source Flowable engines are licensed under Apache 2.0, so the engines themselves carry no license fee. Commercial products such as Flowable Work, Engage, Orchestrate and Design are separate offerings built on the same engines and carry their own terms. Open source users get a community forum, while professional services and partner support are offered separately. Confirm the license terms of every component you run, including any third-party drivers or connectors, before you finalize the budget.
What happens to our process models if an upgrade fails midway?
The upgrade plan should include a rollback path built on a backup that has been restored and tested before cutover. Restore the database and previous application version, then confirm that in-flight process instances, timers and jobs resume correctly. Flowable's async executor relies on lock owners and expiry times stored in the database, so verify job state after a restore. Ask your partner to document the rollback steps, the decision point for invoking them and who signs off on the decision.
How DeployOpen delivers Flowable upgrades and support
DeployOpen plans and carries out Flowable upgrades inside infrastructure you control, from the scoped baseline through regression testing and handover. Engagements are fixed-scope, with ongoing support available as a retainer once the work is live.
How we scope
- Inventory the Flowable engines, REST application and Spring Boot starters your processes depend on, with their current versions.
- Map each BPMN, CMMN and DMN model against the 8.0.0 changes, including Spring Boot 4, Jackson 3 and removed JUnit 3 and 4 support.
- Agree in writing which database, Java, identity and integration components are in scope, and which decisions stay with your team.
How we build
- Run the database schema upgrade on a copy of production data first, and confirm the migration result against the target database type.
- Port custom Java delegates, listeners and Jackson-dependent code to the new baselines, then repeat the test suite until it passes.
- Rerun process and case regression tests against representative instances, including timers and asynchronous jobs under the async executor.
How we hand over
- Deliver a written record of the versions, configuration changes, schema steps and rollback steps used for the upgrade.
- Document the regression test suite and explain how your team runs it before each future Flowable release.
- Walk your engineers through monitoring via the Spring Boot actuator endpoint and the job and lock behavior they should watch after go-live.
How we support
- Offer post-go-live support as a retainer, scoped in writing, covering incidents, patching and upgrades to later Flowable releases.
- Review new Flowable releases and dependency updates against your deployed processes before recommending a change.
- Agree response expectations and service terms in the written retainer, and confirm them with your team before work starts.
