Which open-source option replaces Red Hat Decision Manager rules and DMN?
Apache KIE is the closest match for the Drools and DMN workloads that Red Hat Decision Manager carried, because Drools is the rule engine at the core of both products. Flowable's DMN engine fits better when your decisions are mostly decision tables evaluated inside a process, and IBM's successor to Process Automation Manager is the path if you need a vendor-supported contract. Start by inventorying what runs today: rule units, DMN models, decision tables, and the services or processes that call them. Every option here can run in your own cloud account, data center or air-gapped network, so the choice is about fit and support rather than where the decisions execute.
The right choice depends on rule complexity and on the authoring tools your analysts use. Apache KIE 10.2.0 replaced the legacy GWT-based tooling with a new BPMN editor and removed the classic BPMN and DMN editors, and it added DMN 1.6 support. If analysts edit DMN in Business Central today, test that exact workflow on the 10.2.0 line before you commit. Flowable 7.0.0 removed the UI applications from the open-source edition, so decision authoring there usually moves into models managed in source control, or into a commercial Flowable edition if your business users need a visual editor. Confirm which of these your team actually depends on.
Accepting an incubating project is the decision that most often stalls these migrations. The Apache KIE site states that incubation does not necessarily reflect the completeness or stability of the code, so a regulated rule estate needs a named support model, in-house or through a partner, before go-live. Pin to the incubator-kie-drools codebase rather than the archived Kogito repositories, whose code has moved there. On the Flowable side, version 8.0.0 requires Spring Boot 4 with no backward compatibility for Spring Boot 3, so Spring applications on Boot 3 need their own upgrade plan. Review the Flowable open source materials against your decision volume and support requirements before choosing.
How Drools, DMN and decision tables map to open-source options
This table maps each Red Hat Decision Manager capability to Apache KIE, Flowable's DMN engine and IBM's successor, with a coverage note for each. Read the notes as the minimum you can confirm from published sources, and verify every gap and open question with the project or vendor before you commit to a migration path.
| Capability | Apache KIE | Flowable DMN engine | IBM successor (BAMOE) |
|---|---|---|---|
| Drools rule engine | Drools is the core rule engine of Apache KIE, under Apache-2.0 and still incubating at the ASF. | No Drools engine. Rule logic moves to DMN, Java code or service tasks. | Confirm with IBM whether the Drools rule engine is included in the successor product. |
| DMN decision models | DMN 1.6 support arrived in Apache KIE 10.2.0. Confirm the level of TCK conformance with the project. | DMN engine ships with the open-source engines and runs in embedded or REST modes. | Confirm DMN version and execution scope with IBM. |
| Decision tables | Decision tables are a DMN construct. Because the classic DMN editor was removed in 10.2.0, confirm how you author them today. | Supported by the DMN engine. Confirm which hit policies and expression features your tables use. | Confirm decision table support and any editor included in the open edition. |
| Rule authoring and versioning | Rule and model assets are project artifacts you can keep in Git. Confirm the supported authoring tools for your team. | Models are deployed as versioned definitions in the engine. Authoring happens in your own tools or code, since the open-source UI applications were removed in Flowable 7.0.0. | Confirm the authoring environment and how versions are promoted between environments. |
| Decision services exposed over APIs | Kogito-based runtimes can expose decisions as services. Confirm the generated API surface and how it is secured. | Decisions are reachable through the Flowable REST application or your own endpoints, with Java APIs for embedded use. | Confirm the REST and event interfaces and their authentication options. |
| Business-user editing | The classic BPMN and DMN editors were removed in Apache KIE 10.2.0, and a new BPMN editor replaced the legacy GWT-based tooling. Confirm whether any DMN editing remains for business users. | No open-source business-user designer. Low-code modeling, visual debugging and governance are in the commercial Flowable editions. | Confirm whether business-user authoring is included in the open edition and what license covers it. |
| Deployment on containers | Apache KIE 10.2.0 moved to Quarkus 3.27.2 and Spring Boot 3.5.10. Confirm the container build path and the supported runtime for your stack. | Runs embedded in Spring, Tomcat, Jetty or Java EE, or as a standalone REST service. Flowable 8.0.0 requires Spring Boot 4. | Confirm supported container images, operators and platforms with IBM before planning the build. |
Apache KIE, Flowable DMN and IBM's successor: when each fits
Decision Manager users usually need one of three things: Drools and DMN models kept close to the original runtime, a lighter DMN engine embedded in a process application, or a vendor-supported path from IBM. The cards below set out when each option fits, what it costs you in trade-offs, and the question to put to each party before you commit.
Apache KIE for Drools and DMN
Apache KIE is the home of Drools, jBPM, Kogito and related tools under the Apache License 2.0. It is the closest open-source lineage to the rule engine and DMN assets you already run, so it fits rule-heavy applications that need Drools rules and DMN models kept largely intact. The main trade-off is that the project is still in incubation at the Apache Software Foundation, which the project itself says does not necessarily reflect the completeness or stability of the code. Plan for self-supported operations unless you buy support elsewhere. Ask the project which 10.x release line and Java version your rule assets need, since 10.2.0 added Java 21 support and DMN 1.6.
Flowable's DMN engine
Flowable is an Apache-2.0 Java engine that supports BPMN, CMMN and DMN, and it can run embedded in your application as a JAR or as a standalone service with REST APIs. It suits simpler decision tables that sit inside a process application, where the decision is called from a BPMN flow and the team already runs Java. The trade-off is scope: it is a decision table engine within a process platform, not a full replacement for Drools rule authoring, so complex rule sets will need redesign. Ask Flowable whether your DMN models and decision tables load on the version you target, since Flowable 8.0.0 requires Spring Boot 4 and has no backward compatibility for Spring Boot 3.
IBM's Decision Manager successor
IBM has positioned its Decision Manager Open Edition and the wider Business Automation Manager lineage as the vendor-supported successor path for Red Hat Process Automation Manager users. This fits teams that need a contracted support route, an IBM roadmap and formal indemnities more than they need open-source governance. The trade-off is that scope, licensing and what counts as the Open Edition may differ from the Red Hat product you run, so do not assume feature parity. Confirm with IBM the exact product name, which components are included, the support term, the license terms for production use and how Drools and DMN assets migrate before you decide.
How decision services sit beside your process engine
This pattern keeps your current process engine in place and treats the decision service as a separate callable endpoint. The process model sends the facts it needs as a request, receives a decision result, and continues its flow. Because the decision layer is separate, rule changes can be deployed without redeploying the process models, but every call becomes a network dependency that needs timeouts, retries and error paths in the process.
- Call pattern: Process service tasks send JSON or XML payloads to a decision endpoint over HTTP, and the response becomes process variables.
- Rule versions: Versions live with the decision service's own asset store. Record which version answered each decision in the process history so audits can reproduce it.
- Identity and access: Authenticate service-to-service calls with client credentials or mutual TLS, and limit which process definitions may invoke which decision endpoints.
- Integration points to test: Payload schema drift, timeout and retry behavior under load, and what the process does when the decision service is unavailable.
Confirm with your engine vendor whether its HTTP task supports certificate-based authentication and per-call correlation identifiers in your version.
This pattern moves processes onto Flowable and runs DMN decision tables in the same engine, so a decision task is a local call with no network hop. Flowable's BPMN, CMMN and DMN engines can be embedded as a JAR in a Java SE application, in a servlet container such as Tomcat or Jetty, or in a Spring application, or they can be run as a standalone service and called over HTTP through the Flowable REST application. Choosing the embedded or REST model is the main architecture decision in this pattern.
- Call pattern: A DMN decision task evaluates a deployed decision table inside the same JVM as the process, or the REST API evaluates it for external callers.
- Rule versions: DMN models are deployed to the engine's repository as versioned deployments. Process instances started before a redeployment keep the version they began with, so plan the drain of in-flight work.
- Identity and access: Flowable's identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP reference implementation is provided. Map your directory groups to the candidate groups that control who can start or complete tasks.
- Integration points to test: Deployment order during upgrades, the async executor's behavior across nodes, and the database types you run, since Flowable documents H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server.
Confirm the Flowable version and Spring Boot line you need before choosing a starter, because the 8.0.0 release moved to Spring Boot 4 without backward compatibility for Spring Boot 3.
This pattern keeps rules as Drools artifacts inside a Java application, typically built on the Apache KIE projects. The rules run in the application's process and are updated by building and deploying a new version of the artifact, or by loading versioned rule packages through a release mechanism you control. It suits rule-heavy logic that is tightly coupled to application code, and it moves more responsibility for packaging and governance into your development pipeline.
- Call pattern: Application code creates a session, inserts facts and fires rules, or calls a DMN model through the KIE APIs.
- Rule versions: Rule versions are tied to artifact versions in your repository and build system. Pin the Drools version in the dependency management of each application.
- Identity and access: The rules engine itself has no user directory. Access control comes from the application that calls it, so enforce authorization before facts reach the session and log who triggered each evaluation.
- Integration points to test: Behavior after upgrades to a new Apache KIE release, Java runtime compatibility, and concurrency of sessions under production load.
Apache KIE is incubating at the ASF, so confirm which release line your organization will rely on and who will patch it before you embed it in regulated systems.
Moving Drools rules and DMN models off Decision Manager
This sequence moves rule packages, decision tables and DMN models from Red Hat Decision Manager into source control and onto a target engine, with recorded test results proving each decision still returns the same outputs before traffic is switched.
Inventory every rule package and decision asset
Your team lists each rule package, decision table, DMN model and spreadsheet-based decision in Business Central, along with the services, batch jobs and processes that call each one. Rule owners confirm which decisions are still in use and which are dead code. Done means a register that maps every asset to its owner, its consumers and the version currently deployed in production, so nothing is migrated blind.
Export assets from Business Central into source control
Export each project from Business Central as its source files, including DRL, DMN, BPMN and decision table spreadsheets, and commit them to a Git repository your organization controls. Keep the Maven coordinates and version of each deployed artifact in the same repository. Done means a clean build of the exported projects succeeds locally, and the commit history gives you a baseline to compare against later.
Choose the target engine and validate models against it
Decide between Apache KIE for Drools and DMN on Quarkus or Spring Boot, the IBM successor path, or Flowable's DMN engine for simpler decision tables. Load each DMN model and rule project into the chosen engine's build and compile it, then fix dialect, function or datatype differences. Note that Apache KIE is still incubating at the ASF, so confirm the release line and support arrangements before committing. Done means every asset compiles and loads on the target without manual edits left undocumented.
Re-run decisions against recorded test cases
Build a regression suite from recorded production inputs and their known outputs, covering normal cases, boundary values and the rules that fire rarely. Rule owners review and sign off on the expected results before the run. Execute the suite on the old and new runtimes side by side and investigate every difference, including changes in hit policy, rounding or null handling. Done means the target returns the approved output for every recorded case, with differences either fixed or formally accepted.
Cut over decision services by version
Deploy the validated decision services to a staging environment, then route a limited share of traffic to them while the old runtime still serves the rest. Use versioned endpoints so you can point consumers back to the Decision Manager version without a redeploy. Monitor decision outcomes and error rates against the baseline. Done means each consumer has moved to the new service, and you have a documented rollback path for each one.
Retire the old runtime after in-flight work completes
Confirm that no running process instances, pending decisions or scheduled jobs still depend on the old KIE Server or Business Central deployment. Archive the final exports, the test evidence and the sign-off records, then shut the old runtime down. Keep the archive for your audit and records retention rules. Done means the old runtime has no active consumers, the archive is complete and the decommissioning decision is recorded.
What Apache KIE's incubating status means for your rules
Apache KIE is still in incubation at the Apache Software Foundation, and that status should shape how you plan rule upgrades. The KIE project's own site notes that incubation does not necessarily reflect the completeness or stability of the code, only that the ASF has not yet fully endorsed the project. In practice, Drools, jBPM and the Kogito-derived runtime are open source under Apache License 2.0, but the release cadence and compatibility guarantees are those of the community, not of a vendor with a support contract behind them. The release history is the first input to your plan. Apache KIE 10.0.0 was tagged on December 11, 2024, as the first major release under the ASF, and it came 15 months after the previous release on September 5, 2023. Later tags were 10.1.0 on July 8, 2025 and 10.2.0 on April 28, 2026. Each major line brought platform upgrades, including Java 21 support and DMN 1.6 in 10.2.0, and removed the classic BPMN and DMN editors. Confirm which Java, Quarkus or Spring Boot baseline your rules and services need before choosing a target, and check the release notes for every version between your current build and the target.
Kogito is a second thing to track. The archived Kogito Runtimes and Kogito Apps repositories have had their code moved into the apache/incubator-kie-drools repository, so older Kogito references in build files, documentation and tutorials may point to dead locations. Inventory every dependency coordinate and repository reference in your rule and process projects, and map each one to its current home before you change any version number. Because no vendor is assumed to stand behind the upgrade, you need two things before you move production rules. The first is your own regression suite: a set of decision inputs with expected outputs, covering each DRL rule set and DMN decision table, run on every candidate release. The second is a named support route, whether an internal team with Drools expertise, a partner under a fixed-scope agreement, or a retainer, agreed in writing before the migration starts. Ask who will triage a defect in an incubating release and how quickly they can ship a fix.
What you pay for when you run decisions yourself
Running Drools and DMN yourself moves cost from a license line to a set of components, each paid to a different party and each with its own one-time or recurring profile. The cards below separate those components so you can ask for each one in a written quote and compare it against a vendor subscription.
Rule and model re-validation
Your team, or a partner you hire, re-tests every DRL rule set, DMN decision table and BPMN model against the new runtime, because behavior can shift between engine versions. This cost is one-time per migration wave, but it grows with the number of decision tables and the depth of custom Java in rule consequences. Ask the provider to state which assets are in scope, how regression data is produced, and who signs off on the results.
Runtime and database infrastructure
You pay your cloud or data center provider for compute, storage, backups and the database that holds decision state and audit history. This is recurring, and it scales with transaction volume, number of environments and retention rules. Confirm which database engine your platform team supports, since the Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types.
Internal or partner support for an incubating project
Apache KIE is still in incubation at the Apache Software Foundation, so no vendor carries the support contract that Red Hat provided. You either staff engineers who know Drools and jBPM internals or pay a partner for fixes, patch backports and on-call coverage. Request in writing the response expectations, the versions covered and who owns security patches for components you run.
Recurring upgrades and regression testing
Each new engine release brings dependency changes, such as Java, Quarkus or Spring Boot baseline moves, and every upgrade needs a full regression pass across your decisions. This is recurring work tied to the release cadence you choose, not a one-time project. Ask whether the plan includes a fixed number of upgrade cycles per year and how breaking changes are documented and tested before production.
Successor subscription, if you choose IBM
If you move to IBM's successor product instead of self-supporting Apache KIE, the subscription is the main recurring license cost, and you still pay for the infrastructure and migration work above. Read the subscription terms for the core count or usage metric, the support tier, and what happens to the subscription at renewal. Request the price in writing from IBM and compare it with the internal and partner support costs for the open-source path.
How much effort does a Decision Manager replacement take, and can we do it ourselves?
How does the number of rule packages and DMN models affect cost?
The number of rule packages and DMN models is the main driver of effort, because each one has its own dependencies, tests and deployment unit. Start with an inventory: every rule module, every DMN file, the decision services that call them, and each BPMN process that reaches them through a business rule task. One-time costs cover analysis, conversion, test building and cutover. Recurring costs cover maintaining the runtime and the rules after go-live. Decision tables and imperative Drools rules convert with very different effort, so ask any quote to price them separately. Also ask whether shared libraries are counted once or per package.
Can our team migrate from Red Hat Decision Manager in-house?
Yes, a team with Java, Drools and DMN experience can often do the migration in-house, but it then owns every upgrade and every support question. Apache KIE is licensed under Apache 2.0 and is still in incubation at the Apache Software Foundation, so no vendor carries the support load unless you buy it elsewhere. Check your skills in the runtime you choose, whether Quarkus or Spring Boot, and in Java versions, since Apache KIE 10.2.0 added Java 21 support. Confirm your team can run regression tests and keep the build pipeline current. If any of these are thin, a fixed-scope partner engagement can cover specific parts of the work.
What do business rule owners and testers need to contribute?
Rule owners must state the intended outcome for representative cases, including edge cases, exceptions and default values, and sign off on decision tables before cutover. Testers need a regression set made of real historical inputs with the outputs the current system produced, so differences can be measured. Expect rule owners to be the scarcest resource, because they must review converted tables against policy wording that may be years old. Ask the project for named owners, review dates and a written process for resolving disputed outputs. Without these people, the technical conversion finishes but the business cannot approve it.
How long does a Decision Manager migration take, and what sets the timeline?
No duration has been established for this migration, so treat any single figure with caution and ask for a milestone plan in writing. The main drivers are the number of rule packages and DMN models, the number of integrations that call decision services over REST or Java APIs, and how much regression coverage already exists. Approval cycles for rule owners, environment access, and the choice between Quarkus and Spring Boot also move the schedule. Running in-flight process instances through a cutover adds time if BPMN processes depend on the rules. Ask the scope document to list each milestone, its exit criteria and the client decisions it depends on.
Is IBM's successor or Apache KIE cheaper, and what should we ask in a quote?
Neither option can be called cheaper without comparing the full cost components. IBM's successor is a subscription, so its cost recurs and depends on the support term and scope you buy. Apache KIE carries no license fee, but you pay in-house staff or a partner for upgrades, support and security fixes, and the project is incubating, which the Apache KIE site notes does not necessarily reflect the completeness or stability of the code. Ask IBM for subscription scope, support hours, upgrade rights and exit terms. Ask DeployOpen for a fixed scope listing deliverables, responsibilities and timelines. DeployOpen does not publish a price list, so a quote follows from that written scope.
How do we test that new decisions match the old outputs?
Run the old and new engines on the same captured inputs, then compare outputs field by field and classify every difference as expected or defective. Build the input set from production logs covering common cases, boundary values, null fields, date and time handling, rounding and each DMN hit policy in use. Keep the Red Hat Decision Manager environment running in parallel until the comparison set produces no unexplained differences for an agreed period. Store expected results in version control so rule changes trigger the same tests. Ask any partner to show its comparison tooling and how it records approved differences for audit.
What does DeployOpen cover in a Decision Manager replacement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. A quote follows from the written scope.
How DeployOpen scopes and delivers a decision service migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For rule-heavy applications, we start by inventorying the decision assets and the systems that call them, then build the replacement engine in your environment and hand it over with documentation your team can run.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- The inventory covers Drools rules, DMN models, jBPM processes and the callers that invoke them.
- The written scope states which engine is in play: Apache KIE, IBM's successor edition or Flowable's DMN engine.
How we build
- We stand up the chosen decision engine in your cloud account, data center or air-gapped network.
- Each rule set and DMN model is re-run against recorded inputs to confirm outputs match the current system.
- Integration with your data stores, identity provider and logging is built and hardened to your security baseline.
How we hand over
- Deliverables include architecture notes, deployment configuration, runbooks and a record of test results.
- Your team receives the decision assets in their source form, with ownership and change steps documented.
- Compliance evidence is prepared for your assessors, who issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade work tracks the release line you select, so version changes are tested before production.
- Ask the team to confirm support terms, response expectations and patch responsibility in the written scope.
