Migrate from Red Hat PAM to Flowable: what the move involves
Flowable can run your BPMN processes in your own infrastructure, but moving off Red Hat Process Automation Manager is a re-validation and re-wiring project, not a file copy. If your PAM 7.x estate is past end of life, or a renewal is forcing a decision, plan for each BPMN model to be re-tested on Flowable's engine, each jBPM work item handler to be rebuilt as a Flowable service task or Java delegate, and each running process instance to be drained or migrated deliberately. Most teams do this work with an internal platform team and an implementation partner, since the people who know the PAM-specific wiring are rarely the same people who will own the Flowable runtime afterward. Effort depends mainly on how many custom work item handlers, human task integrations and process variables your models use, so start with an inventory of those before estimating anything.
Treat Drools rules as a separate decision. Flowable has a DMN engine that suits simpler decision tables, but rule-heavy applications built on Drools may be better served by staying on the Apache KIE line, which is still incubating at the Apache Software Foundation and must be assessed on its own terms. Confirm with your architects which rules are called from processes, because those call points determine whether rules move, stay, or are reimplemented as DMN. Also confirm how your PAM deployment handles process instance state: in-flight instances will not run unchanged on a different engine, so decide whether to let them complete on PAM, cut over at a quiet window, or script a state transfer, and test whichever you choose against a copy of production data. Ask Flowable's commercial or professional services teams and your partner what support you would have for an open-source engine in production, and write that answer into the plan.
Which PAM capabilities map to Flowable, and which need rework
This table maps the main jBPM and Red Hat PAM capabilities your processes depend on to Flowable's BPMN, CMMN and DMN engines. Read each row as clean (carries over with little change), needs rework (the concept exists but the code or assets change) or gap (Flowable does not provide it in open source, so you must build or buy it). Confirm BPMN element coverage against your own models before estimating effort.
| Capability | Flowable fit | Status | What to check |
|---|---|---|---|
| BPMN process definitions | Flowable executes BPMN 2.0 process definitions on its BPMN engine | Needs rework | Re-validate every jBPM model on Flowable, since element coverage must be confirmed against your own BPMN files |
| Human tasks | Flowable provides user tasks on the BPMN engine with Java and REST APIs | Needs rework | Task assignment and candidate logic may need reimplementation through identity services |
| Timers and async jobs | Flowable's async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through database locks | Clean | Review lock expiration settings and test recovery when a node stops mid-job |
| Service and work item handlers | Work item handlers are replaced by Flowable service tasks implemented in Java | Needs rework | Each custom handler needs a new implementation and tests against Flowable's service task contract |
| Process variables | Flowable stores process variables in the database through its BPMN engine APIs | Clean | Check serialization of complex objects and variable naming against the new engine |
| Business Central authoring | Flowable 7.0.0 removed its UI applications; authoring moves to modeling tools or custom screens, and commercial Flowable Design and Work add low-code modeling | Gap | Decide whether to adopt a commercial modeling product or build screens for business analysts |
| KIE Server REST access | Flowable offers a REST application and REST APIs for its engines, but endpoints and payloads differ from KIE Server | Needs rework | Map every client integration to the new REST contract and update callers |
| Drools rules | Flowable has no Drools equivalent; complex rule sets need Apache KIE Drools or a separate rules service | Gap | Identify which rules stay in Drools and how the Flowable process will call them |
| DMN decisions | Flowable's DMN engine executes decision tables for simpler decisions | Needs rework | Test each DMN model on the Flowable DMN engine and confirm supported features |
| Spring Boot integration | Flowable provides Spring Boot starters for all engines, REST and individual BPMN, CMMN and DMN engines | Clean | Confirm Spring Boot version compatibility; Flowable 8.0.0 requires Spring Boot 4 |
How to re-validate BPMN models on Flowable's engine
Re-validation is the step that proves a migrated process still behaves as it did under Red Hat PAM. jBPM and Flowable both execute BPMN 2.0, so the core flow elements usually load, but the two engines differ in extension elements, script languages, service task implementations and history behavior. Every BPMN model should be treated as unverified on Flowable until its outputs match PAM output on the same inputs. Start by inventorying which extension attributes, expression languages and listener types your models use, and confirm each one against Flowable's documentation for the version you plan to run. Do not assume a jBPM-specific construct has an equivalent until you have checked it.
Run the re-validation as a repeatable loop. Deploy each process definition to a Flowable test environment, then run representative instances through every path, including gateways, boundary events, timers, error paths and subprocesses. For each run, compare the variables at each wait state, the timers that fire and their due dates, and the task assignments and candidate groups against the output recorded from PAM for the same inputs. Keep the PAM outputs as fixed golden files so each Flowable change is checked against the same baseline. Flowable's engine supports BPMN, CMMN and DMN and can be embedded in Spring, Tomcat, Jetty or Java EE applications, or called over HTTP through the Flowable REST application, so choose the test topology that matches your production deployment before you start.
Confirm the mismatches that matter most before sign-off. Timer expressions, identity lookups for candidate users and groups, and history records are the areas most likely to differ, so check them against your own environment rather than assuming parity. Ask whether your identity source will be provided through Flowable's identity service interface, which the Flowable configuration and advanced documentation describe as replaceable. Record every model that needed a change, the reason, and the test run that confirmed the fix, because that record becomes the evidence your auditors and change board will ask for.
Which data, identities and integrations move, and which you rebuild
Moving from Red Hat PAM to Flowable splits into components that move through extraction and components you rebuild in Flowable's model. No supplied source documents a direct PAM-to-Flowable export tool, so plan for a scripted extraction or a rebuild, and confirm export options with Red Hat and Flowable before you commit to a timeline. The cards below cover each component in turn, from running instances to external integrations.
Runtime process instances and variables
In-flight jBPM instances hold tokens, timers, variables and pending tasks that must be drained or carried across. Because there is no supplied direct export path, the usual options are to let running instances finish on PAM while new starts go to Flowable, or to write an extraction that maps variable types and task state into Flowable tables. Confirm with Red Hat and Flowable whether any state transfer is supported, and test variable serialization on a copy before any cutover.
Process definitions and deployments
BPMN models from PAM are not deployed as-is. You redeploy them to Flowable's engine, check every gateway, script task and timer expression against Flowable's behavior, and keep version numbers and deployment IDs in a mapping table so audit trails still resolve. Treat the BPMN file as the portable artifact and the deployment record as something you recreate, not copy.
Identity and group mappings
Flowable's docs state that identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Map PAM users, groups and candidate roles onto that service, and check that task assignment and candidate-group queries return the same people before go-live. Your directory design, not the BPM engine, decides most of the effort here.
Database schema and supported databases
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and its schema is separate from PAM's. Your PAM database is not a drop-in target, so plan a new Flowable schema, its backup and restore, and a migration of historic data only if your retention rules require it. Note that MySQL versions below 5.6.4 lack millisecond precision, which matters for timer and audit timestamps.
Work item handlers and REST integrations
PAM work item handlers, the Java classes that call external systems from a jBPM task, have no direct equivalent. Rebuild each one as a Flowable service task or delegate, or call the service over REST, and retest error handling and retries. Flowable's async executor recovers expired job locks across nodes, so confirm that any integration you move to asynchronous jobs is idempotent. Inventory every handler before estimating effort.
Drools rules and decision assets
Drools rules and DMN decision tables used by PAM are a separate decision. Flowable's DMN engine can take simpler decision tables, while rule-heavy logic may stay on Drools through Apache KIE. Decide per rule set before moving process logic, because a rule moved into a process script loses the rule engine's testing and versioning. Record each decision asset's owner and destination in your inventory.
The migration sequence: inventory, pilot, parallel run, cutover and decommission
This sequence moves running and new Red Hat PAM workloads to Flowable in controlled stages, so each step produces evidence that the next one depends on.
Inventory processes, rules, handlers, timers and integrations
Platform and process owners list every BPMN process definition, Drools rule package, DMN model, custom work item handler, timer and boundary event, and external integration deployed on Business Central and KIE Server. For each item, record its owner, the process families it belongs to, and how many instances are active or waiting. The output is a signed-off inventory with instance counts per process and a column marking which items use custom Java code. The step is done when every deployed asset maps to a row and nothing is left unassigned.
Classify handlers and rules for Flowable
Engineers review the inventory and sort work item handlers into groups: those that call a REST service, those that call a database or message queue, and those that embed business logic. Each handler gets a planned Flowable replacement, usually a service task with a Java delegate, an expression, or an external worker. For Drools rules, the team decides whether each package stays in a rules engine (for example Apache KIE or a DMN decision called from Flowable) or moves into Flowable's DMN engine for simpler decision tables. The output is a written mapping that architects and risk owners approve before any code is written.
Pilot one low-risk process on Flowable
Pick one process with few active instances, no regulated data, and a small number of handlers. Re-validate its BPMN model on the Flowable engine, replace each handler with a Flowable service task, and deploy the process either embedded in a Spring Boot or Java SE application or as a standalone service through the Flowable REST API. Run it in a non-production environment with test data and compare the audit trail, timer behavior and outputs against the PAM version. The pilot is complete when the team has a written list of differences, each either fixed or accepted by the process owner.
Run in parallel with new starts on Flowable
Route newly started instances of the pilot family to Flowable while instances already running on PAM continue to completion there. Both platforms run side by side, each with its own database and monitoring. Operations teams watch job execution, timer firing and error queues on both sides, and any defect found in Flowable is fixed before the next family moves. The step closes when the PAM instance count for the family reaches zero or a documented set of long-running instances is accepted to finish on PAM.
Cut over by process family
Move the remaining process families one at a time, starting with those that have the fewest handlers and dependencies. For each family, stop new starts on PAM, drain or migrate in-flight instances according to the decision made in the inventory, switch the calling systems to Flowable endpoints, and confirm with a reconciliation report that instance counts and key business states match. A family is cut over only when its reconciliation report is signed by the process owner and the rollback procedure has been tested in the non-production environment.
Decommission KIE Server and Business Central after archiving evidence
After the last process family is live on Flowable and the drain period recorded in the plan has ended, export the PAM process history, audit logs, rule packages, BPMN and DMN assets, and configuration to read-only archive storage in your own infrastructure. Confirm with compliance and records owners which retention rules apply to that archive. Then stop KIE Server and Business Central, remove their database schemas only after the archive is verified, and close the access and secrets entries tied to them. The step is done when the archive has been restored and checked once and the decommission record is approved.
Draining in-flight process instances without losing work
The first decision is whether open PAM process instances finish on a retained PAM environment or are migrated to Flowable while still running. Letting them complete is the lower-risk path for short-lived processes, because the jBPM engine already knows how to execute them and no state needs to move. Migration becomes necessary when the old environment must be shut down on a fixed date, or when instances will outlive your support window. The hard cases are instances waiting on timers, such as escalation deadlines or SLA reminders, and instances parked on human tasks, which may sit for weeks. Inventory these by process definition and by age before choosing, because a single long-running timer can keep a retained environment alive far longer than expected.
If both platforms or nodes point at the same database, the job tables become a coordination point. Flowable's async executor runs timers and asynchronous jobs from a thread pool and records a lock owner and a lock expiration time for each job in the database. When a node dies or stalls, its lock expires and another node picks the job up, which is how jobs are recovered across nodes. Mixing a PAM runtime and a Flowable runtime on one schema is not something to attempt casually. Keep the two engines on separate schemas or databases, and test in a non-production copy whether timers fire exactly once and at the expected time after a failover. Confirm the timer semantics, time zone handling and lock timeout settings for your Flowable version in your own tests, not from assumptions about the older engine.
Drain in four steps. First, freeze new starts for each process definition in PAM by disabling the entry point your channels use, and record the date. Second, count open instances per definition, split by state (running, waiting on timers, waiting on human tasks), and track that count weekly. Third, set a retirement date for the PAM environment, and move instances that cannot finish before it, such as those with timers beyond that date, using a tested migration script rather than manual edits. Fourth, keep read access to PAM audit and history data after retirement, since your records retention obligations do not end when the engine is switched off. Agree the retirement date and the migration tooling with your change owner before the first start is frozen.
Where Drools rules and DMN decisions go after the move
This path leaves Drools rule projects where they are and has the Flowable process call them through an API. Apache KIE is the home of Drools, and its 10 line is licensed under Apache 2.0, but the project is still in incubation at the Apache Software Foundation. The Apache KIE site notes that incubation does not necessarily reflect the completeness or stability of the code, so the team takes on that risk directly.
- Maintenance: You run two engines, the Flowable runtime and a Drools runtime, each with its own upgrades, security patches and monitoring.
- Testing: Rule tests stay in the existing Drools test suites, but you need integration tests for the call boundary between the two systems.
- Skills: Your team keeps Drools expertise, and needs Flowable and service-to-service integration skills as well.
- Version risk: Apache KIE 10.2.0 removed the classic BPMN and DMN editors, so any authoring workflow built on those editors must change.
- Exit path: This path keeps the rules portable, but it does not remove the incubating dependency.
Before choosing this path, confirm the current Apache KIE release line and editor support with the project's release notes and your own build pipeline.
This path moves simple, stable decision tables into Flowable's DMN engine so that a decision runs inside the same engine as the process that calls it. Flowable's open source engines cover BPMN, CMMN and DMN under Apache 2.0, and the DMN engine suits decisions expressed as tables with clear inputs and outputs. It is a poor fit for large rule sets that rely on Drools features such as complex pattern matching across many facts.
- Maintenance: One engine and one deployment unit reduce moving parts for these decisions.
- Testing: Decision tables can be tested against sample inputs in the same pipeline as the process models.
- Skills: Business analysts who read decision tables can review them, which lowers the review burden on developers.
- Conversion effort: Each Drools rule must be checked for whether it maps to a table, a conversion that is manual for anything beyond simple conditions.
- Scope: Flowable's Java and REST APIs cover DMN execution, but confirm which DMN features your models use against the Flowable documentation.
Before choosing this path, check each candidate decision against a sample of production inputs so that the table produces the same outcomes as the rule it replaces.
This path removes the rule engine entirely and writes the decision logic as ordinary code in the services that call Flowable. It removes the incubating dependency and the second runtime, but it moves the rules into a language and release process that your developers already own. This suits small rule sets with stable logic and poorly suits rule sets that business owners change often.
- Maintenance: The rule logic is maintained with the application, with no separate rule runtime to patch.
- Testing: Unit tests cover the logic directly, but you must build the test cases that Drools previously held in its rule projects.
- Skills: Developers carry the logic, so knowledge of business rules can concentrate in a few people unless it is documented.
- Change rate: Each rule change becomes a code release, which can slow updates that the business expects quickly.
- Audit trail: Explain how decisions are recorded for auditors, because code-based logic does not produce the same decision records by default.
Before choosing this path, ask the business owners which rules change monthly and which change yearly, because that split usually decides which logic belongs in code.
Most teams should not pick one path for the whole estate. Start with an inventory of every rule project, decision table and Drools call made by a process, then assign each to a path. The inventory is the input that determines the mix of tabs above, and it prevents rules from being moved on assumption.
- Catalog: List each rule project, DMN model and rule call, with the process that uses it and the owner who approves changes.
- Classify: Mark each item by complexity, change rate, data inputs and whether it must produce an audit record.
- Test baseline: Capture current decision outputs for a representative set of inputs so the new path can be compared against them.
- Assign: Map each item to Apache KIE, Flowable DMN or application code, and record the reason.
- Confirm: Verify with the vendor or project which Drools, DMN and Flowable features your models depend on before committing.
Run the inventory with the business owners, not only the developers, since they hold the knowledge of which rules are still in force.
What drives the cost and duration of the move
This table lists the factors that change how much work a move from Red Hat PAM to Flowable takes, and how each one can be reduced. Read the driver rows to size your own estate, then use the cost component rows to decide who pays for each part and which costs recur after cutover. No durations or prices are given, so ask for a quote built from a written scope.
| Driver or cost component | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Process definitions and variants | Each BPMN model, including subprocesses and near-duplicate variants, must be re-validated on Flowable's engine, so effort grows with the number of distinct definitions. | Inventory every definition, retire unused ones, and merge variants that differ only in data before conversion. |
| In-flight process instances | Running instances must finish on the old engine or be migrated, and older instances may reference task names or variables that no longer match the new model. | Count instances by definition and age, drain short-lived processes first, and migrate only long-running instances that justify the work. |
| Timers and human tasks | Timer events, boundary timers and user task assignment rules must be checked for identical behavior, including time zones, calendars and escalation paths. | Document each timer and assignment rule with a test case so behavior can be compared after conversion. |
| Custom work item handlers | Each jBPM work item handler is custom Java code that must be rewritten as a Flowable service task, delegate or listener, and each one needs its own tests. | Group handlers by external system, rewrite shared logic once, and confirm which integrations are still in use. |
| Drools rule volume | Rules embedded in processes or in Business Central assets must either move to Flowable's DMN engine, stay in Drools as a separate service, or be rewritten, and each choice has a different cost. | Classify rules as decision tables, which suit DMN, or complex rule sets, which may stay in Drools. Confirm that the team can support whichever path it picks. |
| Identity integration | Flowable does not ship identity management as a turnkey feature for every directory, so the identity service may need an override or a custom implementation that connects to your LDAP or SSO source. | Confirm which groups and roles processes use, then reuse the reference LDAP identity service where it fits. |
| Database platform | Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the target database affects schema setup, migration scripts and the DBA work required. | Choose a database your team already operates and test the Flowable schema on a copy of production data. |
| Number of environments and compliance evidence | Each environment needs its own deployment, test data and sign-off, and regulated teams must keep records of the migration, testing and approvals. | Automate deployments, keep one test suite for all environments, and agree evidence requirements with your auditors early. |
What usually goes wrong and how to prevent it
Moving jBPM processes to Flowable tends to fail at the seams: engine semantics, handler coverage, rule placement and cutover. The cards below describe six risks that recur in this kind of move, each with a check to run before production traffic shifts.
Silent timer and variable differences
Timer expressions, due-date calculation, calendar handling and variable type coercion can behave differently after re-validating BPMN models on Flowable's engine. A process may deploy cleanly and still fire a boundary timer at a different time or store a number as a string. Replay representative instances from each process family in a staging copy and compare timer fire times, variable values and end states against jBPM output before cutover.
Handler gaps found in production
Custom work item handlers from Red Hat PAM have no direct equivalent in Flowable, and each one replaced by a service task or Java delegate is a place where behavior can silently change. A missing handler often surfaces only when a rarely used branch runs on a Monday morning. Build an inventory that maps every work item name in the BPMN files to a Flowable implementation, and fail the build when a service task reference has no registered bean.
Rule logic split across two engines
Drools rules that ran inside jBPM decision steps must be placed somewhere on Flowable, either in a DMN decision table evaluated by Flowable's DMN engine or in an external Drools service. Splitting logic between the two makes it hard to know which engine owns a given decision and who changes it. Record one owner for each rule set, and confirm that DMN tables you move are supported by the DMN features Flowable exposes before retiring the Drools source.
Unmanaged in-flight instances at cutover
Process instances started on the jBPM runtime keep their state in the old database and will not move on their own. Cutting over without a rule for them leaves work stranded, duplicated or reassigned by hand. Decide per process whether running instances finish on the old runtime, get migrated with a scripted state transfer, or are restarted, then set a drain date and track the count of open instances until it reaches zero.
Missing runbooks for the self-hosted engine
Once Flowable runs in your own infrastructure, your team owns the async executor, database connections, lock recovery and upgrades. Teams that never wrote runbooks discover these gaps during the first incident. Document how the async executor recovers expired locks, how to restart stuck jobs, how to back up the engine schema and how to roll back a release. Test each runbook once in a non-production environment before go-live.
Loss of visual authoring
Business analysts who edited processes in Business Central may lose their modeling and debugging environment when the move lands on code-first engines. Open-source Flowable does not include the low-code modeling and visual debugging that Flowable's commercial editions add, so those workflows need a replacement. Decide early which modeler the team will use for BPMN and DMN, who maintains it, and how changes go through version control and review.
How the move differs by estate size and starting point
A single department with a handful of BPMN processes usually has one owner, one deployment and a small set of work item handlers. The move is mostly a question of re-validating each model on Flowable's BPMN engine, rewriting the handlers as service tasks and running the new engine beside the old one until the open instances finish. Because the estate is small, the team can often test every process end to end in one pass.
- Inventory first: list every process definition, timer, signal and human task, and note which ones call external systems through work item handlers.
- Keep the database simple: Flowable supports PostgreSQL, MySQL, Oracle, DB2, Microsoft SQL Server and H2, so choose the one your team already operates.
- Decide on Drools early: if the department uses only a few rules, consider moving them to DMN decision tables that Flowable evaluates directly.
- Drain in place: let running instances finish on the old runtime before you switch the front door to Flowable.
- Assign one owner: a single accountable person usually shortens the back-and-forth on model changes.
Confirm with your team how many instances are open at cutover and whether any process runs for months, because that sets how long the old runtime must stay available.
A shared jBPM estate serves several business units, with Business Central, KIE Server and many Drools rule projects that other processes depend on. The move here is a program rather than a single project. Rules, processes and integrations have different owners, and a change to one rule package can affect several applications, so the sequence has to be agreed across teams before work starts.
- Separate rules from processes: map which Drools packages are called from which processes, then decide per package whether it becomes DMN, Java code or an external decision service.
- Sequence by dependency: migrate leaf processes that call no shared rules first, and leave the most connected processes for last.
- Plan for coexistence: many instances will run on both platforms for some time, so routing, monitoring and audit reporting must cover both.
- Retire Business Central deliberately: authoring moves to models you version in Git, which changes how business analysts work and needs its own training plan.
- Check support boundaries: confirm with each owner which environments, backups and upgrades you must keep consistent during the program.
Ask the program owner to name every application that calls the estate, since unlisted callers are the most common source of late surprises.
A team that already runs Flowable or Spring Boot services starts with familiar tooling. The main work is less about a new engine and more about consolidating: deciding whether jBPM processes become Flowable process definitions inside existing services, or whether they stay on their own runtime as a separate service. Flowable's Spring Boot starters and its REST application give the team two integration shapes to choose from.
- Pick the deployment shape: embed the engine in an existing Spring Boot application, or run the Flowable REST application as a shared service, based on how many teams call it.
- Reuse the operations model: Flowable exposes an actuator endpoint at
/actuator/flowablefor monitoring running processes, which fits existing dashboards. - Check the async executor: confirm that lock expiry and job pickup behave correctly across the nodes you already run.
- Replace identity carefully: if the jBPM estate used its own user model, implement the identity service interface that Flowable documents, with LDAP as a reference.
- Check the major version: Flowable 8.0.0 requires Spring Boot 4 and drops Spring Boot 3, so align versions before you start.
Check your current Flowable version against the release notes before you plan the upgrade path, since the move from 7.x to 8.0.0 changes framework requirements.
Questions teams ask before moving from Red Hat PAM to Flowable
How much effort does a move from Red Hat PAM to Flowable take?
The effort depends mostly on how many jBPM processes you run, how many use custom work item handlers, and how many depend on Drools rules or Business Central assets. Flowable's BPMN engine is a separate codebase, so every process model must be re-validated and every work item handler rewritten as a Flowable service task or Java delegate. Teams with a small set of standard BPMN flows usually have far less to change than teams with heavy custom integration. Ask any provider to inventory process definitions, handlers and rule assets first, because that inventory produces the estimate. No fixed effort figure is supplied for this move, so treat any number you see without that inventory as a guess.
How long does a Red Hat PAM to Flowable migration take?
Duration is driven by the same inventory of processes, handlers and rules, plus how much of your operations you must keep running during the cut-over. Projects with a single application and few process definitions move faster than platforms where several business units share a Business Central instance. Time also depends on how you handle in-flight process instances: you can let old instances finish on the jBPM runtime while new work starts on Flowable, which extends the period you run both. No duration is supplied for this migration, so ask for a schedule tied to a written scope and milestones.
Can our internal team migrate to Flowable without a partner?
Yes, a capable Java team can do it, but the skills must match the work. Your engineers need working knowledge of BPMN semantics, the Flowable Java and REST APIs, the Spring Boot starters if you use them, and the database you choose. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so your DBA team also has a role. Open-source use means you have no vendor support contract by default, so decide in advance who handles production incidents. Flowable offers professional services and partners separately, and DeployOpen can plan, implement and document the move under a fixed-scope agreement if you prefer outside help.
What do we need from our side for the migration?
Three inputs matter most: engineers who can run the target stack, environments where you can test and promote changes, and process owners who can confirm expected behavior. Process owners are needed because a model that validates on Flowable can still behave differently from the jBPM original in timers, error handling or variable scoping, and only the business can say which behavior is correct. You also need staging environments that mirror production databases and identity sources. Flowable's docs describe replacing identity management through an IdmIdentityService implementation, so your identity integration should be scoped early. Confirm each of these with the team before you agree on a scope.
Is Flowable a better long-term home than the jBPM lineage?
Flowable is an Apache 2.0 licensed engine for BPMN, CMMN and DMN with Java and REST APIs, and its 8.0.0 release was dated February 27, 2026. The jBPM lineage now lives in Apache KIE, which is still in incubation at the Apache Software Foundation, and the Apache KIE site notes that incubation does not necessarily reflect the completeness or stability of the code. Whether Flowable is the better home depends on your release cadence needs, on whether you want CMMN case management, and on how much you value a single engine family. Check the Flowable 8.0.0 release notes for breaking changes, since that release requires Spring Boot 4 and drops support for Spring Boot 3.
What happens to our Drools rules during the move?
Drools rules do not transfer automatically to Flowable, so you need a deliberate decision for each rule asset. Flowable's DMN engine is suited to simpler decision tables, while complex rule sets that use Drools features may need to stay on Apache KIE, run as a separate decision service, or be rewritten. Start by listing which DMN models and DRL files exist, which are called from processes, and which can be expressed as decision tables. Keeping Drools separate lets you move process orchestration first and decide the rule platform later, but it adds a second runtime to operate.
Do we have to buy Flowable's commercial editions?
No. The Flowable engines are open source under Apache 2.0, and the open-source engines include BPMN, CMMN and DMN with Java and REST APIs. Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, add low-code modeling, visual debugging, security controls, monitoring and governance on the same engines. Open-source users get a community forum, while professional services and partners are offered separately. The real decision is whether you need those tools, and whether you can operate the monitoring, security and modeling capabilities yourself.
How DeployOpen scopes and runs a PAM to Flowable migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Red Hat PAM to Flowable is handled as a fixed-scope engagement with written deliverables. We start by inventorying the jBPM processes, Drools assets and running instances, then agree the migration plan and acceptance criteria before any code changes begin.
How we scope
- We inventory every BPMN model, work item handler, Drools rule set and DMN table the PAM estate uses.
- We map each process to a Flowable engine (BPMN, CMMN or DMN) and flag where Drools logic needs a separate decision.
- Scope, deliverables and timelines are agreed in writing before work starts, with no prices in this page.
How we build
- We re-validate BPMN models on Flowable and replace work item handlers with Flowable service tasks.
- We configure the database type, async executor and identity service to match your identity and hosting model.
- We test each process path and the draining plan for in-flight instances in a non-production environment first.
How we hand over
- We document the model mapping, handler replacements, rule placement decisions and deployment runbooks for your team.
- We deliver the test evidence and cutover record so your auditors or internal reviewers can trace each change.
- We train the operators who will run the Flowable services, covering monitoring and the actuator endpoint configuration.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover engine version upgrades, such as tracking Flowable's release line, with testing before each change.
- We ask you to confirm with Flowable which edition and support terms fit your environment before we agree the scope.
