Red Hat PAM end of life: which path keeps your processes running
If your estate runs Red Hat Process Automation Manager 7.x, with BPMN processes, Drools rules and Business Central in daily use, you are past end of life and extended support has ended. The choice now is between three paths: IBM BAMOE, the named successor and a subscription product; self-supported Apache KIE, the open-source home of Drools, jBPM and Kogito; and a move to Flowable, an Apache-2.0 BPMN, CMMN and DMN engine. The decision turns on how much code must change, what support model you need, and how much risk you can carry without vendor-backed patching. The constraint that matters most is the end of supported patching: every month you run 7.x unpatched is exposure you have to document and accept, so the path you pick should be one you can start within your next change window.
Start by inventorying what you actually run. List every process definition, every decision asset and rule package, every custom work item handler, and every KIE Server deployment or Business Central project. Note which runtime features each asset depends on, because Business Central tooling and the KIE Server APIs are where the three paths diverge most. Confirm with IBM the scope, term and support entitlements of BAMOE for your workload, and confirm with the Apache KIE community the current state of the release line you would adopt, since the project is still in incubation and the Apache KIE site notes that incubation does not necessarily reflect the completeness or stability of the code. Ask Flowable which engine versions and support tiers apply to your database and framework stack.
Within each path, the work splits into code change, operations and assurance. Code change covers model re-validation, rule migration and handling in-flight instances. Operations covers where the runtime is hosted, how you back up its database and how you handle upgrades. Assurance covers the evidence you can show an auditor or regulator that the platform is patched and supported. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure, and prepares controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that. Use the sections below to compare each path on those three dimensions.
What the end of life forces you to decide
Red Hat Process Automation Manager 7.x no longer receives extended support, so each path forward starts with a runtime choice. The cards below cover the decisions that follow from that choice: the patch source, the Java and framework baseline, how running process instances move, and how rules and decisions stay auditable.
Choose the patch source
Each path gives you a different party responsible for security fixes. IBM BAMOE is a subscription, so ask IBM in writing which versions, fix types and support windows the subscription covers. Apache KIE is an incubating ASF project with no vendor behind it, so your team or a partner must decide how to track CVEs, build patched artifacts and test them. Flowable offers its open source engines under Apache 2.0 and sells commercial editions separately. Confirm which of these options gives you a named party to call when a critical fix is needed.
Set the Java and framework baseline
The target platform often matters more than the feature list. Apache KIE 10.0.0 moved the projects to Java 17, Jakarta 10, Quarkus and Spring Boot, and 10.2.0 added Java 21 support. Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 and drops Spring Boot 3 compatibility, while Flowable 7.0.0 targeted Java 17 and Spring Boot 3. Map your current runtime against these baselines before you pick a version, because a framework jump can cost more than the engine swap itself.
Preserve in-flight process instances
Running instances are the hardest part of cutover, because a new engine will not necessarily read the state of a process started on the old one. Inventory the active instances, timers and asynchronous jobs in the Red Hat PAM database, and decide whether each one completes on the old runtime, is migrated, or is restarted. Flowable's async executor recovers expired locks across nodes, so test that behavior under your clustering setup. Plan a drain window for instances that cannot move.
Keep rules and decisions auditable
Auditors will ask which decision logic was in force on a given date. With Apache KIE, Drools rules and DMN 1.6 models in 10.2.0 must be versioned, exported and tested against the same inputs as before the move. With Flowable, rule-heavy logic may need to be simplified into DMN decision tables, which changes how the logic is reviewed. Record the source of every decision table, the engine version that evaluated it, and the test results that prove the outputs match.
Account for dropped features
Some capabilities do not carry over cleanly. Flowable 7.0.0 removed the UI applications, the form and content engines and async history, so any Business Central screens, forms or history reports you depend on need a replacement or a rebuild. Apache KIE 10.2.0 replaced the legacy GWT-based BPMN tooling and removed the classic BPMN and DMN editors, so existing modeling habits and editor-dependent steps must be retrained. List every feature your users touch today and mark which ones the target path keeps.
How IBM BAMOE, Apache KIE and Flowable compare
This table compares IBM BAMOE, Apache KIE and Flowable for teams leaving Red Hat PAM 7 across continuity, code changes, support, project maturity and trade-offs. Check each row against your own inventory of BPMN, DMN and rule assets, since BAMOE terms and compatibility must be confirmed in writing with IBM. The main takeaway: Apache KIE keeps the closest jBPM and Drools lineage but carries incubation risk, while Flowable is a re-platforming effort.
| Criterion | IBM BAMOE | Apache KIE | Flowable |
|---|---|---|---|
| Continuity path | IBM's successor to Red Hat PAM. Confirm which PAM 7 assets and versions it accepts. | Same jBPM and Drools lineage. The 10.x line is the natural upgrade target. | New engine. BPMN, CMMN and DMN models must be re-validated on Flowable. |
| Code changes | Confirm with IBM how much jBPM and Drools code carries over unchanged. | Plan for Java 17 or later, Quarkus or Spring Boot, and the new BPMN editor in 10.2.0. | Replace work item handlers with service tasks, decide where Drools rules move, and target Spring Boot 4 for 8.0.0. |
| Support model | IBM subscription. Confirm terms, lifecycle dates and scope in writing. | Community-driven under the Apache Software Foundation. Production support comes from your team or a partner. | Open-source community forum. Professional services and partners are offered separately. |
| Project maturity | Commercial product. Confirm release cadence and end-of-life dates with IBM. | Still in incubation. Incubation does not necessarily reflect completeness or stability. | Apache-2.0 engines with releases through Flowable 8.0.0 on February 27, 2026. |
| Commercial add-ons | Confirm which tooling and entitlements the subscription includes. | Apache-licensed projects. Check separately for any vendor offerings you may need. | Flowable Work, Engage, Orchestrate and Design build on the same engines with low-code modeling and governance. |
| Main trade-off | Lowest expected code change if IBM confirms compatibility. Recurring subscription cost. | Closest code lineage. Incubating status and self-support move risk onto your team. | Lighter, standards-based engines. A larger rewrite and new skills for the team. |
Which path fits which estate
If your applications depend on Drools rules, decision tables and DMN models, Apache KIE is the path that keeps the most of your existing assets in their native engine. Apache KIE is the ASF home of Drools and jBPM, licensed under Apache License 2.0, and it is still in incubation, so the project's own site notes that incubation does not necessarily reflect the completeness or stability of the code. Your work here centers on rule regression testing and on checking how rule sets behave when moved to the 10.x line.
- Rule regression suites: Build test cases from production decisions and run them against the target version before any cutover.
- DMN compatibility: Apache KIE 10.2.0 added DMN 1.6 support, so confirm which of your DMN models use features that changed between versions.
- Editor change: The 10.2.0 release replaced the legacy GWT-based BPMN tooling and removed the classic BPMN and DMN editors, so plan for authoring workflows to change.
- Runtime shift: Confirm how your rule services move from KIE Server to the Kogito-based runtime on Quarkus or Spring Boot.
- Support: Arrange in-house or partner expertise in Drools internals, since no vendor support is included.
Before committing, ask your team to confirm which rule assets are business-critical and whether your staff can debug Drools on Quarkus or Spring Boot without vendor help.
If your estate runs mainly BPMN service orchestration with few or no custom rules, a lighter engine can be easier to own over time. Flowable provides BPMN, CMMN and DMN engines under Apache 2.0 that run embedded in a Java application, in a servlet container, in Spring, or as a service over REST. Its 8.0.0 release, dated February 27, 2026, upgraded to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so any Spring Boot 3 service needs its own upgrade plan.
- Model re-validation: Re-run every BPMN model on the target engine and compare task behavior, timers and error paths.
- Work item replacement: Map each jBPM work item handler to a Flowable service task or delegate and test it end to end.
- In-flight instances: Decide whether to drain running instances or migrate them, and test that path with real process state.
- Clustering behavior: Confirm the async executor's lock-expiry settings suit your node count, since it recovers expired locks across nodes.
- Identity mapping: Confirm how users and groups are resolved, because identity management can be replaced through an IdmIdentityService implementation.
Ask your team to confirm how many processes truly need Drools, since that count decides whether this path is simpler than Apache KIE.
If your organization needs a contract, a named support channel and a vendor accountable for fixes, the commercial route fits better than a self-supported open-source stack. IBM's successor subscription, BAMOE, is the vendor-backed option in this topic. Your work shifts from building and supporting engines to managing the subscription, the upgrade cadence and the migration to a licensed product, which still requires code and test changes to your existing jBPM assets.
- Subscription scope: Ask IBM which components, versions and support hours the subscription covers, and whether it includes the rule engine you use.
- Migration effort: Even with a vendor, your BPMN models, work item handlers and rules still need re-validation and regression testing.
- Support boundaries: Confirm who handles production incidents, patches and upgrades, and in what order.
- Lock-in review: Ask what export formats and runtime dependencies would apply if you later change direction.
- Comparison input: Compare the subscription quote with the in-house or partner support cost of the open-source paths, since those costs recur as well.
Before signing, ask IBM for the written support scope and the upgrade calendar, then match them against your own change windows.
How to move off PAM 7 under the constraint
This sequence takes a PAM 7 estate from inventory to a decommissioned platform, with each step producing evidence that the target engine behaves the same way in your own infrastructure. It applies whichever path you choose: IBM BAMOE, self-supported Apache KIE, or Flowable.
Inventory BPMN, DMN and rule assets
Your architecture or process team lists every deployed process, case, decision table, DRL rule package, work item handler and KIE Server container, with its owning application and business owner. Record which assets have running instances, which are called by other systems, and which depend on custom Java code or external services. The output is a register that marks each asset as migrate, rewrite, retire or keep, and that register becomes the scope document for the rest of the sequence.
Stand up the target engine in your infrastructure
Platform engineers provision the chosen runtime in your own cloud account, data center or air-gapped network, alongside a separate non-production environment. For Flowable, choose a production database from the supported list (H2, MySQL, Oracle, PostgreSQL, DB2 or Microsoft SQL Server) and confirm the version against the Flowable configuration docs, since MySQL below 5.6.4 lacks millisecond precision. The step closes when a sample BPMN process deploys, starts and completes through the REST API in each environment.
Re-validate models on the target engine
Import each BPMN and DMN model into the target engine and confirm that it deploys without parse errors. Compare decision outputs against PAM results using a fixed set of representative inputs, and record every difference in a defect log. Business analysts sign off on the behavior of timers, boundary events and escalations, because these are where engines most often diverge. The step closes when every in-scope model passes a signed-off test pack.
Replace work item handlers with service tasks
Developers rewrite each jBPM work item handler as the target equivalent: a Flowable service task or delegate, a Kogito or KIE process task on the Apache KIE path, or the vendor-supported extension point on the BAMOE path. Drools rules that sit behind decisions are either kept as Drools packages on Apache KIE or moved to DMN tables where the logic is simple enough. Each handler gets unit tests and an integration test against a non-production copy of the downstream system. The step closes when the handler suite passes in CI.
Plan multi-node runs and lock recovery
If the target runs on more than one node, confirm how timers and asynchronous jobs are distributed. Flowable's async executor uses a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so expired locks are recovered and picked up by other nodes. Test node failure during a timer firing in staging and verify that no job is lost or executed twice. Confirm the equivalent behavior for IBM BAMOE or Apache KIE with the vendor or your own engineers, because the mechanism differs.
Drain or migrate in-flight instances
Decide for each process family whether running instances finish on PAM or move to the new engine. Draining keeps PAM serving existing instances while new starts go to the target, which avoids state conversion but extends the period PAM must stay in service. Migrating instances requires a tested state-mapping script and a reconciliation report showing that counts and variable values match before and after. Record the agreed approach per process in the register, and do not cut over a family until its instance plan is approved.
Cut over and monitor
Route new process starts and calling systems to the target engine in stages, starting with the lowest-risk process family. Watch error rates, job backlogs and decision exceptions through your monitoring stack, and keep a documented rollback path to PAM until the drain plan is complete. Confirm that the Flowable actuator endpoint or equivalent health checks are wired into alerting. The step closes when all in-scope families run on the target with agreed metrics stable for an approved observation window.
Decommission PAM and retain evidence
After the last PAM instance completes or is migrated, export the final audit and history data your records policy requires, then shut down Business Central and KIE Server and remove their access. Archive the model sources, test packs, reconciliation reports and handler code in your own repository, and update the asset register to show the final state. Confirm with your compliance lead which evidence auditors will request. The step closes when PAM is powered off, its data is retained under your policy, and the register has no open items.
Questions buyers ask before choosing a path
What drives the cost of each path after Red Hat PAM 7 reaches end of life?
The cost depends on which components you pay for, and which of them are one-time versus recurring. An IBM BAMOE path carries a recurring subscription, and the price is set by IBM's quote for your scope, so ask for it in writing. A self-supported Apache KIE path has no license fee, but you pay for migration engineering, the internal or partner support you need for an incubating project, upgrades, testing and the on-call effort to run it. A Flowable path combines open-source engine use with optional commercial editions or professional services. One-time costs include migration, model re-validation and testing. Recurring costs include subscriptions, support contracts, infrastructure and staff time for patches and upgrades. Cost rises with the number of processes, custom work handlers, rule assets and in-flight instances that must be drained.
Which costs are one-time and which recur over the life of the platform?
One-time costs are the ones tied to moving off PAM: inventorying assets, converting or re-validating BPMN, DMN and rule files, rewriting custom handlers, testing, cutover and draining running process instances. Recurring costs depend on the path. Under IBM BAMOE, the subscription recurs and funds vendor support and fixes. Under self-supported Apache KIE, the recurring cost is internal or contracted engineering for security patches, dependency upgrades (the 10.x line moved to newer Java, Quarkus and Spring Boot versions) and incident response. Under Flowable, recurring costs cover any commercial edition or support contract, plus the same operations work you would carry for any self-hosted engine. Ask each vendor which costs repeat and at what trigger.
How long does a migration off Red Hat PAM take, and what changes that timeline?
No supplied fact gives a duration for this migration, so treat any timeline as something to confirm against your own environment. The main drivers are the number of processes and rule projects, how many use custom work item handlers or Drools-specific features, how many process instances are still running at cutover, and how many systems call the engine over its APIs. Regulated environments also add time for validation evidence and change approval. Ask each path for a written scope with phases, the assets it covers and the acceptance tests it expects, so you can compare timelines on the same basis.
What does the migration team need from our own staff?
Expect to supply business owners who can confirm which processes are still in use, engineers who know the current jBPM and Drools code, and someone who owns the production runtime after cutover. You will also need access to the current PAM environment, source repositories, databases and test data, plus a decision on who approves cutover and rollback. On the Flowable path, Java and Spring or servlet skills are needed to embed or deploy the engine. On the Apache KIE path, your team must be able to operate Quarkus or Spring Boot services and track incubating project releases. Confirm these roles in the written scope before work starts.
Can our team support Apache KIE ourselves without a vendor?
Yes, it is possible, but only if you accept the project's status. Apache KIE is licensed under Apache 2.0 and remains in incubation at the Apache Software Foundation, and the foundation notes that incubation does not necessarily reflect the completeness or stability of the code. Self-support means your team or a contracted partner owns security fixes, upgrades and testing for each release. The 10.2.0 release also removed the classic BPMN and DMN editors in favor of a new BPMN editor, so you must plan for editor changes. Ask whether your staff can handle this for the expected life of the platform, and document who responds to an incident.
What should we ask IBM and Flowable to include in a quote?
Ask each vendor for a written scope and a price breakdown rather than a single figure. For IBM BAMOE, ask what the subscription covers, which product versions and support levels apply, the term length, renewal and uplift terms, and what migration help is included or excluded. For Flowable, ask which engines and REST APIs are in scope, whether you need a commercial edition or only the Apache 2.0 engines, what support and professional services cost separately, and how upgrades are handled. For both, ask for a list of named deliverables, acceptance criteria and dependencies on your staff. Compare the quotes on the same scope, not on headline price.
Which path carries the least migration risk for regulated workloads?
No single path is lowest risk for every organization, so compare them on your own workloads. An IBM subscription moves vendor support risk to a contracted party but keeps you tied to IBM's roadmap and terms. Self-supported Apache KIE keeps you free of license lock-in but puts security patching and incubation risk on your team. Flowable offers Apache 2.0 engines with a mature BPMN, CMMN and DMN core and an established commercial vendor behind it, but its 7.0.0 release removed some features, such as the UI applications and async history, so confirm what your processes depend on. In every case, run a parallel test, plan a rollback and drain running instances before cutover.
Evidence to keep for the decision and the cutover
Whichever path you choose, auditors and internal risk teams will ask the same questions: what you had, what you tested, what happened to running work, and who supports the result. The cards below cover the records that answer those questions for a move away from Red Hat Process Automation Manager 7.x. None of them is a certification, and each should be kept current through the cutover.
Written asset inventory
List every jBPM process, Drools rule package, DMN decision model, work item handler, custom service and integration endpoint, with its owner, version and business purpose. Record where each asset is deployed today, including Business Central spaces and KIE Server containers. This inventory defines the scope of the decision and tells you which assets must be re-validated on IBM BAMOE, Apache KIE or Flowable. Confirm it with the process owners, not only the platform team.
Re-validation test results
For each re-validated BPMN, DMN and rule asset, keep the test cases, the input and expected output data, and the results on the target engine. Capture differences in gateway behavior, timer handling, expression evaluation and error boundary events, and record how each was resolved. Auditors often ask whether a decision produced the same outcome before and after the change, so keep side-by-side results for regulated decisions.
Drain or migration record for in-flight instances
Document how running process instances were handled: completed before cutover, migrated to the new engine, or left on the old runtime until they finished. Record instance counts at each checkpoint, timers and asynchronous jobs that were moved, and any instances that could not be migrated and how they were closed. Without this record, you cannot show that no case or payment was lost or duplicated during the move.
Support agreement for the chosen runtime
Keep the signed support terms for the path you take. For IBM BAMOE, this is the subscription and its support terms. For self-supported Apache KIE, which is still in incubation at the Apache Software Foundation, record who answers defects and security issues, whether a partner is engaged, and the response expectations agreed internally. For Flowable, record the open-source versus commercial edition decision and the support coverage that goes with it.
Change records and rollback plan
Keep a change record for each deployment step, including approvals, the version deployed, the configuration changed, the person responsible and the rollback steps tested before cutover. Store these alongside the inventory and test results so that each production change can be traced to an approved decision. Reviewers look for evidence that the rollback path was rehearsed, not only described.
What a fixed-scope migration covers
A fixed-scope engagement starts with a written scope that names the systems, process definitions, rule assets and deliverables before any work begins. For a Red Hat PAM 7 estate, the assessment phase usually means inventorying the Business Central projects, the KIE Server deployments, the jBPM process definitions, the Drools rule packages and any custom work item handlers, then deciding which of those move, which are retired and which need a rewrite. DeployOpen plans that assessment with you so the target choice, whether IBM BAMOE, Apache KIE or Flowable, is made on the inventory rather than on assumptions. Ask the vendor or DeployOpen to show exactly which artifacts the assessment will list and how each one is classified.
The target build and model re-validation phases cover the parts that break most often in a PAM move. Each BPMN model is re-run on the chosen engine, service tasks and work item handlers are reimplemented, and DMN decisions are checked against expected outputs using test cases you approve. Cutover planning covers what happens to in-flight process instances, including whether they finish on the old runtime or are drained first, and which environments are switched and in what order. Documentation covers the runbooks, configuration, identity wiring and backup procedures for the platform you run afterward. Confirm with DeployOpen which of these items are fixed deliverables and which are listed as options in your written scope.
Ongoing support is handled separately from the fixed-scope migration. Upgrades to the target line, security patch handling and continuous testing can be contracted as a retainer after cutover, which matters if you choose Apache KIE, since it is still incubating at the Apache Software Foundation. Ask for the retainer terms in writing, including response expectations and what is excluded, and keep them distinct from the migration scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence produced during the migration should be reviewed with your independent auditor.
How DeployOpen approaches PAM exits
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Red Hat PAM exit, we start from your running process and rule estimate, agree a written scope, and then move the work through build, testing and handover at a pace your change control allows.
How we scope
- Inventory every BPMN, CMMN, DMN and rule asset, plus the Business Central and KIE Server dependencies each one uses.
- Identify in-flight process instances and agree how they drain or migrate before any cutover date is set.
- Confirm which support route you choose (IBM BAMOE, self-supported Apache KIE or Flowable) before the written scope is signed.
How we build
- Re-validate BPMN models on the target engine and record every behavior difference found during testing.
- Replace work item handlers with the target's service tasks or delegates, and wire identity through the engine's identity service interface.
- Configure the database, async executor and clustering settings for your environment, then test failover between nodes.
How we hand over
- Deliver written runbooks for deployment, backup, upgrade and rollback, owned by your team after handover.
- Document the migration decisions, test results and open risks so auditors and internal reviewers can trace each change.
- Train the operators who will run the platform, using your own models and environment rather than generic examples.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm in writing which support obligations stay with your team and which sit with the retainer.
