Why a Flowable 7.1 to 7.2 upgrade is a contained move and what it still needs
A Flowable 7.1 to 7.2 upgrade is a contained move, but it is not a dependency bump you can merge unreviewed. If your Java stack runs Flowable 7.1 engines, the release facts show that 7.2.0 changes REST API date responses to UTC, deprecates JUnit 3, JUnit 4 and Joda Time support, and upgrades Spring Boot to 3.5.4. Those changes touch API behavior and build dependencies more than the Java and Jakarta baseline, so the work is mainly verification of your own code and clients. The supported path is 7.1 to 7.2 now. Flowable 8.0.0 is a separate, later upgrade that moves to Spring Framework 7 and Spring Boot 4, so do not fold it into this change.
Start by checking the 7.2.0 release notes against what your application actually uses. Confirm which of your engines and starters you run (BPMN, CMMN, DMN, event registry, REST), whether any service parses date fields returned by the REST API, and whether any test code depends on JUnit 4 or Joda Time. Ask your team to list every consumer of the REST API, since a change in date handling is most likely to break a client that compares timestamps against local time. Confirm with Flowable the exact deprecation timeline for JUnit and Joda Time before you plan any test rewrite.
The remaining work sits in your environment, not in the engine jar. Plan a regression run against the Spring Boot 3.5.4 build, and confirm that your database type, from the supported list in the Flowable configuration docs, still behaves the same under the new dependency set. Decide who owns sign-off for API consumers and whether a rollback path exists for the schema and application together. Those decisions determine the duration more than the version number does.
What changes in 7.2 and what each change means for your team
This table compares each change in the Flowable 7.2.0 release notes with the work it creates for your application, tests and integrations. Read each row as a checklist item: the impact column shows who is affected, and the action column shows what to verify before you upgrade. The main takeaway is that the REST date change is the one most likely to break running systems, while the dependency and test changes mainly affect build and test work.
| Change in 7.2 | Impact on your team | Action needed |
|---|---|---|
| REST API date responses switched to UTC | Clients that parse timestamps from the REST API may read different times if they assumed the server time zone. | Confirm how each client parses date fields, then run comparison tests against a 7.1 baseline before cutover. |
| Spring Boot upgraded to 3.5.4 | Starters, parent POMs and dependency pins that assume the 3.3.x line may conflict with the new baseline. | Review Spring Boot and Spring dependency overrides in your build, and align any custom starters with 3.5.4. |
| JUnit 3 and JUnit 4 support deprecated | Test suites built on JUnit 3 or 4 keep working in 7.2 but carry a deprecation signal for the team. | Inventory tests that use JUnit 3 or 4 so the move to JUnit 5 can be planned before 8.0.0 removes that support. |
| Joda Time support deprecated | Any custom delegates, expressions or variables that use Joda Time types may need replacement before a later major release. | Search your process scripts, expressions and Java code for Joda Time usage and plan a move to java.time. |
| Coming from earlier 7.x lines | The 7.1.0 removal of Liquibase from the App, CMMN, DMN and event registry engines, and the Spring Boot 3.3.4 baseline, apply only if you are moving from an earlier 7.x release. | If you already run 7.1, skip this row. If you are on 7.0, review the 7.1 release notes for schema and Liquibase changes first. |
How the UTC change in REST date responses breaks clients
Flowable 7.2.0 changes REST API date responses to UTC instead of the server time zone, so any client that read those timestamps as local time can now get shifted values without a single line of its own code changing. The risk is greatest where a consumer stores dates with a fixed offset, parses them with a parser that assumes the server zone, or compares them with dates generated on another system. Batch jobs that select records by a date window are the most likely to return different rows after the upgrade, and they often fail quietly. Confirm the exact response format for each date field against the Flowable 7.2.0 release notes and against responses from your own test environment, since the release notes are the reference for what changed.
Start with an inventory of every consumer of the Flowable REST API, including scheduled reports, reconciliation jobs, front ends, partner integrations and scripts run by operations staff. For each consumer, record which endpoints it calls, which date fields it reads or writes, and how it converts those values. Then capture sample payloads from the current 7.1 deployment for the same requests and compare them with payloads from a 7.2 test environment built from the same data. Differences in offset notation or in the instant represented are the signals to look for. Contract tests that assert on date fields, and tests that filter by a date range, give the clearest evidence of a change in behavior.
Decide, for each affected consumer, whether to change the client to parse UTC explicitly, to convert values at an adapter layer, or to keep a server-side setting that restores the previous behavior if one exists in your version. Ask the Flowable team or your partner to confirm that option in writing before you rely on it. Plan a regression run that replays the sample payloads and the batch windows around the cutover, and include daylight saving boundaries in the test data. Assign an owner for each consumer so that a changed report or missed job has a clear route to a fix.
What to prepare before touching the 7.2 engine
Most failed Flowable upgrades are discovered after the engine is already running, not during the version change itself. The six items below cover data, code, client contracts and tests, so each can be checked before anyone edits a dependency version. Work through them in order, because the staging environment depends on the backup and the inventories.
Database backup and restore test
Take a full backup of the Flowable schema and prove you can restore it into a scratch database before the upgrade. Confirm the backup covers runtime, history and identity tables and that the restore completes with the same row counts. Record the database type and version, since the Flowable configuration docs list the supported types (H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server) and your restore procedure must match the one you run. Ask your DBA who owns the restore step.
Custom code and overrides inventory
List every Java class your application registers with the engine: custom delegates, execution and task listeners, event listeners, identity service overrides and script tasks. Flowable's identity management can be replaced by overriding IdmIdentityServiceImpl or implementing IdmIdentityService, so include any LDAP or custom identity service in this list. Mark which items depend on Spring Framework APIs or Jackson, because those are the areas most likely to need changes when the Spring Boot baseline moves to 3.5.4.
REST client inventory and date handling
Identify every system that calls the Flowable REST API and what it does with date fields. Version 7.2.0 changed REST date responses to UTC instead of server time zone, so any client that parses dates as local time, compares them to stored values or displays them without conversion will show different results. Ask each client owner to confirm how they read timestamps and to test against a staging instance before cutover.
Test suite baseline with JUnit and Joda Time
Run the full process and integration test suite on the current 7.1 version and save the results as a baseline. Search the codebase for JUnit 4 imports and for Joda Time usage, since 7.2.0 deprecates JUnit 3, JUnit 4 and Joda Time support ahead of version 8. Flag tests that depend on time zone or timestamp precision, because the UTC change can alter their expected values. Keep the baseline so that failures after the upgrade can be traced to a specific change.
Staging environment matching production
Build a staging environment that uses the same database type, major version and connection settings as production, and load a recent copy of production data. Testing on H2 or a different database engine will miss schema and precision differences, such as the MySQL millisecond precision limit for versions below 5.6.4. Confirm with your platform team who can provision the environment and how long a refresh from production takes in your own setup.
Dependency and build pinning
Record the current Flowable, Spring Boot, Jackson and test library versions in your build file and in a dependency lock or bill of materials. Check whether any other library in your stack pulls in Joda Time or JUnit 4 transitively, because those versions will appear in the dependency tree after the upgrade. Keep a rollback build that runs against the 7.1 artifacts so the release can be reverted without rebuilding from source.
Upgrade sequence from 7.1 to 7.2 with checks and rollback points
This sequence moves a Flowable 7.1 application to 7.2 in a controlled order, so each change has a verified state and a point to return to before production is touched. It ends with the upgraded engine running in production under monitoring, with the rollback path still defined.
Freeze changes and back up the database
The application team stops merging changes to the Flowable models, delegates and REST clients for the upgrade window, and the DBA takes a full backup of the Flowable schema and the application database. Record the current Flowable and Spring Boot versions, the deployed process and case definitions, and the running instance counts, so you can compare them after the change. The step is done when the backup restore has been tested on a copy and the baseline record is stored with the change ticket. Rollback point: the restored backup and the prior build artifact.
Upgrade the dependencies in a branch
A developer creates a branch and moves the Flowable 7.2.0 modules and the Spring Boot 3.5.4 parent in the build file, following the 7.2.0 release notes for the exact artifact changes. Review the dependency tree for conflicts with libraries that the application pins, and confirm that the build compiles without relying on the Liquibase-related or Joda Time code paths that the release notes mark as changed or deprecated. The step is done when the branch builds cleanly in continuous integration. Rollback point: the unmerged branch and the tagged 7.1 release.
Run the existing test suite
The team runs the full unit and integration suite against the upgraded branch, including process tests that deploy BPMN, CMMN and DMN resources. Failures are sorted into engine behavior changes, Spring Boot configuration changes and test-harness issues, since each has a different fix. Deprecated JUnit 4 and Joda Time usage is logged as a follow-up for the Flowable 8 work rather than fixed here unless it blocks the build. The step is done when the suite is green or every failure has a recorded cause and owner. Rollback point: the 7.1 branch remains the release candidate until this gate passes.
Verify REST date responses against contract tests
Because 7.2.0 returns REST API date values in UTC rather than the server time zone, the QA team runs the contract tests for every client of the REST API and compares date fields in responses from 7.1 and 7.2 for the same stored instances. Check how each consuming system parses timestamps, including reports, task lists and any batch jobs that filter by date. Where a client assumed server local time, agree the fix with that client's owner before release. The step is done when every date-bearing endpoint in the contract suite passes and each client owner has signed off on the time zone behavior. Rollback point: a build that keeps the 7.1 response format through the client adapter, if a consumer cannot change in time.
Deploy the build to staging
The release team deploys the upgraded build to a staging environment that uses a copy of production data and the same database type, container image and configuration as production. The engine starts against the migrated or unchanged schema, and the operator confirms the startup logs show no version mismatch or schema errors. Confirm the staging database backend is one of the supported types in the configuration documentation. The step is done when staging starts cleanly and the baseline counts match the pre-upgrade record. Rollback point: staging is reset from the backup copy, which proves the restore path before production.
Run process and REST regression checks
Testers start new process and case instances, complete user tasks, trigger timers and asynchronous jobs, evaluate DMN decisions and call the REST endpoints used by front ends and integrations. Include a check that the async executor picks up jobs and that the lock handling works across two or more nodes if you run a cluster. Compare the results with the 7.1 baseline for the same scenarios. The step is done when the agreed scenario list passes and every difference has an accepted explanation. Rollback point: the staging reset and the decision to keep production on 7.1 if a scenario fails without a fix.
Deploy to production with a rollback point
The operations team schedules the change, drains or pauses traffic according to the runbook, and deploys the 7.2 build alongside a retained copy of the 7.1 artifact and a verified backup taken immediately before the change. The team agrees the criteria for rollback in advance, such as startup failure, failed core scenarios or client errors on date fields. The step is done when the production engine starts, the smoke scenarios pass, and the rollback procedure has been written down and is reachable by the on-call team. Rollback point: redeploy the 7.1 artifact, and restore the backup only if the schema or data has changed in a way the old engine cannot read.
Monitor the actuator endpoint after release
After release, the operators watch the Flowable actuator endpoint at /actuator/flowable, which reports on running processes, and compare its figures with the pre-upgrade baseline. They also watch failed jobs, error logs and client error rates for date-related parsing problems. Monitoring continues through the agreed observation period, and the team records any anomaly against the change ticket. The step is done when the operators confirm the figures are in line with the baseline and the change is formally closed. Rollback point: the 7.1 artifact remains available until the closure review, and the decision to roll back follows the criteria set before deployment.
Regression testing and rollback options for REST and engine behavior
If your systems call the Flowable REST API, the most visible change in 7.2.0 is that date values in REST responses are now expressed in UTC rather than the server time zone. Any client that parsed those timestamps as local time, or that compared them with values stored in another system, can show shifted times without any error. Regression testing for this group focuses on the response contract and on fixtures that make time handling deterministic.
- Contract tests on date fields: Capture responses from 7.1 and 7.2 for the same process instances and tasks, then compare every date field for offset and format.
- Timezone-fixed fixtures: Run the test environment with a fixed server time zone and pin the client test runner to UTC, so a shift shows up as a failed assertion.
- Client parsing review: Check that each consumer converts timestamps explicitly, including reports, SLA calculations and audit exports.
- Downstream data comparison: Compare values written to data stores or sent to partner systems before and after the upgrade.
- Rollback: Keep the previous REST application build deployable behind the same route, and roll back the client code only if it depends on the old date behavior.
Confirm the full list of changed REST responses in the 7.2.0 release notes against the endpoints your clients actually use.
If your application embeds the engines as Java libraries or Spring Boot starters, the regression risk sits in deployment and runtime behavior rather than in the REST contract. Process definitions, running instances and timers must behave the same after the engine version changes. Spring Boot moves to 3.5.4 in 7.2.0, so dependency resolution and application startup also need checks.
- Deployment tests: Deploy every BPMN, CMMN and DMN resource to a clean schema and confirm that each definition version is registered as expected.
- Running instance tests: Start instances on 7.1, stop the application, and resume them on 7.2 to confirm that tasks, timers and variables continue correctly.
- Async job checks: Confirm that timers and asynchronous jobs fire and that failed jobs can be retried after the upgrade.
- Startup and actuator checks: Verify that the application starts cleanly with the Spring Boot 3.5.4 dependency set and that the flowable actuator endpoint reports healthy engines.
- Rollback: Keep the 7.1 artifact and its configuration available. Rolling back the binary is safe only before the database schema has been upgraded or for changes you have confirmed are backward compatible.
Rollback past a schema change requires your database plan: take a verified backup before the first start on 7.2, and agree with your DBA who owns the reverse path. Confirm the schema behavior in the 7.2 documentation before you rely on it.
Flowable 7.2.0 deprecates support for JUnit 3, JUnit 4 and Joda Time. The engine still runs on these, so nothing breaks on the day of the upgrade, but test suites that depend on them will need work before Flowable 8, which removes JUnit 3 and 4 support. This group should treat 7.2 as the point to start the move, not the point at which tests are complete.
- Inventory of deprecated usage: Search test and main source trees for JUnit 3 and 4 imports, runners and rules, and for Joda Time types in date handling.
- Joda Time replacement: Replace Joda Time with the java.time types your code already uses, and rerun date-sensitive tests against the UTC behavior described above.
- Parallel test runs: Keep the existing suite green on 7.2 while new JUnit 5 tests are added beside it, so coverage does not drop during the transition.
- Deprecation warnings: Make sure the build reports deprecation warnings for the affected APIs and track them as a backlog item.
- Rollback: Test code changes are reverted through source control. Keep the test branch that pins 7.1 available until the suite passes on 7.2.
See the separate guide on moving Flowable process tests from JUnit 4 to JUnit 5 for the rewrite steps, and confirm the exact deprecation list in the 7.2.0 release notes.
What makes a Flowable 7.2 upgrade longer or shorter
This table lists the factors that most change the effort of moving from Flowable 7.1 to 7.2, and what to check for each. Read it before scoping, because the upgrade is short when the affected surface is small and grows with each REST consumer, Joda Time usage or JUnit 4 test that must be reviewed. Most of the risk sits in clients that parse dates, so inventory those first.
| Driver | Effect on effort | What to check |
|---|---|---|
| REST consumers that parse dates | Each client that reads date fields must handle UTC responses, which can raise effort sharply when there are many | List every client of the REST API and confirm how each parses timestamps |
| Custom Java delegates and scripts | More delegates and scripts mean more code paths to review and retest after the change | Count delegates, listeners and script tasks that read or write date values |
| Use of Joda Time | Code that still depends on Joda Time must be reviewed, since support is deprecated in 7.2 ahead of version 8 | Search dependencies and source for Joda Time imports and transitive uses |
| JUnit 4 test volume | A large JUnit 4 suite adds work now and sets up the later move before Flowable 8 | Count test classes and rules that use JUnit 3 or 4 and note the deprecation |
| Identity service overrides | Custom IdmIdentityService implementations need regression runs against the new Spring Boot 3.5 baseline | Confirm which overrides exist and whether an LDAP or custom service is in use |
| Database type and size | Engine schema, driver versions and data volume affect rehearsal time and rollback planning | Confirm the database product, version and largest history tables before scheduling |
| Number of environments | Each environment needs its own upgrade, verification and sign-off, which multiplies effort | Ask whether development, test, staging and production share a release path |
Questions teams ask before upgrading Flowable 7.1 to 7.2
What does a Flowable 7.1 to 7.2 upgrade cost, and what drives the quote?
The cost depends on the written scope, not on the version number alone. The main drivers are how many applications and engine deployments you run, how many REST API clients read date values, how much of your test suite needs changes, and whether your build pulls in Spring Boot starters that move with the 7.2 baseline. Each component you change adds review and test work, and each client team you need to coordinate adds coordination effort. Some costs are one-time, such as the upgrade and regression run. Others recur if you later choose a retainer for upgrades or testing. Ask any provider for a quote that lists the applications in scope, the REST clients to be checked, the test environments, and what is excluded, such as a later move to Flowable 8.0.0. DeployOpen does not publish a price list. A quote follows from the written scope.
How long does a Flowable 7.1 to 7.2 upgrade take?
Duration depends on scope, so no fixed figure applies to every estate. A single Spring Boot application with a small REST surface and a solid test suite moves faster than several applications sharing one engine version, with external clients that parse timestamps. The critical path is usually the regression check for REST API consumers, because date responses now use UTC instead of server time, and any client that assumed local time must be found and verified before release. Build the plan around environment availability, change windows, and the time your client teams need to confirm their parsers. Ask for a timeline that names each phase and the dependencies between them.
What does the internal team need to provide for the upgrade?
The internal team provides the knowledge of the system and the access needed to test it. In practice that means a named owner for each application, access to source code and build pipelines, non-production databases that resemble production, and a list of every system that calls the Flowable REST API. Someone must also decide how dates are consumed downstream and approve changes to shared contracts. Product owners need to schedule acceptance testing against real business processes. Expect the team to review the deprecation changes in the 7.2.0 release notes and confirm which of their tests still rely on JUnit 3, JUnit 4 or Joda Time, since those support changes affect future work even though they are deprecations in this release.
Can our own team perform the Flowable 7.1 to 7.2 upgrade alone?
Yes, a team with Java, Spring Boot and Flowable experience can usually perform this upgrade without an outside partner, provided it has the capacity and a clear test plan. The work is smaller than a major version change because it stays within the Spring Boot 3 line. The risks are in the details: REST date handling, dependency conflicts, and client regressions that only appear in production-like data. Teams that lack a regression suite for the REST API, or that have few people who know the engine configuration, often benefit from an external review or a fixed-scope engagement. Decide based on the test coverage you already have and the number of people who can own each step.
Must we move to Flowable 7.2 before upgrading to 8.0.0?
Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, according to the 8.0.0 release notes. Those release notes do not state that 7.2 is a required intermediate step, so confirm the path with the project and your own dependency analysis before you plan. Moving to 7.2 first has a practical benefit: it deprecates JUnit 3, JUnit 4 and Joda Time support while the code is still on the Spring Boot 3 line, which gives your team time to rewrite tests and remove Joda Time usage. Your decision depends on how far your application is from the Spring Boot 4 baseline and on how many test suites still use JUnit 4. A separate planning page covers the Flowable 7 to 8 upgrade.
What does a rollback look like after the 7.2 deployment?
Rollback means returning the application to the 7.1 build and confirming that the database state still works with it. Before deployment, take a database backup and keep the 7.1 artifacts available so the previous version can be redeployed quickly. Check whether the 7.2 release changed the database schema for your engine configuration, and if it did, confirm that the 7.1 version can read the result. Also check that no clients were updated to rely on UTC date formats during the window, because clients that already changed may need a coordinated rollback. Rehearse this in a non-production environment and write the decision criteria down before the change window opens. Ask any partner to document rollback steps as part of the deliverables.
How DeployOpen scopes and delivers a Flowable upgrade
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Flowable 7.1 to 7.2 upgrade is scoped against your running engines, your REST API clients and your database before any code changes. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every Flowable engine, starter and REST client in use, including which BPMN, CMMN and DMN engines your applications load
- Identify which REST responses carry dates that will change to UTC and which consumers parse them
- Record Spring Boot 3.3 and JUnit or Joda Time dependencies that must be reviewed before the move to 7.2
How we build
- Upgrade Flowable and Spring Boot 3.5.4 in a branch, then run the existing process and case test suites against the new baseline
- Adjust date parsing, time zone handling and query code for the REST API changes in a documented change list
- Remove or replace deprecated JUnit 3 and 4 and Joda Time usage where the scope requires it, with the decision recorded
How we hand over
- Deliver a regression check suite for REST API clients covering date fields, variable handling and query results
- Document the upgrade steps, the rollback path and the database settings checked against the supported database list
- Walk your engineers through the change list, the test evidence and the deprecation items to plan for Flowable 8
How we support
- Run post-upgrade monitoring checks on job execution and the Flowable actuator endpoint in your environment
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to keep the baseline current
- Confirm with your team which Flowable 8 sibling work, such as the JUnit 5 move, should follow this upgrade
