Red Hat PAM vs Flowable: which to choose

Is Flowable a good Red Hat PAM alternative for your team?

Flowable is a good long-term home for a Red Hat PAM estate when your team wants an embeddable, Apache-2.0 licensed engine for BPMN, CMMN and DMN and is prepared to own the Java application that runs it. Flowable fits well when processes are the center of the design, when case management and decision tables are simpler than the rule base you have today, and when developers can deploy the engine inside Spring Boot or a servlet container, or run it as a standalone service over its REST APIs. Staying in the jBPM lineage, or moving to IBM's successor, fits better when your estate depends heavily on Drools rule sets, when business analysts work daily in Business Central, or when procurement requires a vendor-backed support contract with a named escalation path.

The decision turns on four factors: rule complexity, modeling tooling, in-house Java skills and support expectations. Count the Drools rules and DMN models you actually execute, and mark which ones would need to be rewritten as Flowable decision tables. Next, list who edits processes today. If authors depend on Business Central, note that Flowable's visual modeling, debugging and governance tooling sits in its commercial editions, so you must price that line item separately from the open-source engine. Then check whether your team has the Java and Spring operations skills to upgrade the engine itself. Flowable 8.0.0 requires Spring Boot 4 and removes support for Spring Boot 3, so an upgrade touches your application code, not just a library version.

Before choosing, confirm three things with Flowable directly and in your own environment: which database types and versions your production stack uses, how the async executor behaves across the nodes you plan to run, and whether identity integration through its LDAP reference implementation matches your directory. Also ask what the open-source community forum covers compared with the professional services and partner support you would need to buy. Then run a proof of concept on a representative process with its in-flight instances, so you learn the real cost of migration before committing to a path.

Which option fits which scenario

This table maps common Red Hat PAM team situations to the option that fits them better, Flowable or the Apache KIE lineage (jBPM, Drools, Business Central). Read each row against your own estate: the condition column tells you when the advantage actually matters, and the Spring Boot row is a hard gate to check first.

Scenario	Better fit	Why and when it matters
BPMN processes embedded in Spring Boot services	Flowable (7.x on Spring Boot 3, or 8.0.0 on Spring Boot 4)	Flowable ships Spring Boot starters for its process, CMMN and DMN engines and an actuator endpoint at /actuator/flowable. Matters when processes run inside your services rather than on a separate process server.
Heavy Drools rule sets	Apache KIE (Drools)	Drools is the rule engine of the KIE lineage, and Flowable's DMN engine covers decision tables more than complex rule sets. Matters when rule logic is the core of the application and must move with minimal rewrite.
Teams that rely on Business Central for authoring	Apache KIE (Business Central successors are still maturing)	Apache KIE 10.2.0 replaced the legacy GWT-based BPMN editor and removed the classic BPMN and DMN editors, so authoring workflows change. Confirm with the KIE project which editor your business users will use before choosing.
Teams needing CMMN case management	Flowable	Flowable's engines include CMMN for case management alongside BPMN and DMN, all Apache-2.0. Matters when cases with ad hoc tasks are part of your Red Hat PAM scope. Confirm how far Apache KIE covers your case patterns.
Regulated buyers who need a contracted vendor	Flowable (commercial editions) or IBM's successor	Flowable sells commercial editions built on the same engines, with professional services offered separately. Apache KIE is incubating at the ASF, which the KIE site says does not necessarily reflect code completeness or stability. Ask each vendor for the support terms in writing.
Spring Boot 3 codebase	Flowable 7.x	Flowable 8.0.0, released February 27, 2026, drops Spring Boot 3 compatibility. The Flowable 7.x line remains the Spring Boot 3 path. Keep on 7.x if your services cannot move to Spring Boot 4 yet.
Teams ready for Spring Boot 4	Flowable 8.0.0	Flowable 8.0.0 upgrades to Spring Framework 7 and Spring Boot 4, uses Jackson 3 by default and drops JUnit 3 and 4 support. Plan test rewrites and dependency updates before the move.

How Flowable runs next to your applications

