Can Flowable's CMMN engine replace IBM BAW case solutions?
If you run a case solution on IBM Business Automation Workflow and need to replace it because of a licensing change, a lifecycle date or a data residency requirement, the CMMN engine in Flowable covers the case model itself: case types, stages, milestones and task planning, licensed under Apache 2.0. What it does not cover is the case user interface, the document store and the identity wiring. Those three layers are yours to build or choose, and they usually account for more of the project than the engine does. Before you start, confirm with Flowable which CMMN features your cases depend on, such as particular planning table behaviors or sentry conditions, and check them against a sample of your most complex case types.
Treat the rest of the IBM suite as a separate decision. BPMN processes and DMN decisions in the same estate can move to Flowable's BPMN and DMN engines, to Operaton or to another engine, and the answer does not have to match the case answer. Splitting the decision keeps a case migration from being held up by process models that need a different treatment. It also means you should inventory which case solutions call into BPM processes or decision services, because those calls must be re-pointed during cutover.
Ask DeployOpen or any implementation partner to scope three items in writing before you commit: the case UI (task lists, case views and document handling for your case workers), the content repository that will hold case documents in your own infrastructure, and the identity integration that maps your roles to case ownership and task assignment. The Flowable docs describe replacing the identity service with a custom implementation or an LDAP-based one, so confirm which directory you use and who will maintain that integration after go-live.
Which IBM case capabilities map to Flowable, and where the gaps are
This table maps the case capabilities an IBM Business Automation Workflow case solution typically relies on against Flowable's CMMN engine, its REST APIs and the components you assemble around them. Each row is marked as covered by the engine, covered by a companion component, or a gap your team builds. The main takeaway is that Flowable supplies the case execution core, while the designer, coaches, content store and case UI are work you scope and build separately.
| Capability | Flowable open source and what you build | Status |
|---|---|---|
| Case types and case definitions | CMMN case models are deployed and versioned through the CMMN engine and its REST API. Authors model in BPMN-style XML or a modeling tool you select. | Covered by the engine |
| Stages, plan items and milestones | CMMN stages, plan items and milestones execute in the case engine. Confirm the modeling tool you use can round-trip these elements. | Covered by the engine |
| Sentries and event-driven transitions | Entry and exit criteria are evaluated by the CMMN engine. Test complex sentries against your own cases before migration. | Covered by the engine |
| Human tasks and assignment | Human tasks are created and assigned by the engine. Work queues, inboxes and task forms are not included in the open-source edition and must be built. | Covered by a companion component |
| Case roles and identity lookup | The engine stores assignees and candidate groups. Replacing IBM's directory integration means implementing your own identity service, for example an LDAP reference implementation. | Covered by a companion component |
| DMN decision use inside cases | DMN decision tables are evaluated by the DMN engine and can be invoked from case tasks. Confirm rule coverage against your IBM decision assets. | Covered by the engine |
| Document attachments and content store | The engine references documents but does not provide a content repository in the open-source edition. Select and integrate your own store, with retention and access controls kept in your infrastructure. | Gap the team builds |
| Auditing and case history | History is recorded by the engine. Confirm the history level you need, and design retention and export for evidence requests. | Covered by a companion component |
| Case user interface | IBM's case designer and coaches are not part of Flowable's open-source edition. You build the case UI, or select a front end, and define the user experience. | Gap the team builds |
| Operations and monitoring | The Spring Boot starters expose monitoring endpoints for running processes. Dashboards, alerting and case-specific reporting are built on your own stack. | Covered by a companion component |
Which open-source option fits which case workload
Case management needs a CMMN engine, and the open-source choices differ mainly in where the engine runs and who builds the case user interface. The cards below set out each option, its build effort, UI ownership, vendor support and operating model, so you can match the choice to your case volume and team skills.
Flowable CMMN embedded in Spring or Java
The CMMN engine runs as a library inside your own Spring Boot or Java EE application, so case types, stages, milestones and sentries share the application's deployment, security context and database. Build effort is the highest of the options because your team writes the case services, the document handling and the entire case user interface. Check that your developers are comfortable owning the engine upgrade path, since each Flowable major version changes framework dependencies. Operationally, you run the engine as part of your application estate.
Flowable as a standalone REST service
You run the Flowable engine as its own service and call its REST APIs from your case front end and back-end systems, which keeps case logic separate from any single application. This suits organizations that want several applications to start and read cases without embedding Java in each one. Build effort is lower for integration but the UI is still yours to build, and you must secure the API layer and agree on how user identity reaches the engine. Confirm whether your team will supply the identity service that Flowable expects.
Flowable commercial editions for low-code design
Flowable's commercial products are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Teams that want business analysts to draw and adjust case models, rather than writing them in code, usually look here first. The cost is a recurring license or subscription, and you should ask the vendor which modules are included, how they are deployed in your environment and what support levels apply. Open-source users receive a community forum, while professional services and partners are sold separately.
Operaton and CIB seven for BPMN only
Operaton and CIB seven are BPMN-focused engines, so they do not replace CMMN case work. Use them when your estate is mostly sequential processes and the case items can be modeled as process paths, or pair them with Flowable for the case layer. Confirm the boundary early: a case model with ad hoc tasks, discretionary activation and sentries needs CMMN semantics that these engines do not provide. Check the support model for each before splitting work across two engines.
Case UI and document store ownership
Whichever engine you choose, the case worker screens, task inboxes and document views are your responsibility. Plan for a front end that shows case status, open milestones and attached files, and for a content store that you operate in your own infrastructure. Ask how the engine's task and variable APIs will be consumed and who owns access control on documents. This is the largest hidden effort in any open-source case project, so size it before committing to a platform.
How Flowable runs cases alongside the rest of the stack
A case instance in Flowable starts from a deployed case definition, which is the CMMN model you have authored and loaded into the engine. Starting a case creates a runtime record that holds the case variables and the plan items that are currently active, enabled or waiting for a trigger. Stages and milestones are tracked as plan items with their own states: a stage completes when its child tasks complete, and a milestone is reached when the engine evaluates its entry criteria as satisfied. Human tasks become visible to users through the Flowable REST API, which your case UI can call, or through an application you embed the engine in. Confirm in the Flowable docs for your target version which case endpoints and query patterns you will need, because the case UI you build will depend on them.
The database is the state store for every case, process and job, so the choice of database shapes operations. The Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and note that MySQL versions below 5.6.4 lack millisecond precision, which matters for timer accuracy. Timers and asynchronous jobs run through the async executor, which uses a thread pool on each node. Nodes coordinate through lock owners and lock expiration times stored in the database, so a job locked by a node that fails is recovered once its lock expires and picked up by another node. Ask your team to test this failover path under load, and to size the connection pool and database backups as part of the same exercise.
Identity is the third integration point. Flowable's identity management can be replaced by overriding the built-in identity service implementation or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Candidate groups and assignees on case tasks then resolve against your directory rather than a copy of users inside the engine. Decide early which directory is authoritative for roles such as case worker, supervisor or auditor, and confirm with your identity team how group membership changes will reach running cases. Your security team should review that access to case data follows these roles, since the engine enforces task assignment but the case UI and API layer must enforce who may open a document.
Running Flowable cases next to IBM BAW, Cloud Pak or other systems
Most case migrations do not switch everything at once. The cards below cover how a Flowable CMMN case service can run beside IBM BAW, the Cloud Pak estate and the identity and content systems you already operate, and where two engines create risk for users, documents and audit trails.
Split by case type, not by user
Run existing BAW processes and solutions to completion while new case types are built on Flowable's CMMN engine. Assign each case type a single owning system and record that decision in a routing table, so a case never has its lifecycle split across two engines. Check which in-flight BAW instances must finish in place and which new intake channels, such as forms or portals, send work to Flowable.
Call case services through REST
Flowable can be used over HTTP through its REST application, which lets BAW or other systems create case instances, start stages and query state without embedding the engine. Put an API gateway or thin integration layer in front of the case service so callers depend on a stable contract. Confirm which REST resources your integration needs and test their error handling under load.
Keep documents behind a content API
Case files often live in an IBM content store that the BAW estate already uses. Flowable's open-source edition does not include a content engine, so expose the existing repository through an API and store only document references in case variables. Decide who owns retention, versioning and access checks, and confirm that signed URLs or proxy calls respect the same permissions the users have today.
Reuse the identity provider in place
Keep one directory for sign-in and role assignment rather than creating a second user store for Flowable. Flowable's identity management can be replaced by implementing its identity service interface, and an LDAP reference implementation is provided. Map groups to case roles explicitly and document who can start, claim and close cases in each system.
Risks of shared users and documents
When two engines hold copies of the same user, document or task, they drift. A reassignment in one system may not reach the other, and a deleted account may still own open work. Assign a system of record for each entity type, sync only identifiers rather than full records where possible, and run a reconciliation report that lists orphaned tasks and documents.
Audit trails across two engines
An auditor may need one timeline per case even when the work spans BAW and Flowable. Define which events each engine records, correlate them with a shared case identifier, and store the combined trail in a system you control. Confirm with your compliance lead what evidence must be retained, for how long, and whether copies from the old engine are sufficient for closed cases.
Moving IBM case solutions to Flowable CMMN in phases
This sequence moves each IBM case solution to a Flowable CMMN case model, rebuilt UI and self-hosted content store in controlled stages, so that every case type is proven against samples and in-flight work finishes on IBM before that environment is retired.
Inventory case solutions, toolkits and coaches
The IBM solution owner and the business case owners list every case solution, its case types, stages, milestones, sentries, roles, document classes and the coaches or custom widgets that users see. Include the toolkits, custom Java code and external services each solution calls, and the number of open cases per case type. The step is done when the inventory is signed off by the business owner, and each item has a target disposition: rebuild, retire or keep on IBM until drained.
Export case definitions and map them to CMMN
The engineering team exports the case model definitions from the IBM environment using the export mechanism documented for its version, then maps each stage, task, milestone and sentry to its CMMN equivalent in Flowable. Some constructs, such as IBM-specific task types, coach bindings and proprietary expressions, have no direct CMMN element and must be redesigned by hand. The step closes when a written mapping sheet lists every construct as mapped, redesigned or dropped, and a reviewer has checked it against the IBM documentation for the exact version in use.
Rebuild the case UI and document integration
Developers replace IBM coaches and the case inspector with a user interface built on the team's chosen front-end framework, calling Flowable's REST API for case instances, tasks and variables. The document integration is rebuilt so that files are stored in the organization's own content store, with access checked against case roles and the content store's permission model. Confirm with the content store vendor which metadata and versioning features are available. The step is done when a pilot user can open, update and complete a case end to end and each document is linked to its case in the store.
Test stages, milestones and sentries on sample cases
QA staff build a set of sample cases covering normal paths, every sentry condition, manual activation, repeating stages and error conditions, then run each one on both the IBM solution and the Flowable model. They compare which stages activate, which milestones are reached and which tasks become available at each step, and log every divergence. The step is complete when all agreed scenarios match or the difference is accepted in writing by the business owner, and the test scripts are kept as regression tests.
Run new cases in parallel with IBM
Operations starts new cases for a limited set of case types in Flowable while the IBM environment continues to handle the rest. Each parallel run is reconciled daily against the business records and audit logs, so that status, ownership and document links match. Support runbooks for the Flowable job executor, database backups and restarts are tested in this period. The step is done when the reconciliation shows no unexplained differences for the agreed period and the operations team has signed off the runbooks.
Drain in-flight cases on IBM
The team stops creating new cases on IBM for each migrated case type and lets open cases complete on their existing model. For cases that must move, a documented decision is made case by case: finish on IBM, close with a recorded outcome, or restart in Flowable with the data carried over and the reason logged. Track the count of open cases per type until it reaches zero. The step closes when the IBM case inventory shows no open cases for migrated types and the audit trail for each decision is archived.
Retire the IBM environment with retained evidence
Before any IBM server, database or container is removed, the organization exports the audit history, case records and document indexes it must keep under its retention policy, and confirms with its compliance lead what must be readable after retirement. The IBM license and support contract is closed in line with the terms agreed with IBM. The step is done when the retained exports have been verified by a second person, access to them is restricted, and the environment is decommissioned according to the written plan.
What does replacing IBM case management cost and require?
What drives the cost of replacing IBM case solutions with Flowable?
The cost follows the scope of the case work, not the license line you remove. The main drivers are the number of case types, how many stages, milestones and sentry rules each case carries, how complex the case UI must be, how many documents and external systems the cases touch, how identity and roles map across the organization, how much testing the regulated processes need, and how the platform will be operated afterward. Each driver adds design, build and test effort. Ask any provider to price these drivers separately so you can see which ones move the total.
Which costs are one-time and which recur after a Flowable case migration?
One-time costs include inventory of existing case solutions, modeling cases in CMMN, building the case UI, integrating document storage and identity, testing, and migrating or draining in-flight cases. Recurring costs include infrastructure for the engine, database and content store, monitoring, backups, security patching, Java and framework upgrades, and staff time to handle change requests. If you buy a commercial Flowable edition, its subscription is a recurring cost on top. Ask for these as separate line items in any written quote.
Can an internal team replace IBM case management without outside help?
Yes, a team with Java, BPMN and CMMN experience can build on an Apache-2.0 engine, but the work is wider than the engine. Flowable's open-source edition does not include the authoring tools, coaches or case UI that IBM bundles, so your developers will build those screens and the surrounding services. Teams usually need skills in Spring or the servlet stack, database administration, identity integration, document management and secure deployment. Assess those skills honestly before committing, and consider a fixed-scope pilot to test the estimate.
How long does a case management replacement take?
Duration depends on scope, and no supplied figure applies to every estate. The number of case types, the depth of UI work, the volume of documents to migrate, and the number of integrations set the timeline more than the engine does. A small set of case types with a simple UI is a very different project from dozens of cases tied to regulated records. Ask for a timeline tied to written deliverables, and ask which milestones include user acceptance testing and cutover.
What does the client need to provide for a case migration project?
The client provides the decisions and access the work depends on. Typical inputs include:
- Case owners who can confirm stages, milestones, entry and exit criteria, and who may act on each case
- Domain experts who review case behavior and sign off on test scenarios
- Access to existing IBM case solutions, data exports and documentation
- Infrastructure access to the target cloud accounts, data centers or air-gapped networks, plus database and identity service connections
- Decision rights on document storage, retention periods and audit requirements
Delays usually come from slow answers on these items, so name owners for each one before work starts.
What testing and compliance evidence does a case replacement need?
Regulated case work needs documented test evidence for each case type, covering normal paths, exceptions, role-based access and document handling. Plan for functional testing of CMMN behavior, integration tests for document and identity systems, security testing of the case UI and APIs, and performance checks on expected case volumes. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Confirm early which assessment your organization must pass, since that decides the evidence format.
What operational work follows go-live of a self-hosted case platform?
After go-live, your team or a support partner runs the engine like any other production Java service. Recurring work includes applying security patches to the engine and its dependencies, upgrading across major versions, monitoring running cases and asynchronous jobs, backing up the database and content store, and rehearsing restores. Flowable's async executor coordinates jobs across nodes through lock expiration stored in the database, so cluster and database operations need an owner. Decide whether that work stays in-house or moves to a retainer before you sign the build contract.
Does DeployOpen handle the whole case management replacement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. For case management, that can include the CMMN models, the case UI, document and identity integrations, testing and operating support. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.
When keeping IBM case management is the better choice
Keeping IBM case management is the better choice when your case work depends heavily on IBM's own authoring tools and the coaches built on them, and your organization has no appetite to build a case user interface. Flowable's engines execute CMMN case models, but the open-source edition does not include the modeling, visual debugging and case front end that a business team would use day to day. Flowable's open-source release notes for version 7.0.0 state that the UI applications and the form and content engines were removed from the engine line, so the case worker screens, stage dashboards and document handling become your build. If the people who maintain your cases cannot be handed a new, custom UI without a project of their own, staying on IBM avoids a rebuild that the business would have to fund and test.
Contractual timing can also make a migration premature even when the technical case for Flowable is sound. A Cloud Pak for Business Automation subscription with a remaining term, an enterprise agreement that bundles IBM support, or a regulator-facing change freeze in a critical case area all change the sequence. Confirm the exact end dates, renewal notice periods and any exit or transition terms with IBM and your procurement team before planning any cutover. Ask whether the current contract allows a parallel run and read-only access to historical case data after termination.
Before deciding, verify in your own environment. Inventory the case solutions and count how many use coaches, custom extensions or IBM-specific document integrations. Check whether any case types depend on the Content Manager or FileNet content store, and confirm which databases, Java runtimes and identity sources the platform uses today. Ask your platform team whether they can run and patch a stateful Java service with a database-backed async executor, which Flowable documents for multi-node operation. If the answers show heavy coupling and no team to own the UI, IBM remains the lower-risk choice for now.
How DeployOpen scopes a case management replacement
The sequence below shows how a case management replacement is agreed in writing, built in your infrastructure, tested, documented and kept supported, so each stage ends with a result your team can check. Scope, deliverables and timelines are fixed before work starts, and a quote follows from that written scope.
Agree the written scope and quote
DeployOpen and your team agree in writing which case types, stages, milestones and integrations are in scope, along with deliverables, responsibilities and timelines. Your team should ask for a quote that follows directly from that scope and lists each component separately: discovery, Flowable build, UI, document integration, hardening, testing, documentation and any retainer. The step is complete when both parties have signed the scope and the exclusions are written down.
Inventory the case solutions
DeployOpen works with your team to list every existing case solution, its case types, stages, milestones, entry and exit criteria, roles, deadlines, documents and the systems it calls. Each case type is classified by how much of it is truly case-driven and how much is a fixed sequence that belongs in BPMN or a plain service. The output is a case inventory with a sign-off from the process owners, showing which cases move to Flowable, which are retired and which are deferred.
Deploy Flowable in your infrastructure
DeployOpen installs the Flowable engines in your own cloud account, data center or air-gapped network, using the deployment model that fits your estate: embedded in a Spring application, run as a standalone service, or called over the REST APIs. It configures a supported database for the engine state, sets up the async executor and lock handling for multi-node operation, and connects identity through your existing directory using Flowable's identity service interface. The step closes when a test case runs end to end in a non-production environment.
Model cases in CMMN and integrate documents
DeployOpen models each approved case type in CMMN, with stages, milestones, sentries and human tasks, and connects the case to processes and decision tables in BPMN and DMN where those apply. Documents stay in your own content store: the integration writes references, metadata and access rules, and never copies files into a vendor store outside your control. Your team checks the models against the inventory, and the step is complete when every in-scope case type runs with its documents resolved from your store.
Build the case user interface
Flowable's open-source edition does not include a case UI, so DeployOpen designs and builds the work screens your caseworkers need: case lists, case detail, task queues, document panels and audit views, built on your chosen front-end stack and tied to the engine's REST APIs. Your team reviews the screens with real caseworkers using test cases, and the step closes when those reviews are recorded and the open items are agreed.
Harden, test and document
DeployOpen hardens the deployment for your baseline, covering access control, secrets handling, network segmentation, logging, backups and upgrade procedures, and runs functional, integration and security testing on the case flows and APIs. Test results, configuration records, architecture notes and operating runbooks are delivered in writing. The step is complete when the open findings are fixed or accepted by your risk owner and the documents are handed over.
Prepare evidence for compliance assessments
DeployOpen assembles the evidence your compliance team needs to show how the case system is configured and controlled, such as access reviews, change records, test results and backup restore tests. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Your compliance lead confirms with the auditor which evidence they will accept before the step is closed.
Offer ongoing support as a retainer
After go-live, DeployOpen can provide ongoing support, upgrades, continuous testing and patching under a retainer agreed in writing, so your team has a defined contact for engine and UI changes. Your team should confirm the response expectations, upgrade scope and what happens when a Flowable release changes the platform requirements before signing. The retainer is complete when the support scope is documented and the handover to your operations team is accepted.
