Why Flowable Spring Boot integration is more than adding a starter
The official Flowable starters make the first working embedded engine straightforward, but the datasource, deployment shape, async executor and version choices decide whether it runs reliably in production. A Java team that needs process, case or decision logic inside an existing Spring Boot 4 application will usually get the engine to start quickly. The harder work comes later, when the engine shares a database with other workloads, runs on more than one node, and has to be upgraded without interrupting the business processes it supports.
Version choice comes first because it sets every other decision. Flowable 8.0.0, released on February 27, 2026, moves to Spring Framework 7 and Spring Boot 4, and its release notes state there is no backward compatibility for Spring Boot 3. An application still on Spring Boot 3 cannot simply change the Flowable version. It needs a framework upgrade first, or it stays on the 7.x line. Confirm the starter coordinates for your Spring Boot version in the Flowable Spring Boot documentation and the 8.0.0 release notes before the first build, because the starter artifacts change with the major version.
Jackson 3 is now the default JSON library in Flowable 8.0.0, with a Jackson 2 compatibility layer available. This matters for any team with custom REST payloads, serialized process variables, or service tasks that pass JSON between Flowable and existing services. Review your ObjectMapper configuration, custom Jackson modules and any classes that depend on Jackson 2 annotations or package names. Decide whether to migrate those classes or keep the compatibility layer for now, and test the REST API responses against the contract your clients already use.
Teams underestimate the operational setup because the starter hides it. The engines need a database schema, and Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types. Decide who owns schema creation and upgrades, which database account the engines use, and whether they share a datasource with your application tables. Set the async executor deliberately, since it runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. Pool sizing and lock settings determine how quickly work resumes after a node fails, so they belong in the design review and the load test. Finally, the actuator endpoint at /actuator/flowable exposes running process information, so confirm who can reach it before it reaches production.
Which engines, starters and database settings to choose
This table compares the main setup choices for a Flowable Spring Boot application: which starter to add, whether to embed the engine or run the REST application, and which database type to use. Read each row for when the option fits and what it adds to build, deployment and database operations. The main takeaway is that the starter and database decisions are hard to reverse once tables and deployment pipelines exist, so settle them before the first environment is built.
| Choice | When it fits | Operational cost |
|---|---|---|
| All-engines starter | One team runs BPMN, CMMN and DMN together and wants a single dependency to start with. | Every engine's schema objects and auto-deployment behavior load at startup, so unused engines still add tables and startup work to confirm. |
| Per-engine starters | You use only BPMN, or only DMN for decision tables, and want a smaller footprint. | Each engine you add later is another dependency to version, test and upgrade alongside the Spring Boot 4 baseline. |
| Embedded engine in your Spring Boot app | Process logic is owned by one Java service and calls go in-process through the engine API. | Engine upgrades ship with your application, so every Flowable release needs a full build and regression run of that service. |
| Flowable REST application | Several systems or non-Java clients need to start processes or read tasks over HTTP. | The REST app is a separate deployable with its own scaling, authentication, and monitoring to design and confirm. |
| PostgreSQL, Oracle, SQL Server, DB2 or MySQL | Your organization already operates one of these as a supported production database. | Schema creation and upgrades must be tested against the chosen vendor, and DBA review is needed before go-live. |
| MySQL below 5.6.4 | Only if an existing MySQL estate cannot be upgraded soon. | The docs note these versions lack millisecond precision, which affects timer and history timestamps; confirm the version before choosing. |
| H2 | Local development, unit tests and quick prototypes. | Not a production choice for shared, multi-node deployments; keep it out of production configuration. |
Building the Flowable Spring Boot application step by step
This sequence takes an empty Spring Boot 4 project to a running Flowable 8.0.0 application that deploys its own models, exposes monitoring, and completes a process instance. Each step ends with a check so the team knows the layer below works before building on it.
Pin Spring Boot 4 and Flowable 8.0.0 together
The developer sets the Spring Boot parent or BOM to a 4.x line and selects Flowable 8.0.0, the release that moved to Spring Framework 7 and Spring Boot 4. Flowable 8.0.0 has no backward compatibility with Spring Boot 3, so a leftover Boot 3 dependency will break the build or the context. Confirm the exact Spring Boot 4.x version against the Flowable Spring Boot documentation and your organization's approved baseline. The step is done when the dependency tree shows one Flowable version and no Spring Boot 3 artifacts, and the project compiles.
Configure the datasource and schema handling
The team points the application at a database type that Flowable supports, such as PostgreSQL, Oracle, MySQL, SQL Server, DB2 or H2 for local tests. Choose how schema changes are applied: let Flowable create or update its tables on startup, or run the scripts through your change process. If MySQL is used, confirm the server is at least version 5.6.4, because older versions lack millisecond precision that timers depend on. The check is that the application starts against the target database and the Flowable engine tables exist with the expected prefix.
Add the Flowable starters
The developer adds the official Flowable Spring Boot starters. Use the all-engines starter for a combined application, or add the individual process, CMMN and DMN starters when only some engines are needed. Keep the starter versions aligned with the Flowable 8.0.0 baseline from the first step. The check is that the application context loads without bean conflicts and the startup log shows each selected engine initializing.
Place BPMN, CMMN and DMN resources for auto-deployment
Models are stored in the standard resource locations that the starters scan, with BPMN files, CMMN case files and DMN decision tables kept in separate folders for clarity. Each file should be valid for its notation and carry a stable process or case key, because keys drive versioning when models change. Confirm the default scan locations and any naming rules in the Spring Boot section of the Flowable docs before relying on them. The check is that the deployments appear when the repository service lists them at startup, and a second restart does not create duplicate deployments.
Enable the REST starter if the application needs it
Only add the REST starter if other systems or a front end must call Flowable over HTTP. Without it, the engines are reached through Java APIs inside the application, which is a smaller attack surface. When enabled, the REST endpoints must be placed behind your authentication and authorization model, which is covered in the security and SSO work rather than assumed here. The check is that an authenticated request to a deployment or process definition endpoint returns data, and an unauthenticated request is refused.
Expose and check the actuator endpoint
The team includes the Spring Boot actuator and exposes the Flowable endpoint at /actuator/flowable, which reports on running process activity for monitoring. Management endpoints should be restricted to internal networks or a monitoring role, since they reveal operational detail. Confirm which exposure settings your Spring Boot version requires. The check is that the endpoint responds to an authorized request and shows the deployed definitions and any running instances created in the previous steps.
Configure the async executor for timers and jobs
The team sets the async executor that runs timers and asynchronous jobs from a thread pool. Size the pool for the expected load, and plan for the lock owner and lock expiration settings that the engine stores in the database, because they decide how a second node recovers stalled jobs. For a single node, the defaults are a starting point; confirm the property names and defaults in the Flowable advanced documentation. The check is that a process with a short timer fires on schedule and an async service task runs to completion in the logs.
Run a process instance to completion
The final check is functional, not configuration-based. A tester starts a process instance from the deployed BPMN model, through the Java API or the REST endpoint if enabled, and follows it through each user task, service task and gateway until it ends. The team then confirms the history records the completed path and the actuator endpoint no longer lists the instance as running. Use an illustrative model with one user task and one service task first, then move to the production process models. The step is done when the instance completes on the target database with no errors in the log.
How auto-deployment of processes, cases and DMN tables works
With the Flowable Spring Boot starters, process models, case models and DMN decision tables placed in the standard resource locations are deployed to the engine when the application starts. The practical consequence is that the application's classpath, not a separate deployment step, decides which definitions the engine knows about. Before you rely on this behavior, confirm in the Flowable Spring Boot documentation for the exact version you ship which locations are scanned by default, which file suffixes are recognized for BPMN, CMMN and DMN resources, and whether the scan can be narrowed or disabled through configuration. The Spring Boot docs are the authority here, and the Flowable 8.0.0 line is built for Spring Boot 4, so the Spring Boot 3 documentation may not describe the same behavior. Each startup deploys the resources it finds as new versions of the definitions with the same keys. Flowable assigns an incrementing version to each deployment of a key, so a restart with unchanged files should be checked for whether it creates a duplicate version or is skipped. Confirm the duplicate-detection behavior in your target version with a test: start the application twice against the same database, then query the deployed definitions and count the versions. Also confirm whether deployments are tied to a tenant or a deployment name, because those settings change which definitions are considered the same and which are kept side by side. The main risk is redeploying a process definition while instances of an earlier version are still running. Running instances normally stay bound to the version they started on, but a changed model with a new version can still alter behavior for new work, timers, or any instance you migrate by hand. Plan for this before the first production release: decide whether a changed model is a new key or a new version of the same key, decide who approves a redeploy, and test a restart against a copy of the production database that holds active instances.
To keep definitions in sync across development, test and production, treat the resource files as release artifacts. Put BPMN, CMMN and DMN files in version control, build them into the application artifact, and promote the same artifact through each environment rather than editing models directly in a running database. This avoids the common drift where a model fixed in test never reaches production. If your organization allows an external deployment process, the same rule applies: one artifact, one checksum, and a record of which definition versions each environment is running. Decide early whether auto-deployment is the right mechanism for every environment. It works well for a small number of models shipped with each release. It is harder to govern when several teams deploy models independently to a shared database, because a restart of one application can publish another team's changes. Ask your Flowable partner or internal platform team to document which application owns each definition key, and to set the rule that only that application's artifact may deploy it. Test the startup behavior as part of the release, not only the models. Run an integration test that starts the Spring Boot application on a database with existing instances, confirms the expected definition versions exist, and confirms that running instances still complete. Keep the database type in the test the same as production, because the Flowable configuration docs list several supported databases and the behavior of the deployment tables should be checked on the one you run.
Securing the datasource, REST endpoints and actuator
Three controls decide how exposed a Flowable Spring Boot application is: the database account, the HTTP surface of the REST starter, and the actuator endpoint. The identity service sits behind them and decides which users and groups tasks and lookups resolve to. Work through the cards in that order, then verify each boundary before go-live.
Database credentials from a secrets manager
The engines connect through the datasource settings in your Spring Boot configuration, and the account needs rights to create and update Flowable schema tables during deployment and upgrades. Keep the username and password out of application properties files and source control by loading them from a secrets manager or from environment variables your platform injects at startup. Confirm with your secrets team how rotation interacts with connection pool restarts, and check whether the runtime account can be narrowed once the schema is in place.
REST starter behind Spring Security
The Flowable REST starter exposes process, case, decision and task operations over HTTP, which makes it an API surface in its own right. Place it behind Spring Security filter chains so every request is authenticated and authorized before it reaches the engine. Map which roles can start instances, read variables or complete tasks, and test each rule with a user who should be denied. Confirm which REST paths your chosen starter version serves so none fall outside the security configuration.
Actuator exposure limited to Flowable
The Flowable starter adds an actuator endpoint at /actuator/flowable that reports on running processes. Expose that endpoint only to operators who need it, and keep other actuator endpoints off public interfaces or behind authentication. Where your platform allows, serve management endpoints on a separate port or internal network. Review the response content for process data that operators outside the support team should not see, and confirm which endpoints your Spring Boot version exposes by default.
Identity replacement through IdmIdentityService
The IDM engine resolves users and groups through the IdmIdentityService interface. The Flowable docs describe two ways to replace the default behavior: override IdmIdentityServiceImpl or implement the IdmIdentityService interface. An LDAP identity service is provided as a reference implementation. Decide which directory is the source of truth for candidate users and groups, then test that task assignment and candidate group queries return only the people your access policy allows.
Verifying the security configuration
Settings for the datasource, REST endpoints and actuator only hold if they are tested after each change. Build a short check list: unauthenticated calls to REST paths fail, unauthorized roles are denied, actuator paths other than the Flowable endpoint are unreachable from outside the network, and database credentials do not appear in logs or error responses. Run these checks in a staging environment that mirrors production configuration, repeat them after each Flowable or Spring Boot upgrade, and keep the results as evidence for your assessors.
How the integration changes on single node, multi-node and air-gapped setups
On a single node, the Spring Boot application runs one Flowable engine instance against one database. The starters create or upgrade the engine schema on startup, and the async executor runs timers and asynchronous jobs in-process without needing to coordinate with other instances. Most of the configuration effort goes into the datasource, the auto-deployment of process, case and DMN resources, and the actuator endpoint used for monitoring.
The points that matter most at this stage are:
- Datasource ownership: Confirm which database type you run. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and notes that MySQL versions below 5.6.4 lack millisecond precision.
- Schema changes at startup: Decide whether the application may change the schema on boot or whether a controlled migration step runs first.
- Auto-deployment scope: Limit which BPMN, CMMN and DMN files load from the classpath so test artifacts do not reach production.
- Job execution: Timers and async jobs depend on one node staying up. Plan a restart procedure that does not lose scheduled work.
- Monitoring: Check the /actuator/flowable endpoint and expose it only to operators.
Before approving a single-node design, confirm with your platform team how the node will be restarted, patched and backed up, because the process state lives entirely in that one database.
When several stateless Spring Boot instances share one database, each instance runs the engine against the same schema. Any node can start or continue a process, but the async executor must avoid two nodes running the same timer or job. Flowable does this through lock owners and lock expiration times stored in the database. If a node stops while holding a lock, the lock expires and another node picks up the job.
The points that matter most at this stage are:
- Shared database: Every node must point at the same database and schema. Local embedded stores break coordination.
- Schema upgrades: Run schema changes once, through a controlled release step, rather than letting every node race to migrate on startup.
- Lock expiration settings: Review how long a lock lasts before recovery. Values that are too long delay recovery, and values that are too short risk duplicate execution.
- Session and node state: Keep application state in the database or in external stores, not in node memory, so any instance can serve any request.
- Clock and time sources: Timers depend on consistent time across nodes, so confirm time synchronization in the hosting environment.
The depth of this topic, including database high availability, scaling of timers and failover testing, belongs in the Flowable high availability guide. Review that guide before setting the node count.
In an air-gapped network, the build server cannot download Maven or Gradle dependencies from public repositories at build time. The team must mirror every required Flowable artifact and its transitive dependencies into an internal repository, then build the application from those offline artifacts. The Spring Boot starters, the Flowable engine JARs and the database driver for your chosen database all need to be present in the mirror.
The points that matter most at this stage are:
- Dependency mirror: Build an internal repository that holds the exact Flowable and Spring versions in use, including transitive dependencies, and verify the build succeeds with outbound access blocked.
- Version pinning: Pin versions explicitly so an offline build cannot pull a different release than the one tested.
- Database driver and JDBC source: Check that the driver for your database is mirrored and that it is approved for the network's software inventory.
- Process and DMN artifacts: Process models, case models and decision tables are packaged with the application, so they travel through the same controlled transfer.
- Update path: Define how security fixes and new Flowable releases enter the network, since the mirror is a manual import process.
Before approving an air-gapped build, run a complete build and deployment from a cold cache on an isolated network, because missing transitive dependencies usually surface only at that point.
Testing the integration and confirming it fails safely
The Spring Boot integration is not ready until tests show that processes run, timers fire, failed jobs recover and a broken process model stops the application from starting. Start with unit tests for your delegates and expressions, then add integration tests that boot the embedded engine with the same starters and configuration as production. Use JUnit 5 for all new tests. Flowable 8.0.0 removed JUnit 3 and 4 support, so any test base classes, rules or runners carried over from Flowable 7.x or older code need migration before the suite will run. Confirm the exact removal scope in the 8.0.0 release notes and in your own build before estimating the effort.
Run deployment tests against a copy of the production database, not an empty schema. A copy shows whether auto-deployed BPMN, CMMN and DMN resources deploy cleanly on top of existing data and whether any database schema upgrade completes. For timers, use the engine's test clock or a controlled job executor so that a timer fires at a known point, then assert the resulting process state. For failed jobs, force an exception in a service task, confirm the job is retried according to the retry settings your Flowable version exposes, and confirm that a job which keeps failing becomes visible to operators rather than disappearing.
Fail-safe behavior starts at startup. Add a test profile that deploys a deliberately invalid process model and asserts that the Spring context fails to start with a clear error. A process that deploys with a silent error, or an application that starts with missing definitions, will only surface when a customer case reaches that step. Also verify the actuator endpoint at /actuator/flowable in a test environment, asserting that it reports the deployed definitions and running instances. Decide who may read that endpoint in production, because it exposes process information and should sit behind the same access controls as your other management endpoints.
The two-node test checks the async executor's lock recovery. Start two application instances against the same database, create a timer or async job that will fall due, and let one node acquire the job. Stop that node while the lock is held, wait past the lock expiration time configured for your environment, and confirm that the second node picks up the job and completes it exactly once. Inspect the lock owner and lock expiration values in the job table during the test to show the handover. Ask your partner for a written test plan that lists the scenarios, the expected results and the evidence each run will produce, so that the results can be reviewed by your team and kept with the release record.
What to monitor, back up, upgrade and document after go-live
This table lists the operational areas a Flowable Spring Boot team needs to own after go-live, with what to watch, what to back up, what the 8.0 upgrade touches and what to document. Read each row as a question your runbook must answer before the first production release. Teams that skip the documentation and upgrade rows usually find the gaps during an incident or a framework upgrade.
| Area | What to watch or do | What to confirm or keep |
|---|---|---|
| Running processes | Use the actuator endpoint at /actuator/flowable to read counts of running process instances and check that the endpoint is exposed only to your monitoring network. | Confirm which actuator endpoints your Spring Boot configuration exposes and who can reach them. |
| Job queue depth | Track the number of waiting asynchronous jobs and timers over time, since a rising backlog points to executor capacity or a stuck node. | Record the normal range for your workload so alerts reflect real deviation, not a guessed threshold. |
| Failed jobs | Alert on jobs that exhaust retries and move to the dead letter or failed state, and review their exception messages each working day. | Document who owns each failed job type and the steps for retrying or cancelling it safely. |
| Database backups | Schedule backups of the Flowable schema, including runtime, history and job tables, so they stay consistent with each other. | Confirm that restores were tested against the same engine schema version the application runs, and note the restore time you measured. |
| Upgrade from 7.x to 8.0 | Plan for Spring Framework 7 and Spring Boot 4, which Flowable 8.0.0 requires with no Spring Boot 3 backward compatibility, and for Jackson 3 as the default JSON library. | Check every custom delegate, REST client and JSON mapping for Jackson 2 assumptions, and rerun process model regression tests against a database copy. |
| Test framework changes | Flowable 8.0.0 removes JUnit 3 and 4 support, so existing engine tests need migration before the upgrade is verified. | Record which test suites moved and which were retired, so reviewers can trace coverage. |
| Deployed definitions | Document each deployed BPMN, CMMN and DMN definition with its version, deployment ID, owning team and the release that introduced it. | Keep the source models in version control and link each deployed version to its commit. |
| Datasource and executor settings | Document the datasource URL, pool sizes, database type and the async executor thread pool and lock settings for each node. | Store these values in a configuration record that changes through the same review process as code. |
Questions teams ask before embedding Flowable
Can our team embed Flowable in Spring Boot without a partner?
Yes, a capable Java team can embed the Flowable engines without a partner, because the engines are Apache 2.0 licensed and the Spring Boot starters are documented. The real question is capacity and experience. Someone must own datasource setup, process and case deployment, custom delegates, identity mapping, the async executor and upgrades, and must test every model before go-live. Teams with prior BPMN work and a clear owner usually find the documentation enough to start. Teams without that experience often spend early effort learning the engine instead of delivering the process. A partner can take that risk off your schedule or review your design before you build. Confirm with Flowable which support options fit your use, since community and commercial support differ.
What drives the cost and timeline of a Flowable embedding project?
Scope is the largest driver: the number of processes, whether each needs BPMN, CMMN or DMN, and how many decisions and forms they include. Integrations come next. Each system a task calls needs an interface, error handling and test data. Environments add effort, including separate databases for development, test and production, plus CI pipelines and automated model deployment. Migration adds the most uncertainty if you are moving from Camunda 7 or Activiti, because in-flight instances and history must be checked. Design, build and testing are one-time costs, while hosting, upgrades and support recur. Ask any quote to list these items separately, with stated assumptions about data volume and named environments. Fixed-scope work is agreed in writing before it starts, so the scope document should set the timeline.
What does the embedding work need from our engineers?
Your engineers need working Java and Spring Boot skills, plus familiarity with relational databases, because the engine stores process state, timers and locks in database tables. They also need to own the build. That covers Maven or Gradle configuration, starter selection, schema management and automated deployment of BPMN, CMMN and DMN files. Someone on the team should understand the process models well enough to review them, since business logic often sits in models and delegates. Expect to provide access to a test database, an identity source and any systems the processes call. Operations staff need to monitor the Flowable actuator endpoint and understand how the async executor behaves across nodes. Confirm the skill profile with your partner or with Flowable's documentation for your target version.
Do we have to run the Flowable REST app to use the engines?
No. Flowable documents embedding the engines directly as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers. The REST application is one option, not a requirement. It suits teams that want to call the engines over HTTP from other languages or systems. The Spring Boot docs describe separate starters for the REST layer and for individual engines, so you can include only the engines and APIs you use. Embedding keeps process execution inside your own application and deployment pipeline, while the REST app adds a separate service to secure, scale and monitor. If only Java services call the engine, embedding is usually simpler. If several technology stacks need HTTP access, the REST starter may be the better fit. Confirm the REST API security approach with Flowable before you expose it.
Do the open source Flowable engines need a commercial license?
No commercial license is needed to use the open source Flowable engines, which are licensed under Apache 2.0. The license covers the BPMN, CMMN, DMN and event registry engines and their REST APIs as published in the open source repository. Flowable's commercial products are separate purchases. Products such as Flowable Work, Engage, Orchestrate and Design are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. You do not need them to embed the engines. Open source users have access to a community forum, while professional services and partner support are offered separately. Ask Flowable to confirm current terms for your use, and have your legal team review the license text and any third-party dependencies in your build.
Which Spring Boot version works with the current Flowable release?
Flowable 8.0.0 was released on February 27, 2026, and it upgrades to Spring Framework 7 and Spring Boot 4. The release notes state there is no backward compatibility for Spring Boot 3. Existing Spring Boot 3 applications need migration before they can adopt 8.0.0. The release also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes support for JUnit 3 and 4. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, so teams on Spring Boot 3 must choose between staying on the 7.x line and planning a Spring Boot 4 upgrade. Confirm the Java baseline and supported combinations for your exact version in the release notes before you start.
What happens to the async executor when we run several application nodes?
The async executor runs timers and asynchronous jobs from a thread pool. Nodes coordinate through lock owners and lock expiration times stored in the database. If a node holding a job fails, its lock expires and another node can pick the job up. This lets you run several application instances on a shared database, but you must size the thread pool, the lock settings and the database for your job volume. Test failover in a staging environment with real timers, because a poor lock configuration can cause duplicate or delayed execution. Plan database high availability separately, since the lock table is only as available as the database behind it. Confirm the expected behavior for your chosen database and connection pool with Flowable's documentation before you go live.
How DeployOpen scopes, builds and hands over Flowable integrations
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including Flowable Spring Boot integration. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which Flowable engines the application needs, such as the process, CMMN, DMN or event registry starters, before any code is written.
- Record the target Spring Boot and Java baselines, and whether the application is on Spring Boot 4 or needs a version decision first.
- Agree in writing which database types, datasource setup and auto-deployment of process, case and DMN resources are in the deliverables.
How we build
- Configure the engine starters, datasource and async executor settings in your Spring Boot application, following Flowable's documented configuration.
- Test deployed process, case and decision models against the database you run in production, including the actuator endpoint used for monitoring.
- Check async executor behavior on the nodes you plan to run, including lock owners and expired lock recovery where multiple instances share a database.
How we hand over
- Deliver the source, configuration, model files and build pipeline changes described in the agreed scope, with the test results they were verified against.
- Document the datasource setup, auto-deployment behavior, REST starter settings and actuator monitoring so your engineers can operate the application.
- Walk your team through the runbook for deploying new model versions and reviewing the running processes exposed through monitoring.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the Flowable starters and Spring Boot version you run.
- Plan upgrades to new Flowable and Spring Boot versions as separate scoped work, with regression testing of the process models before cutover.
- Confirm with Flowable which support options are available for your edition, since professional services and partners are offered separately from the open source engines.