Flowable gives Red Hat PAM teams two deployment shapes, and the choice shapes everything after it. The first is embedded: the engine ships as a JAR inside a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server, so process execution shares the application's JVM, release train and deployment pipeline. The second is standalone: the Flowable REST application runs as a separate service that other systems call over HTTP. Most jBPM estates today run as KIE Server behind Business Central, which is closer to the standalone shape. Teams that choose the embedded route will own service boundaries, versioning and scaling of the process layer that Business Central previously handled for them, so the decision should be made per workload before any BPMN model is re-validated.

Clustering is where the operating model matters most. Flowable's async executor runs timers and asynchronous jobs from a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. If a node fails, expired locks are recovered and other nodes pick up the jobs. Confirm that your DBA can support the database types Flowable lists: H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. The Flowable configuration docs also note that MySQL versions below 5.6.4 lack millisecond precision, which affects timer accuracy. Load-test timer-heavy processes on your real database before going live, because lock behavior is a database concern as much as an engine one.

For Spring Boot shops, Flowable provides starters for all engines, for REST, and for the individual process, CMMN and DMN engines, with support for Spring Boot 4.x. The actuator endpoint at /actuator/flowable exposes running process information for monitoring, so decide early which dashboards and alerts replace the monitoring your KIE Server estate has today. Identity is another operational decision: Flowable lets you replace its identity management by implementing the IdmIdentityService interface, with an LDAP implementation provided as a reference. Map your current user and group sources, including any roles Business Central enforces, to that interface before migration planning is final. Check the Spring Boot version against your framework standard first, since the Flowable 8.0.0 release moved to Spring Boot 4.

Capabilities side by side: Red Hat PAM and Flowable

This table compares the capabilities a Red Hat PAM team typically relies on with what Flowable's open-source engines provide. Where a Red Hat PAM capability is not covered by the researched facts, the cell says to confirm it against current PAM documentation. Read the gaps as migration work to plan, not as a verdict on either product.

Capability	Red Hat PAM (jBPM, Drools, Business Central)	Flowable open source
BPMN process execution	jBPM engine runs BPMN 2.0 processes; confirm the supported BPMN elements for your PAM 7.x version	BPMN engine, Apache-2.0, embedded in a Java application or run as a standalone service
CMMN case management	Case management is part of the jBPM lineage; confirm the CMMN coverage in your PAM release	CMMN engine included in the open-source distribution
DMN decision tables	DMN models run through the Drools and jBPM stack; confirm DMN version support in your PAM release	DMN engine for decision rules; suited to simpler decision tables
Business rules engine	Drools provides the full rules engine, which is the main reason many teams adopted PAM	No equivalent full rules engine in the supplied facts; rule-heavy logic usually stays in Drools or moves to Apache KIE
Authoring UI	Business Central is the authoring environment; confirm what your version offers for editing and deployment	Version 7.0.0 removed the UI applications from the open-source edition; modeling UI comes from commercial Flowable Design or Flowable Work
Low-code modeling and governance	Confirm the governance and approval features available in your PAM release	Commercial Flowable editions add low-code modeling, visual debugging, security controls and governance
Visual debugging and monitoring	Confirm the process monitoring and debugging tools in your PAM documentation	Open-source engines expose a Spring Boot actuator endpoint at /actuator/flowable for monitoring running processes; visual debugging is a commercial feature
REST API	Confirm REST endpoints available through KIE Server or the PAM runtime	REST application and REST starters available for all engines
Identity integration	Confirm the directory and SSO options in your PAM version	IdmIdentityService can be replaced, with an LDAP reference implementation provided
Database support and clustering	Confirm supported databases and clustering model for your PAM release	H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server; the async executor coordinates nodes through database lock expiration

Where process data lives and who controls the runtime

Flowable runs inside infrastructure you choose, so the location of process data and the people who operate the runtime are decisions you make rather than ones a vendor makes for you. The four cards below take those decisions in turn, each tied to the condition that makes it matter for your Red Hat PAM vs Flowable evaluation.

Data location in your database

Process variables, history and job tables are written to the relational database you configure. Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types. Data residency matters most when process payloads carry personal data, such as customer identifiers or case notes, because every variable a process stores lands in that database. Confirm with your security team the backup schedule, encryption at rest and audit logging for the database you choose, since Flowable does not provide these controls on its own.

Hosting models you control

