Which option fits a team weighing a switch from IBM Business Automation Workflow
IBM Business Automation Workflow fits best when the organization already depends on what it bundles: coaches for user interfaces, the process designer for authoring, IBM support contracts, and a Cloud Pak for Business Automation estate that is staying in place. Teams in that position gain little from a platform change unless a renewal, a licensing change or a residency requirement forces the question. Flowable fits a different team: one that will build its own user interface, accepts that much of the work happens at the engine level in Java, and wants Apache-2.0 licensed BPMN, CMMN and DMN engines that it can run in its own infrastructure. Because Flowable's open-source edition leaves out the UI applications and form tooling, the switch is a build decision as much as a license decision.
Three factors should drive the decision. The first is how much of the current estate is user interface and authoring. Inventory the coaches, process apps and case solutions that business users touch every day, and estimate the front-end work to replace them, since that work is usually the largest cost in a move and it recurs as the interface changes. The second is skills. Flowable's engines are consumed through Java and Spring Boot, with starters for each engine and a REST API, so confirm that your developers can own the engine configuration, the async executor and the database layer. The third is how much support the organization must buy. Ask Flowable which commercial editions, professional services and partners it can offer alongside the open-source engines, and ask IBM what its current support terms would cost to keep through your planned exit date.
Run a short proof of concept before committing. Take one representative BPMN process with a human task, one DMN decision table and one CMMN case if you have them, and rebuild each on the Flowable engines in a non-production environment. Measure the time spent on the interface, the identity integration and the monitoring setup, not only the modeling. If the proof of concept shows that your team can deliver those parts, Flowable is a credible target. If the work points to a large user-facing rebuild that no one owns, the better next step may be to stay on IBM for the current lifecycle and plan the exit as a separate project. Confirm the Flowable release that you will standardize on, since the 8.0.0 line changed its Spring and Java baseline, and check the current support terms with each vendor in writing.
Which option is the better fit for each scenario
This table compares IBM Business Automation Workflow and Flowable across common operating scenarios and states the condition under which each fit holds. Read each row as a question about your own team, then check the condition before choosing, since several Flowable advantages depend on work you would own.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Business users edit processes and cases through a visual UI on an existing Cloud Pak estate | IBM Business Automation Workflow, if the contract confirms it | Flowable's open-source edition does not bundle a process designer or user task UI, so users would depend on UI you build. Confirm in the IBM contract which authoring tools and support terms apply to your licenses. |
| Platform team wants BPMN and CMMN work in version-controlled code | Flowable | This fits only if your engineers will own the models, tests and deployment pipeline. Flowable provides BPMN, CMMN and DMN engines with Java and REST APIs under Apache 2.0, so model changes can follow your normal code review. |
| Java team embedding a process engine inside its own services | Flowable | Flowable runs as a JAR in Java SE, servlet containers, Spring applications or Java EE servers, and offers Spring Boot starters. The fit assumes your team is comfortable with the database, async executor and identity configuration it will operate. |
| Team that needs vendor-backed SLAs and a single accountable support contract | IBM Business Automation Workflow, if the contract confirms it | Flowable's open-source edition offers a community forum, with professional services and partners sold separately. Confirm support hours, response targets and escalation paths with IBM before assuming they match your needs. |
| Strict requirement to keep all process data inside your own network | Flowable, if deployed on your own infrastructure | Flowable can run on H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server that you host. Confirm where any IBM-managed components, telemetry or licensing checks send data before choosing IBM for this scenario. |
| Estate is on WebSphere or Cloud Pak and the team plans a new platform within a fixed budget | Decide after a cost comparison | Licensing and platform costs under IBM are contract-specific, so ask for them in writing. Flowable's engines are free under Apache 2.0, but UI, rebuild and operations effort are yours to estimate from your written scope. |
| Team with limited Java skills and no plan to hire developers | IBM Business Automation Workflow, if the contract confirms it | Flowable assumes engineers who can build the UI, integrations and operations. Without that capacity, the open-source route shifts delivery risk to your team, so a fixed-scope implementation partner may be needed. |
What Flowable's open-source edition leaves out compared with a bundled suite
Flowable's open-source engines execute BPMN processes, CMMN cases and DMN decision tables, and they expose Java APIs and REST APIs for starting work, claiming tasks and querying state. What they do not include is the layer that IBM Business Automation Workflow bundles around its engine. The Flowable 7.0.0 release notes say version 7 removed the UI applications, the form and content engines and async history. Before you compare costs, list every part of your current estate that depends on those removed pieces: the process UI and coaches, form rendering, document and content storage, and the history views your operations team uses. Each one becomes a build, buy or integrate decision.
The commercial Flowable products, including Flowable Work, Engage, Orchestrate and Design, add low-code modeling, visual debugging, security controls, monitoring and governance on top of the same engines. Treat these as a separate line item in your quote. Ask the vendor which features are included, how they are licensed, and whether they run in your own infrastructure. If you choose the open-source route, budget for a task UI, a forms approach, a document store and a debugging or monitoring method of your own, and confirm with your team who will maintain each one after go-live.
Confirm the target stack before you estimate effort. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and it defaults to Jackson 3. If your application or your platform team is standardized on Spring Boot 3, the upgrade is a prerequisite rather than an option, and it changes the size of the rebuild. Also confirm the Java version and the database types your operations team supports before you choose the release line.
Where process data lives and who controls the hosting
Process instances, variables, case documents and audit history all sit in a database and a runtime somewhere. Who owns that database, network and identity store decides who can access the data and what evidence you must produce. The cards below compare how each side answers those questions.
Runtime placement and network control
Flowable runs embedded in your own Java application (Spring, a servlet container or a Java SE process) or as a standalone service with REST APIs. In either model, your team decides which hosts run the engine, which network segments can reach it and where the process database lives. Check how your IBM estate is deployed today: confirm whether Cloud Pak for Business Automation and WebSphere run in your data centers, a private cloud or an IBM-operated environment, and who holds the operator and root access.
Supported database engines
Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. Because the engine writes process state, timers and history to that database, the choice of database is also a choice of backup, replication and restore tooling. Confirm which database your IBM environment uses today, since moving a durable process store between engines is part of the migration plan. MySQL versions below 5.6.4 lack millisecond precision, so check your version before you rely on timer accuracy.
Identity replacement through IdmIdentityService
Flowable's engines do not require their own user directory. The Flowable docs describe replacing identity management by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Your team owns that integration: group membership, task assignment, and how user attributes reach the engine. Map every IBM role, group and coach-level authorization to an explicit rule in your code, and test the mapping before the cutover, since silent mismatches show up as tasks routed to the wrong people.
Audit evidence you must produce
Flowable provides the execution history and the engine's data, but it does not come with the access logs, change records, backup test results or access reviews that an assessor will ask for. Those controls must be designed and evidenced by your organization or your implementation partner. DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Agree the evidence list with your assessor before build starts.
Hosting responsibilities on the IBM side
IBM Business Automation Workflow runs on WebSphere or in containers under Cloud Pak for Business Automation, and the platform underneath (WebSphere, OpenShift, databases and storage) carries its own operating responsibilities. Ask IBM and your own operations team to write down, for your contract, which layers they operate, which they support and which remain yours. Include patching, certificate rotation, backup and restore, and log retention. Those answers set the baseline you compare against when you take ownership of the Flowable stack.
What operating Flowable involves, by deployment mode
When Flowable runs as a JAR inside a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server, the process engine shares a lifecycle with your application. Your development team owns the engine version, the dependency tree and every deployment, so an engine upgrade is a change to your application build, tested with your code. The Flowable Spring Boot documentation describes starters for all engines, for REST and for the individual process, CMMN and DMN engines, with support for Spring Boot 4.x. Choosing a starter sets which engines are on the classpath, which keeps the footprint small.
- Who patches: your team patches the Flowable libraries, the Spring or Java EE runtime, the JDK and the database driver. Flowable's own release notes are the input for each change.
- Database and async settings: plan the database type first. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. The async executor coordinates nodes through lock owners and lock expiration times stored in the database, so multiple application instances need a shared database and sensible lock settings.
- Actuator monitoring: the Spring Boot starters expose an endpoint at
/actuator/flowablefor monitoring running processes. Wire it into your existing metrics pipeline. - Identity: the identity service can be replaced by implementing
IdmIdentityService, with an LDAP reference implementation available.
Confirm with your architects whether the engine versions your application needs match the supported Spring Boot line before you commit to a major upgrade.
Running Flowable through the Flowable REST application gives several business applications one shared process service reached over HTTP. This resembles the way IBM Business Automation Workflow is often consumed by the rest of an estate, so teams moving from a central server may find this mode closer to their current operating model. The platform team owns the service, its database, its scaling and its access controls, while application teams own the BPMN, CMMN and DMN models they deploy to it.
- Who patches: the platform team patches the REST application, the container or host image, the JDK and the database. Application teams do not patch the engine, but they must test their models after each upgrade.
- Database and async settings: size the shared database for all tenants of the service. Plan the async executor and lock expiration settings for each node in the cluster, and keep the database reachable from every node.
- Scaling and health: run more than one node behind a load balancer when availability matters, and check how the async executor recovers expired locks during a node failure in your test environment.
- Access control: the REST API is the main attack surface. Define who can deploy models, start instances and query history, and place the service behind your identity provider and network controls.
- Monitoring: use the actuator endpoint in a Spring Boot build, or your own health checks, to watch running instances and job backlogs.
Before committing, ask your vendor or implementer to show the exact deployment artifact, the upgrade procedure and the configuration keys used for clustering in your target environment.
Teams comparing these modes with their current IBM estate should translate operations into the same terms. A Business Automation Workflow estate typically involves WebSphere or OpenShift operations, and Cloud Pak for Business Automation upgrades on their own schedule. Those responsibilities do not disappear on a move to Flowable, but they change owner and tooling. Confirm the following with IBM, your license terms and your own operations team, rather than assuming them.
- Runtime operations: list who currently patches WebSphere or the OpenShift cluster, how often, and through which change process.
- Cloud Pak upgrades: confirm the upgrade path, required prerequisites and the effort of each step for your installed version.
- Support boundaries: identify which fixes come from IBM, which come from your integrator and which your team must apply.
- Customizations: inventory coaches, toolkits and custom code that run only on the IBM platform.
- Data and history: confirm where process history lives and how long it must be retained.
The result gives you a like-for-like operating checklist that you can compare against either Flowable deployment mode.
What drives the cost of each option
Cost of ownership splits into licensing, platform, people and support, and each part behaves differently. Some costs are paid once during migration, while others recur every year for as long as the platform runs. Use these cards to build a like-for-like quote request before comparing totals.
IBM licensing and platform
IBM Business Automation Workflow is licensed as part of IBM Cloud Pak for Business Automation, and the WebSphere or OpenShift platform beneath it carries its own subscriptions and administration. This cost recurs for as long as the estate runs. Ask IBM or your reseller to break the annual charge into product, middleware and cluster components, and confirm which entitlement tier covers your user and process counts.
Flowable engines versus commercial editions
Flowable's BPMN, CMMN and DMN engines are Apache-2.0 licensed, so the engine itself carries no license fee. Flowable also sells commercial editions such as Flowable Work, Engage, Orchestrate and Design, which add low-code modeling, visual debugging and governance. Decide early which tier you need, because adding commercial products changes the recurring cost more than any server choice.
Servers and databases
Flowable runs embedded in your application or as a standalone REST service on servers you provision, and it supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Your cost depends on the database you already license and operate, plus high-availability nodes for the async executor. Confirm with your DBA which database engine and backup tooling your standards require.
Rebuild effort for processes and cases
Each IBM process app, toolkit and case solution must be redrawn in BPMN or cases in CMMN, and business rules re-expressed in DMN. This is a one-time cost that scales with the number of applications, integrations and in-flight instances you must drain. Ask any implementation partner for a written inventory and a fixed-scope estimate per application before agreeing a timeline.
UI development and user adoption
IBM coaches and case UIs do not transfer to Flowable, so you must build or buy replacement screens, task lists and case views. This is a one-time build cost followed by recurring maintenance as forms change. Costs rise with the number of distinct user journeys and falls when you reuse a shared component library. Request a list of screens with an estimate for each.
Support and upgrade contracts
Flowable's open-source edition relies on a community forum, while professional services and partner support are contracted separately. Support, patching, upgrades and monitoring are recurring costs that follow the chosen support level. Confirm the Flowable release line you will run, for example the 8.0.0 release from February 27, 2026, and ask for response commitments, upgrade assistance and who holds the on-call duty in a written quote.
How a move from IBM Business Automation Workflow to Flowable is sequenced
The sequence turns an inventory of IBM process apps and case solutions into a tested Flowable estate, then retires the WebSphere or Cloud Pak runtime only after in-flight work has safely finished. Each phase has a named output that gates the next one.
Inventory process apps, toolkits and case solutions
Start by listing every process application, toolkit, Coach, service flow, case solution and integration that runs on the IBM estate, together with the systems each one calls and the data it stores. Your application owners and IBM administrators supply the list, and DeployOpen typically helps with the technical scan of exported artifacts and runtime configuration. The step is done when every asset has an owner, a business purpose and a recorded set of dependencies, and nothing is left unassigned.
Decide which processes and cases carry over
Classify each asset as migrate, rebuild, merge or retire, based on how often it runs, how many instances are open, and whether the business still needs it. Process owners make these calls, with architects checking integration impact and compliance staff confirming any retention or audit obligations. The output is a signed-off disposition list in which every BPMN process, CMMN case and DMN decision set has a named decision, which becomes the scope for the rest of the work.
Redraw models in BPMN and CMMN and rebuild decisions in DMN
Redraw the retained processes as BPMN 2.0 models and the case-driven work as CMMN case models with stages, milestones and sentries. Move business rules into DMN decision tables and agree how each one is versioned and tested. Process architects and domain experts sign off the models, and engineers verify that the Flowable engines deploy them without errors. The step closes when each model passes deployment and a review of its business behavior against the original IBM artifact.
Build the replacement UI and document store
Coaches, process UIs and case views have no direct equivalent in the open-source engine, so this phase designs and builds the user interface in your own front-end stack and connects it to Flowable's REST APIs. Document handling moves to a content store you run, with access rules that match the old case permissions. Your product owners and developers do the build, and DeployOpen typically supports the integration, security review and access-control design. The check is a set of tested user journeys that cover each retained process and case.
Stand up the Flowable runtime and identity
Deploy Flowable on the infrastructure you choose, whether embedded in Spring applications or run as a standalone REST service, and configure a supported database. Connect identity through an identity service implementation that reads your directory. Platform engineers build the deployment, backup and monitoring, and security staff review authentication and authorization. Confirm that the async executor's lock handling works across the nodes in your cluster, then close the phase with a documented, reproducible environment.
Run old and new in parallel
Route new work to Flowable for a controlled set of processes while the IBM runtime keeps handling everything else. Compare outcomes, task timings, audit records and decision results between the two runtimes, and fix any gaps before widening the scope. Operations, process owners and testers jointly run the parallel period. Success is defined in advance as matching outputs for an agreed set of test cases, and the parallel run ends only when those criteria are met.
Drain in-flight instances
Let instances already running on IBM finish where possible, and plan the migration of any long-running instances that must move, since open-source engines do not convert IBM runtime state automatically. Track the count of open instances per process and case until it reaches an agreed threshold, and document any instance that is migrated by hand. The step is complete when the remaining open work is either finished or recorded and accepted by the business owner.
Retire the WebSphere or Cloud Pak estate
Once the drain is complete, archive the IBM artifacts, audit history and configuration you are required to keep, then decommission the WebSphere or OpenShift components and remove licenses that no longer apply. Confirm the retention period with your compliance team, and have your procurement team confirm contract exit terms with IBM. The closing output is a decommissioning record that shows what was archived, where it is stored and who approved the shutdown.
What buyers ask before choosing Flowable over IBM Business Automation Workflow
What does a move from IBM Business Automation Workflow to Flowable actually cost?
The cost is driven by the work, not by a license fee, because Flowable's open-source engines are Apache-2.0 licensed. Your spend falls into four components: the people who inventory and redraw processes and cases, the developers who build the user interfaces IBM bundles with its toolkits, the servers and database you run Flowable on, and any support contract you choose. Most of the one-time cost sits in the rebuild. Recurring costs are infrastructure, operations staff and support. Ask any provider for a quote that separates these components, lists the process and case count in scope, and states which UI screens are included. DeployOpen does not publish prices; a quote follows from a written scope.
How long does a migration take, and what sets the pace?
Duration depends on how many process apps, toolkits and case solutions you run, how complex their coaches and integrations are, and how much of the logic is already documented. There is no fixed timeline that applies across estates. The main pace-setters are the number of BPMN processes and CMMN cases to redraw, the volume of user interface work to replace IBM coaches, the integrations with systems of record, and the number of instances still running when you cut over. Ask for a timeline tied to a written, fixed scope before work starts.
Can our own team migrate to Flowable without outside help?
A team with strong Java and Spring skills can do much of the work internally, but it needs skills IBM's suite largely hides. These include BPMN and CMMN modeling, Flowable engine configuration against your chosen database (Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server), identity integration, a web front end for tasks and cases, and operations work such as clustering and backups. Assess these skills honestly against your inventory before committing. Many teams combine internal ownership with a fixed-scope engagement for the riskiest parts.
What does IBM support cover that the Flowable community forum does not?
IBM contracts typically include vendor-backed fixes, defined support hours, and a single accountable party for the stack, though you must confirm the exact terms in your own agreement. Flowable's open-source edition offers a community forum, while professional services and partners are offered separately, and its commercial products add modeling, debugging, security controls and monitoring. Bring in professional services or a partner when you need guaranteed response times, production incident handling, or help with a complex migration. Confirm what your organization requires before you decide.
Does Flowable 8.0.0 change the upgrade path?
Yes, and the change matters for planning. Flowable 8.0.0 was released on February 27, 2026, and its release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It also makes Jackson 3 the default JSON library, keeps a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. Teams starting now should decide between 7.x and 8.x early, check their own Spring Boot and test dependencies, and budget for that upgrade in the rebuild. Confirm the chosen line against the release notes before you start.
How are in-flight process instances handled during the move?
Running instances usually cannot be copied directly from IBM's runtime into Flowable, so the common approach is to let existing instances finish on IBM while new work starts on Flowable, then drain the old estate over time. Some organizations migrate long-running instances by mapping their state to Flowable models, which needs careful testing. The right approach depends on instance lifetimes and business rules. Ask your provider to inventory open instances by age and state, and to document the cut-over and rollback plan in writing.
Do we need to build a case UI, and what does Flowable's CMMN engine provide?
Yes, you will generally need to build the case interface yourself. Flowable's CMMN engine executes case types, stages, milestones and tasks, and it exposes Java and REST APIs, but the open-source edition does not ship the case worker application that IBM bundles. Plan for the screens case workers use, how documents are attached and stored in your own content system, and how access is controlled. Treat this as a distinct work package in the quote.
What should we confirm with IBM before a renewal decision?
Before deciding, request written answers on the current support end dates for your Cloud Pak for Business Automation version, the price and terms of any renewal, the extended support options and their costs, and the upgrade path that IBM proposes for your runtime. Also confirm whether your estate runs on the traditional WebSphere runtime or on containers, since that changes the migration effort. Ask IBM which artifacts can be exported and in what form. Use those answers to compare renewal against the migration scope in your own quote.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted Flowable inside your own cloud accounts, data centers or air-gapped networks. We start by testing whether your IBM Business Automation Workflow processes, cases and decisions map to Flowable's BPMN, CMMN and DMN engines, then build only the parts you approve in writing.
How we scope
- We inventory your process apps, toolkits, case solutions and decision services before estimating any Flowable work.
- The written scope names which BPMN processes, CMMN cases and DMN tables move, and which are retired.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We identify the UI, identity, content storage and database choices you must make before build begins.
How we build
- We redraw in-scope processes in BPMN and cases in CMMN, then test them against your current behavior.
- Flowable runs embedded in Spring Boot applications or as a standalone service over its REST APIs.
- We configure the async executor, database type and lock handling for the nodes you plan to run.
- We build the task and case front ends you need, since Flowable's open-source edition does not bundle them.
How we hand over
- You receive documentation covering deployment, configuration, process models, decision tables and integration points.
- We document a drain plan for in-flight IBM instances so cutover and rollback steps are explicit.
- Backup, restore and upgrade procedures are written for your own database and infrastructure.
- Compliance evidence is prepared for your assessor, though audit reports and certifications come from independent bodies.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We track Flowable releases, including major version changes, and scope upgrades as separate written work.
- Security testing of the applications, APIs and infrastructure around the engine can run on a recurring basis.
- Support terms, response expectations and included services are confirmed in writing before the retainer starts.
