Migrate from IBM Business Automation Workflow to Flowable: what the move involves
Moving from IBM Business Automation Workflow to Flowable is a re-platforming of process logic, user interface and data, not a file export. The usual trigger is a renewal, exposure to the WebSphere or Cloud Pak for Business Automation lifecycle, or a data residency requirement that the current estate does not meet. The work is typically owned by a platform team that runs the Java and Kubernetes layer, BPM engineers who redraw the models, and business analysts who confirm that the redrawn processes and cases still behave as the business expects. Many organizations also bring in an implementation partner for the engine integration and the cutover, which is a scope decision to make early and write down.
Flowable's open-source edition is an engine set. It gives you the BPMN process engine, the CMMN case engine and the DMN decision engine, with Java and REST APIs, under Apache 2.0. It does not give you the authoring studio, the process apps, the coaches or the case worker interface that IBM bundles with the product. Those become components your team must choose, build or buy, and their cost usually decides the project's size more than the engine does. Flowable also sells commercial editions built on the same engines, so confirm with Flowable which parts of the UI and modeling tooling you would license and which you would build yourselves.
The short answer on effort and risk depends on three inventory results: how many process apps, toolkits and case solutions are in use, how much of the logic sits in custom Java or integration code, and how many instances are still running when the cutover date arrives. Ask your team to produce that inventory before any quote is requested, because a written fixed scope depends on it. The highest risks are in-flight instances that must finish on the old runtime, user interfaces that have no direct replacement, and identity and access rules that must be rebuilt, since Flowable's identity management is replaced through its own service interface.
Which IBM BAW capabilities map to Flowable and which need rework
This table maps the main IBM Business Automation Workflow capabilities to their Flowable equivalents and marks each as clean, needs rework or gap. Treat IBM-specific constructs as items to confirm with IBM or your own inventory, not as assumed equivalents. The main takeaway is that the engine-level work (BPMN, CMMN, DMN, REST) maps well, while the authoring UI, coaches and low-code tooling are where most of the project effort sits.
| Capability | Flowable equivalent | Status |
|---|---|---|
| BPMN process execution | Flowable BPMN engine, embedded or run as a service | Clean: BPMN 2.0 models redeploy, but confirm any IBM-specific extensions in your models |
| CMMN case management | Flowable CMMN engine with case definitions, stages and milestones | Needs rework: IBM case solutions must be redrawn as CMMN and case data mapped to your own store |
| DMN decision rules | Flowable DMN engine for decision tables | Needs rework: confirm decision table syntax and any IBM business rule or decision service constructs |
| REST APIs | Flowable REST application or REST starters, with Java APIs | Needs rework: client calls and endpoints must be rewritten against Flowable's API |
| Embedded Java use | Flowable JAR in Java SE, servlet containers, Spring or Java EE servers | Clean: Java service tasks and listeners port with adjustment for the Flowable API |
| Timers and asynchronous jobs | Flowable async executor with database lock owners and expiry | Needs rework: validate job behavior and cluster settings under your database |
| Identity integration | Replaceable IdmIdentityService with an LDAP reference implementation | Needs rework: write or configure the identity service for your directory and group model |
| Coach-based UI and process apps | Not included: build your own UI or use a commercial Flowable product | Gap: plan UI development, forms and task lists as a separate workstream |
| Low-code modeling and visual debugging | Excluded from Flowable's open-source edition, available in its commercial products | Gap: plan for tooling you will build, buy or operate without |
What moves cleanly and what does not carry over
The process models move more easily than the runtime around them. BPMN 2.0 process diagrams and CMMN case models are open standards, so the flows, gateways, timers, human tasks and case stages can usually be redrawn in Flowable's engines with the same intent. DMN decision tables follow the same pattern. What does not move is everything IBM Business Automation Workflow wraps around those models: toolkits, process applications and their snapshots, coach-based screens, service integrations built in its authoring tools, and the proprietary configuration that binds them together. Inventory each of these as its own line item, because each one has a different rebuild path and a different owner. Ask your IBM contacts and your internal teams to confirm which artifacts are in use, since a model that looks portable can depend on a coach, a business object or a custom service that has no direct equivalent.
Plan for the UI and document work as a new build, not a conversion. Flowable's 7.0.0 release notes state that version 7 removed the UI applications and the form and content engines, so Flowable provides the process, case and decision engines and their REST APIs, while forms, task screens, document upload and storage, and case views become your team's own application code. Decide early which front end, form technology and content store you will use, and whether those components will run in your own infrastructure. Each coach or form you retire needs a matching screen, validation rule, permission check and audit behavior, which is often where the migration effort concentrates. Confirm with your architects how many screens are in scope before you size the project.
Check the runtime version before you design the embedding layer. The Flowable 8.0.0 release notes describe an upgrade to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. If your target application runs on Spring Boot 3, you will either stay on a Flowable 7.x release, which uses Spring Boot 3, or move the application to Spring Boot 4 as part of the same project. Also confirm the JSON library your integrations expect, since Flowable 8.0.0 makes Jackson 3 the default with a Jackson 2 compatibility layer, and check any JUnit 3 or 4 based tests, which 8.0.0 no longer supports. Record the decision in the architecture file before anyone writes a line of migration code.
Which data and integrations to move, and which to rebuild
Each item below needs a different decision: move it, transform it, or rebuild it on Flowable. Process state, identities, decisions, documents and external calls each have a different documented path, and IBM's export formats are the first thing to confirm before any scope is agreed.
In-flight process instances
Running instances hold token position, timers and pending jobs, and they cannot simply be re-imported as BPMN files. Plan a drain-or-migrate choice per process: let instances finish on IBM where they are short-lived, or map active states to a Flowable process definition version for long-running ones. Confirm with IBM which runtime state can be exported at all. Flowable's async executor handles timers and jobs across nodes, so test that behavior under your cluster setup before cutover.
Task and variable data
Task assignments, process variables and form data sit in IBM's database schema, which Flowable does not read. Inventory every variable type that business logic depends on, then write a one-time extract that maps them to Flowable's runtime and history tables. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so confirm your target database is on that list and that the MySQL version meets the precision requirement in the configuration docs.
Identities and groups
Process roles such as candidate groups and users come from IBM's directory setup, typically LDAP or a federated identity store. Flowable lets you replace the identity layer by implementing its IdmIdentityService interface, and it ships an LDAP identity service as a reference. Decide whether group membership is read live from your directory or copied into the engine, because stale copies can route tasks to people who have left the role.
Decision tables
IBM decision services and rule tables must be re-expressed as DMN models that Flowable's DMN engine executes. Export any hit policies, input expressions and data types from IBM, then rebuild each table and test it against recorded inputs and expected outputs. Do not assume IBM's rule export is directly importable, and confirm the export format with IBM before budgeting this work.
Document references
Case and process documents usually live in IBM's content store, and the engine holds only references to them. Flowable's form and content engines were removed in version 7, so document handling is a separate integration. Keep the references, migrate the binaries into a store you control, and rewrite each reference so that it resolves after cutover. Check access rules and retention for each document class before you move anything.
External service calls
Service tasks, REST calls and adapters to back-end systems have to be rebuilt as Flowable service tasks, delegates or REST integrations. Document each endpoint, authentication method and error-handling rule, then test retries and timeouts against the target systems. Flowable exposes its engines through REST APIs, which helps where other systems will call the process layer directly.
The migration sequence from inventory to decommission
The sequence moves IBM Business Automation Workflow estate to Flowable one process family at a time, with each step producing a signed-off artifact so that the WebSphere or Cloud Pak components can be retired only after in-flight work has finished. It keeps the IBM platform authoritative until the Flowable path has proven itself in production.
Inventory process apps, toolkits and in-flight volumes
Your architecture team, with the process owners and the IBM administrators, lists every process application, toolkit, case solution, business rule, coach or UI component, and integration (services, adapters, databases, document stores and identity connections). For each item, record the owner, the business purpose, the version in use, and the count of running instances and open cases. The output is an inventory register that classifies each process family as migrate, rebuild, retire or keep on IBM for now. The step is done when process owners have signed the register and every integration has a named owner.
Redraw a pilot process in BPMN or CMMN
Choose one low-risk process family, ideally one with a clear BPMN flow and few custom coaches, and redraw it in BPMN on Flowable. Where the work is driven by case state rather than a fixed sequence, model it in CMMN instead. Implement the service tasks, DMN decisions and identity lookups, and build a replacement user interface in your own front-end stack. The output is a tested pilot with recorded test cases, a comparison of outputs against the IBM version using the same inputs, and a list of gaps the team found. Confirm that the Flowable edition you choose meets your support and tooling needs before the pilot is extended.
Run in parallel and drain IBM instances
Route new starts for the pilot family to Flowable while existing IBM instances continue to completion on the IBM platform. Use a routing layer, such as an API gateway or a front-end feature switch, so that new requests reach the right engine, and log every routing decision. Monitor both engines for divergence in outcomes, timer behavior and error rates. The output is a drain report that shows the count of IBM instances remaining, their expected completion pattern, and any instances that need manual handling. Do not stop the IBM runtime until this report shows no open instances for the family.
Cut over each process family on a runbook
For each remaining process family, repeat the redraw, parallel run and drain steps, then cut over traffic under a written runbook. The runbook lists the cutover window, the rollback criteria, the person who can approve rollback, the data reconciliation checks, and the communication to users and downstream systems. Keep the IBM definitions available for rollback until the family has run cleanly through its agreed review period. The output is a signed cutover record for each family and an updated inventory register that marks each item as migrated or retired.
Decommission WebSphere and Cloud Pak components
After the last family is cut over and no IBM instances remain, export the audit and history data that your retention policy requires, archive IBM databases and content stores, and remove the IBM applications, toolkits and Cloud Pak components from the cluster. Revoke service accounts and certificates tied to the IBM platform, and update your asset, license and disaster recovery records. Confirm with your license holder what notice and termination steps apply to your subscription. The output is a decommissioning record with evidence of data retention, removed components and revoked credentials, which your compliance team can use in future assessments.
What drives migration cost and duration, and how to hold each down
This table lists the main drivers of a move from IBM Business Automation Workflow to Flowable, why each one changes effort, and what keeps it contained. Read it as a checklist for the written inventory you will hand to any implementation partner. Open-source licensing is not a cost line, so the work to plan is engineering, UI, testing, hosting and support.
| Driver | Why it moves cost or effort | How to hold it down |
|---|---|---|
| Number and complexity of process apps and case solutions | Each process app, toolkit and case solution is redrawn in BPMN or CMMN, and branching, sub-processes and human tasks multiply the modeling and test work. | Inventory every app and solution with its process count, step count and integrations, then retire unused ones before scoping. |
| Custom Java in coaches and services | Java inside coaches, service flows and custom code has no direct equivalent and must be rewritten as Flowable service tasks, listeners or Spring beans. | Count custom classes and external calls up front, and reuse shared libraries instead of rewriting per process. |
| In-flight instance volume | Running instances must finish on the old runtime or be migrated, and migrating state is more involved than redeploying definitions. | Measure active instances by process and age, then let short-lived work drain while only long-running cases are migrated. |
| Identity and directory integration | Users, groups and role-based task assignment must map to Flowable's identity service, which you implement or override yourself. | Confirm which directory is the source of truth, and plan an LDAP or custom identity service as a reference before coding. |
| Document and content integration | Case documents currently held in IBM's content store must move to your own store and be linked from case instances. | Decide the target store early, script bulk export, and limit migration to documents still referenced by open cases. |
| UI rebuild scope | Coaches and IBM's authoring UI are not carried over, so every user-facing form, task list and case screen needs new front-end work. | Build a shared component set for forms and task lists, and prioritize screens used by the largest user groups. |
| Database and Java platform choices | Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and it runs on a Java 17 or later stack, so choosing a database you already operate reduces new operational work. | Reuse a supported database your team runs, confirm version requirements in the Flowable configuration docs, and avoid a new platform layer. |
| Testing and cutover | Every redrawn process needs functional, integration and parallel-run testing, and cutover planning covers the drain period and rollback. | Derive test cases from the current process inventory, and agree the acceptance criteria in writing before work begins. |
What usually goes wrong in this migration
Most failed BAW-to-Flowable migrations fail on process, not engine: teams export models, underestimate the UI, and leave instances running on a retiring estate. The cards below cover the risks we see most often, each with a check to run before the cutover plan is signed off.
Treating the migration as a model export
BAW process applications bundle BPMN models with coaches, business object definitions, service integrations and toolkit-specific logic. Exporting diagrams and deploying them to Flowable keeps the shape of the flow but drops everything that makes it run. Inventory each process app, toolkit and case solution, then classify its parts as redraw, rebuild or retire before estimating work. Ask the team who owns each dependency.
Underestimating the coach UI rebuild
Coaches and coach views are the user interface of most BAW solutions, and Flowable provides no UI of its own in the open-source edition. Each coach must be replaced by a front end your team builds and hosts, with its own authentication, validation and task lists. Count screens per process and reserve design and testing time for them, separately from engine work.
Letting IBM instances run past retirement
In-flight instances on BAW keep running on the estate they started on, so a cutover date alone does not retire anything. Set a drain rule per process: new starts stop on a fixed date, and existing instances either finish or are migrated by an agreed method. Confirm with IBM which Cloud Pak version and lifecycle dates apply to your environment before fixing that date.
Mismatched timer and async behavior
Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. BAW timers and parallel-job semantics do not map one to one, so a timer that fired once on BAW may fire on several nodes or late after a lock expires. Test timers, boundary events and retries under multi-node load, and set lock and pool settings deliberately.
Unclear ownership of Spring Boot and Java upgrades
Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3, and it made Jackson 3 the default JSON library. If your application wraps Flowable, every Spring and Jackson upgrade becomes a Flowable upgrade too. Name one owner for the application's framework versions, record who approves each engine upgrade, and schedule upgrades rather than letting them drift.
No rollback path
Once new instances start on Flowable and users work in the new UI, returning to BAW may not be practical. Define rollback before cutover: keep the BAW environment readable and licensed for the drain period, keep database backups that can restore it, and decide in advance which failures justify a return. Rehearse the rollback on a copy of production data, not only the forward path.
How the migration differs by estate size and starting point
A small estate usually has a handful of process applications, a few integrations and a limited set of users. The migration is mostly a rebuild of known processes, so the inventory can stay short and focused on what is live. Flowable's engines run embedded in a Spring or Java application or as a standalone service with REST APIs, which suits a single team that owns the whole stack.
- Inventory depth: List each process application, its owner, its start channels and its open instances. Confirm which decision tables and human tasks it relies on.
- Parallel run: Keep the IBM process running until in-flight instances finish or are moved. The window is set by your longest-running process, not by the estate size.
- UI scope: Expect to build one task list and one form set. Confirm whether the existing coach screens can be retired or must be reproduced.
- Identity: Map the IBM group and role model to your directory once, and confirm how Flowable's identity service will read it.
- Operations: A single database, a single application and one backup routine are usually enough to start.
Confirm with your own inventory whether any process is a case in disguise, because that changes the tooling you need.
A large multi-application Cloud Pak for Business Automation estate usually spans many process apps, shared toolkits, several teams and multiple environments on OpenShift. The inventory has to cover the dependencies between applications, not just each one on its own. Migration is typically wave-based, with groups of applications moved by business domain and dependency order.
- Inventory depth: Record shared toolkits, common services, data sources and the business calendar behind each process. Map which applications call each other.
- Parallel run: Plan longer coexistence because dependent applications cannot all move in the same week. Define the cutover order for each wave.
- UI scope: Coaches are often reused across many applications, so the UI rebuild is a shared component effort rather than one screen per process.
- Governance: Agree on naming, versioning and deployment standards for the Flowable services before the first wave starts.
- Operations: Confirm how the async executor's lock handling behaves across the nodes you run, and test failover before you rely on it.
Ask for a written wave plan with the dependency map before any cost or schedule is agreed.
Estates still running the WebSphere-based traditional runtime have their own packaging, deployment scripts and server configuration. Some teams consider moving to the container runtime first, but the artifacts from that runtime do not automatically carry into a Flowable build. The migration is best treated as a rebuild on standard Java, with the WebSphere configuration retired instead of ported.
- Inventory depth: Catalog the EAR and deployment artifacts, the WebSphere-specific resources and any custom Java code bound to the server. Note which of them the process logic actually uses.
- Parallel run: Keep the WebSphere runtime available for in-flight work during the cutover. Confirm how instance state will be drained, since no direct instance migration to Flowable is supplied in this page's sources.
- UI scope: Expect the same user interface rebuild as other estates, with the added step of replacing any WebSphere-hosted pages.
- Platform: Decide early whether the target runs on a servlet container, Spring Boot or a Java EE server, because the Flowable getting started guide lists all three.
- Database: Confirm which supported database Flowable will use and test the schema on your own data volumes.
Check which custom code depends on WebSphere APIs, because that code decides how much of the estate can be reused.
A team that also runs case management needs a second modeling standard alongside BPMN. Flowable provides a CMMN engine for case types, stages and milestones, and a DMN engine for decision rules. The inventory must separate structured processes from case solutions, because each needs a different model, a different UI and different test cases.
- Inventory depth: Tag every IBM artifact as a process, a case or a decision. Record the documents each case handles and where they are stored.
- Parallel run: Case instances often stay open for much longer than routine processes. Plan the drain for cases separately from the process queue.
- UI scope: Case work needs a case worklist, a document view and stage-level status screens. Confirm how much of this you will build yourself, since Flowable's commercial products add low-code tooling that the open-source edition does not include.
- Documents: Decide where content lives before cutover, because the case UI will link to an external content store that you run.
- Testing: Build test cases for milestone and stage transitions, not only for the happy path.
Confirm with the business owners which cases are still active, since they set how long the case estate must stay running.
Questions buyers ask before moving off IBM Business Automation Workflow
What drives the cost of moving off IBM Business Automation Workflow to Flowable?
The cost depends mostly on how much process logic you must redraw, how much custom code and UI you must rebuild, and how many of your processes depend on IBM-specific features. Each component is paid differently. Licensing for Cloud Pak for Business Automation and the WebSphere or OpenShift platform under it recurs, while Flowable's open-source engines carry no license fee. Your costs are then labor for redrawing processes in BPMN and cases in CMMN, building a replacement for coaches, new infrastructure, and support. Ask any provider for a quote that separates one-time migration work from recurring hosting and support, and that states which Flowable edition, if any, it assumes.
How long does a migration from IBM Business Automation Workflow usually take?
No duration can be stated from the sources available for this page, so confirm it against your own inventory. The main drivers are the number of process apps, toolkits and case solutions, how many processes are rebuilt rather than retired, how much of the user interface must be rewritten, and how many integrations depend on IBM-specific services. Teams with a small set of well-documented processes generally finish sooner than teams with many coupled case solutions. Most engagements are fixed-scope, so the written scope should list the inventory, the deliverables and the timeline before work starts.
What does our team need to supply for the migration?
You need to supply process owners who can confirm the business rules behind each process and case, access to the existing process apps and their data, and staff who understand the target systems, including identity, document storage and the databases you plan to run Flowable on. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so your database team must choose and operate one. You will also need an owner for the case UI and for the infrastructure on which Flowable runs. Confirm these responsibilities in the written scope so no gap appears during build.
Can our in-house team migrate from IBM Business Automation Workflow to Flowable without a partner?
Yes, a capable internal team can do it, provided it has Java and Spring experience, BPMN and CMMN modeling skills and time to rebuild the user interface. Flowable is Apache-2.0 licensed and can be embedded in a Java application or run as a standalone service with REST APIs, so the engineering skills are standard Java skills. The harder parts are usually the inventory of IBM-specific artifacts, the rebuilt UI and the operational runbooks. A partner can take on any of these as a fixed-scope piece while your team keeps ownership of the processes.
How are in-flight process instances handled during the move?
In-flight instances are the riskiest part of the move, and the usual approach is to drain them. You stop starting new instances on IBM Business Automation Workflow, let running work finish or map it explicitly to the new model, and then retire the old runtime. Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates multiple nodes through lock owners and lock expiration times stored in the database, so expired locks are recovered and jobs are picked up by other nodes. Test this recovery behavior in your own environment, and confirm in the written scope how long-running instances that cannot be drained will be handled.
What do Flowable's commercial editions add beyond the open-source engines?
Flowable states that its commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Open-source users get a community forum, while professional services and partners are offered separately. Flowable also notes that version 7 removed the UI applications, the form and content engines, and async history, so teams that relied on those features should decide early whether to rebuild them or buy a commercial edition. Ask Flowable for current licensing terms before you decide.
How DeployOpen scopes, runs and supports the Flowable migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from IBM Business Automation Workflow to Flowable, we start with a written, fixed scope that covers the process estate, then build, test and hand over the Flowable platform in your environment.
How we scope
- Inventory of process apps, toolkits, case solutions and their running instances, agreed in writing before work starts
- Written scope listing which BPMN processes, CMMN cases and DMN decisions move to Flowable and which are retired
- Decisions on the UI replacing IBM coaches, identity source and database, recorded as deliverables in the scope
- Engagements are fixed-scope, and ongoing support can follow as a retainer once the scope is closed
How we build
- Redraw in-scope processes as BPMN and cases as CMMN on Flowable engines, with DMN decision tables kept under test
- Deploy Flowable as an embedded Java application, a Spring Boot service or the REST application, in your own cloud or data center
- Configure the async executor and database for multi-node operation, and test timers and job recovery before cutover
- Build the replacement task and case UI and connect identity through the Flowable identity service interface
How we hand over
- Documentation of the deployed architecture, configuration, process models and operating runbooks for your team
- Drain plan for in-flight IBM instances, with cutover and rollback steps written out for each process family
- Retirement checklist for the WebSphere or Cloud Pak estate, including data retention and access removal
- Knowledge transfer sessions with your engineers so operating the Flowable platform stays with your team
How we support
- Post-cutover support window scoped in advance, covering incidents on the Flowable platform in your infrastructure
- Upgrade planning for future Flowable releases, including breaking changes in major versions, handled as scoped work
- Continuous security testing of the process applications and APIs available as a separate retainer
- Ask for the support terms, response expectations and retainer scope in your written quote before work begins