Flowable can be embedded as a JAR in a Java SE application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server. It can also run as a standalone service over HTTP through the Flowable REST application. Embedding keeps the engine inside a service you already operate, while standalone hosting suits teams that want one shared process service. Choose based on who owns the release cycle, and plan how the engine will run on your own Kubernetes or virtual machine estate.

Identity through your directory

Flowable does not ship a user store you must adopt. Its identity management can be replaced by overriding the default IdmIdentityServiceImpl class or by implementing the IdmIdentityService interface, and the docs provide an LDAP identity service as a reference. If your workforce identities sit in a corporate directory, the integration work is building or adapting that service so task assignment and candidate groups reflect your real roles. Confirm who maintains this code, how it is tested, and how departing staff are removed from open tasks.

Compliance evidence and attestation

Flowable helps prepare the technical controls and evidence an assessment will examine, such as access configuration, logging, backup records and change history for your process models. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Plan for this split early: decide which controls your auditor will test, which evidence your own team generates, and which records must be retained in the database you run.

Editions and licensing: what you get from each path

The Flowable open-source engines are licensed under Apache 2.0, which allows you to use, modify, embed and redistribute the BPMN, CMMN, DMN and event registry engines inside your own products and infrastructure. The engines come with Java and REST APIs, so they can run embedded in an application or as a standalone service. Support in this path is limited to what the project offers publicly, and the commercial support you may need is sold separately.

License permits: Use, embedding and modification of the engines under Apache 2.0, subject to the license's notice and attribution terms.
Community support: Access to the community forum. Response times and coverage are not guaranteed.
Not included: Vendor-backed service level commitments, security patch guarantees beyond the project's own release cycle, and a low-code modeling UI.
Professional services: Available from Flowable and its partners, offered separately and scoped by contract.
Your own effort: Operating, patching, upgrading and testing the engine in your environment is your responsibility unless a services contract covers it.

Before committing, confirm with Flowable which support tiers, release branches and security advisories apply to the version you plan to run, and check the terms in the open-source repository.

What drives the cost of running Flowable yourself

Running Flowable in your own infrastructure moves cost from a vendor license to the people and platforms that embed, host, test and support the engine. No figures are given here because none have been supplied, so the cards below name what drives each component and what to request in a written quote.

Engineering time to embed and upgrade

Flowable runs embedded in a Java application or as a standalone service with REST APIs, so someone must own the integration, the process deployment pipeline and each engine upgrade. The one-time cost is the initial embedding and re-validation of migrated jBPM models. The recurring cost is each version upgrade. Ask the quote to separate build work from ongoing upgrade work, and to state the team roles assumed (Java, Spring, process analyst).

Database and infrastructure hosting

Flowable stores process state in a relational database, and the configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Your database licensing, high availability design, backups and the application nodes running the async executor all recur. Costs rise with the number of nodes and the database edition you already license. Ask the quote to state which database and topology it assumes and who pays for database licenses.

Commercial subscription or professional services

Flowable sells commercial editions, including Flowable Work, Engage, Orchestrate and Design, built on the same engines, and offers professional services separately. This is optional and changes the cost shape: a recurring subscription, or a per-engagement fee for specific work. Ask for the subscription scope, what support response terms it includes, and whether it covers the engine versions you run or only the commercial products.

In-house or partner support for open source

Without a vendor support contract, fixes, security patches and answers to production incidents come from your own engineers, the community forum or a partner you contract. This cost recurs and depends on how many engineers hold deep engine knowledge. Ask any partner for named staff, response expectations in writing, and what happens when a Flowable release changes behavior you depend on.

Upgrade testing across the Spring Boot 4 move

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, Jackson 3 as the default JSON library, and removal of JUnit 3 and 4 support. Applications on Spring Boot 3 must be retested and possibly refactored before adoption. Ask the quote to price regression testing of your process suite and any custom JSON or test code separately from the upgrade itself.

Retraining teams used to Business Central

Teams that built processes and rules in Business Central must learn Flowable's modeling approach, its REST APIs and its configuration model, and decide how Drools rules are handled outside a Business Central authoring environment. Training is largely one-time but recurs for new hires. Ask the quote to include training for process analysts and developers, and to state whether any low-code modeling tool it proposes is open source or part of a commercial edition.

What a Red Hat PAM alternative migration involves at a high level

This sequence moves a jBPM and Drools estate onto Flowable in an order that keeps business processes running, so each step ends with a check you can hand to your architects and operations team. It is a planning outline, and the detailed migration guide is a separate page.

Inventory BPMN, CMMN, DMN and Drools assets
Your architects and the process owners list every process definition, case model, decision table, DRL rule file and work item handler in the Business Central repositories, along with the external systems, databases and identity sources each one calls. Map which assets are live, which are dormant and which depend on KIE Server features you will not carry over. The step is done when you have a signed-off inventory that shows each asset, its owner and its dependencies, and any asset without an owner is flagged for a decision.
Fix the Spring Boot and Java baseline
Your platform and engineering leads choose the Flowable line that matches your application stack. Flowable 7.x runs on Spring Boot 3 and Java 17, while Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3. Confirm your JDK, application server and JSON library choices against the release notes before you start porting, because a wrong baseline forces rework later. The step is done when the target versions and the build configuration are recorded in an approved architecture decision.
Re-validate BPMN models on Flowable's engine
Your process engineers import each in-scope BPMN model into a Flowable test environment and deploy it, noting every parser error, unsupported element and changed behavior in expressions, listeners and timers. They run representative instances through each path, including error boundary events, timers and parallel gateways, and compare results with the original runtime. The step is done when each model deploys cleanly and passes the agreed test scenarios, and every deviation is either fixed or accepted in writing by the process owner.
Replace work item handlers with service tasks
Your developers rewrite each jBPM work item handler as a Flowable service task, Java delegate or external worker that the engine calls, and wire its inputs and outputs to the same downstream systems. Credentials and connection settings move to your secrets store and configuration rather than remaining in handler code. The step is done when every handler has a unit test, an integration test against a non-production copy of the downstream system, and a reviewed diff showing the behavior matches the original.
Decide where Drools rules move
Your architects decide, per rule set, whether each Drools rule file stays on Drools through Apache KIE, becomes a DMN decision model on the Flowable DMN engine for simpler decision tables, or is rewritten as application code. The decision should weigh rule complexity, how often business users change the rules and who maintains them after the move. The step is done when each rule set has a recorded destination, an owner and a test suite that proves its outputs are unchanged on sample inputs.
Plan draining and parallel running
Your operations and process owners agree how in-flight process instances finish. Options include letting running instances complete on the old runtime while new instances start on Flowable, or migrating selected instances, and the chosen approach depends on how long your longest processes run and whether their state can be mapped. Run both platforms in parallel for the agreed period, comparing outcomes and reconciling counts for the same business events. The step is done when the old runtime has no open instances you have not accounted for, and a reconciliation report signed by the business owner exists.
Cut over and monitor through the actuator endpoint
Your platform team switches new process starts to Flowable behind a controlled release and enables monitoring through the Flowable Spring Boot actuator endpoint at /actuator/flowable, which exposes running process data for dashboards and alerts. Operators watch for stuck jobs, failed timers and error queues during the first production cycles, and a rollback path stays available until the drain is complete. The step is done when the cutover checklist is closed, alerts are routed to on-call staff and the decommissioning date for the old runtime is recorded.

Questions to answer before you hire outside help for a Red Hat PAM alternative

What does a move from Red Hat PAM to Flowable cost?

The cost depends on how much of your Red Hat PAM estate has to move, and no fixed figure applies across projects. The main drivers are the number of BPMN models, the number and complexity of Drools rules, the custom work handlers and integrations behind service tasks, and how many running process instances must finish on the old platform. Costs fall into one-time items (inventory, model conversion, rule redesign, testing, cutover) and recurring items (your engineers' time, database and hosting, and any support contract). Flowable's open-source engine is Apache-2.0 licensed, so the software itself carries no license fee. Ask any provider for a quote built from a written inventory, with each asset line-itemed and the support options priced separately.

How long does a Red Hat PAM to Flowable migration take?

The timeline is set by asset count, rule complexity and your cutover constraints, not by the engine itself. A small set of BPMN processes with no Drools rules can move much faster than a Business Central estate with long-running instances, shared rule packages and strict change windows. The factors that add the most time are in-flight process instances that must drain or migrate, decisions that still live in Drools, identity and database integration, and the testing your business owners require before go-live. Ask for a schedule that lists these phases separately, and treat any single duration offered before an inventory exists as an assumption to challenge.

What skills does our team need for a Flowable migration?

Your team needs Java and Spring or servlet container experience, because Flowable runs as an embedded JAR or as a standalone REST service. Someone must own the database, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the async executor relies on lock records stored there. Identity integration is required if your processes use groups or users from LDAP or an existing directory, because Flowable's identity service must be replaced or implemented. Finally, you need people who can supply and maintain realistic test data and who know which business outcomes each process must still produce after migration.

Can our own engineers migrate from Red Hat PAM to Flowable without a partner?

A team with Java experience can often handle a small, embedded jBPM deployment with a clear asset inventory, provided it has time to test and a rollback plan. The work gets harder with a large Business Central estate, many decision tables, custom work item handlers, several environments, or processes that run for months. In those cases the risk lies less in converting BPMN files and more in regression testing, instance draining and operating the new engine after go-live. A useful self-check is whether your team can state, for each process, its inputs, outputs, owners and acceptance tests. If not, the inventory is the first piece of work to outsource.

Do we need a Flowable commercial edition to run the migrated processes?

No. The open-source Flowable engines for BPMN, CMMN and DMN are Apache-2.0 licensed and can run embedded or as a standalone service with REST APIs. Flowable sells commercial editions, including Flowable Work, Engage, Orchestrate and Design, built on the same engines. Those products add low-code modeling, visual debugging, security controls, monitoring and governance. Open-source users receive a community forum, while professional services and partners are offered separately. Decide whether those tools solve a problem you have today, such as business users editing models, and budget for them only if they do. Your migration plan should work on the open-source engine alone.

What does DeployOpen include in a Red Hat PAM alternative engagement?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Typical scope items for this move include the asset inventory, BPMN and rule assessment, the Flowable deployment, identity and database integration, migration of models and handlers, testing support and documentation. Ongoing support, upgrades and continuous testing are available as retainers after go-live. DeployOpen does not publish a price list, and a quote follows from the written scope.

What should a written scope include before we sign with a migration provider?

A written scope should name every asset in the move and state what done means for each one. Ask for a list of BPMN models, Drools rule packages, decision tables, work item handlers, external integrations, identity dependencies and the number of in-flight instances at cutover. The scope should also name the target environments, the database and hosting model, the testing and acceptance responsibilities of each party, the rollback approach and the documentation you receive. Confirm which items are out of scope, such as rule redesign or new process features, and which support terms apply after go-live. Items left vague in the scope usually become change requests later.

How do we check Flowable's current release and support status before we commit?

Check the release history directly in the upstream repository before choosing a target version. Flowable 8.0.0 was released on February 27, 2026, and its release notes describe the move to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3 and Jackson 3 as the default JSON library. Earlier, Flowable 7.0.0 moved the engine to Java 17, Spring Boot 3 and Jakarta EE and removed the UI applications. Confirm which Java, Spring and database versions your target line supports, and ask your provider how they will handle future upgrades, since the Spring changes in 8.0.0 affect application code.

How DeployOpen helps you evaluate, implement and migrate

DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Red Hat PAM vs Flowable, we start by testing whether Flowable's engines fit your jBPM processes and Drools rules before any migration work is committed.

How we scope

We inventory your jBPM processes, Drools rules, Business Central assets and custom work item handlers before proposing a plan.
Each engagement is fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope states which engines, database types and identity sources are in and which are out.

How we build

We re-validate BPMN models on the Flowable engine and record every behavior difference found in the test runs.
We map work item handlers to Flowable service tasks and decide with you where Drools rules are kept.
We test in-flight process instance draining, async executor behavior across nodes and the database backend you choose.

How we hand over

You receive documentation of the deployed architecture, configuration, runbooks and the migration decisions taken.
We provide test evidence for each migrated process so your own team can repeat the checks later.
Knowledge transfer covers operating the engine, upgrades and rollback steps in your environment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support covers Flowable version upgrades, such as reviewing the release notes for each major line before you move.
Ask any provider, including us, to confirm in writing which versions and components they will support.

Red Hat PAM vs Flowable