Red Hat PAM cost vs self-supported Apache KIE: where the money goes
The comparison between an IBM BAMOE subscription and self-supported Apache KIE turns on who pays for support, upgrades and skills, not on license fees alone. Apache KIE is licensed under the Apache License 2.0, so there is no license line item to negotiate. What replaces it is a set of recurring labor and risk costs that you carry yourself or buy from a partner. Before you compare any quote, write down who will answer a production incident at 2 a.m., who will rebase your patches onto each new release, and who will test your BPMN, DMN and rule assets against every upgrade.
Apache KIE is still in incubation at the Apache Software Foundation. The KIE site is explicit that incubation does not necessarily reflect the completeness or stability of the code, only that the ASF has not yet fully endorsed the project. The release cadence is a planning input: 10.0.0 was tagged on December 11, 2024, 10.1.0 on July 8, 2025 and 10.2.0 on April 28, 2026. Each line brought platform upgrades, and 10.2.0 replaced the legacy GWT-based BPMN tooling and removed the classic editors. Budget for regression testing of your own models and rules on every minor release, and confirm with your engineering team how many hours that testing takes today.
Build the quote request around the components: migration engineering, a support arrangement for an incubating project, a named internal owner for the runtime on Quarkus or Spring Boot, the upgrade and regression cycle, and a security patch process you can evidence to auditors. Ask any partner to state in writing which of these are fixed scope and which are retainers, and ask the vendor for BAMOE's support terms, lifecycle dates and included upgrades so the two options are compared on the same basis. The cheaper license line often hides the larger recurring cost, which is staff time that stays with you for as long as you run the platform.
Which cost components change when you leave the subscription
This table sets the IBM BAMOE subscription and IBM support against a self-supported Apache KIE deployment, row by row, and marks each cost as one-time or recurring. Read the commercial column for what IBM bills, and the Apache KIE column for what your organization or a partner must fund instead. No prices are shown because none were supplied; use the rows to frame your quote request.
| Cost component | IBM BAMOE subscription | Self-supported Apache KIE |
|---|---|---|
| Subscription or license | Recurring: annual subscription from IBM covering the runtime and its support entitlement. Ask IBM for the exact metric and term. | Recurring: none for the Apache-2.0 code. Costs move to people and infrastructure. |
| Infrastructure | Recurring: runs on your platform under IBM's supported container and Kubernetes guidance. Confirm the supported versions. | Recurring: you size and run the Quarkus or Spring Boot runtimes, databases and CI pipelines yourself. |
| Migration effort | One-time: moving jBPM and Drools assets to the BAMOE runtime. Ask IBM which Red Hat PAM 7 assets it expects you to change. | One-time: moving to the Apache KIE 10 line, including testing BPMN, DMN and rule assets and retiring KIE Server and Business Central patterns. |
| Implementation | One-time: IBM services or a partner, if you buy them. Scope is set by your contract. | One-time: internal teams or an implementation partner, scoped in writing before work starts. |
| Support | Recurring: vendor support tied to the subscription, with a published escalation path from IBM. | Recurring: an in-house or partner support model you must staff. Apache KIE is still incubating, so the ASF does not endorse it as a fully mature project. |
| Upgrades and patching | Recurring: vendor-provided releases and fixes within the subscription. Confirm the upgrade path from your current PAM version. | Recurring: you track Apache KIE releases, such as 10.2.0, test them and apply patches. Budget for a regular upgrade cycle. |
| Internal skills | Recurring: staff who operate IBM's packaged runtime and work with its support team. | Recurring: engineers who know Drools, jBPM and Kogito well enough to maintain code without a vendor safety net. |
| Risk | Lower vendor-dependency risk on support continuity, while you remain tied to IBM's licensing terms and roadmap. | Higher operational risk for an incubating project, offset by open code you can fork, audit and maintain. |
What moves the cost of running Apache KIE yourself
Running Apache KIE without a vendor shifts cost from a subscription line to the engineering hours, testing and operations your team absorbs. The drivers below set how large that work is, and most of them compound: a larger asset inventory raises the testing load, and a stricter change window raises the cost of every cutover step.
Number of process and rule assets
Every BPMN process, DMN decision table, Drools rule package and work item handler is an asset you must re-validate on the Apache KIE 10 line. Cost rises with the count and with how many assets depend on Business Central-specific features. Ask your team to inventory assets by type and by owner before estimating effort, and note which ones have no test coverage today.
In-flight process instances at cutover
Running process instances hold state that must either finish on the old runtime or be migrated. Large numbers of long-running instances increase the work to drain or migrate them and the risk of mismatched definitions. Confirm with the business owners how long instances live and whether any can be cancelled or restarted safely.
Deployment target on Kubernetes
The Kogito-based runtime runs on Quarkus or Spring Boot, typically in containers on Kubernetes, which differs from the KIE Server and Business Central model. Choosing one framework and one cluster pattern early keeps build pipelines and operations simple. Mixed targets add platform engineering time, and the team needs someone who can run that stack after handover.
Availability and change-freeze requirements
Regulated services often have limited change windows and quarter-end freezes. Those constraints decide whether you can run old and new runtimes in parallel, how long dual running lasts, and how many rollback rehearsals you need. Tighter windows push cost up through parallel infrastructure and extra test cycles, so write the allowed windows into the plan before scheduling.
Java and Drools team skills
Without a vendor support contract, your own engineers diagnose engine issues, rule behavior and framework upgrades. Teams with strong Java, Quarkus or Spring Boot and Drools experience carry less external support cost. Thin skills in these areas raise the need for a partner for an incubating project. Assess current staff against these skills before deciding how much to outsource.
Environments that must be validated
Each environment, such as development, test, pre-production and production, needs its own deployment, configuration and regression run. More environments, and more regulated copies of production data, multiply the validation effort and the evidence you retain. Ask which environments already exist and whether they match production closely enough to count as validation.
How to build the comparison with your own numbers
This sequence turns a renewal quote and a migration idea into a side-by-side model of what BAMOE and self-supported Apache KIE each cost over the same period, so the decision rests on your asset inventory and your staffing rather than on general claims.
Inventory BPMN, DMN and rule assets
Engineering leads list every BPMN process, DMN decision model, Drools rule package and custom work item handler in the current Red Hat PAM estate, with the owning team, the number of running instances and the business criticality of each. Group them into asset classes so later costs can be attached to each class. The step is done when the inventory has a row for every deployed asset and a second list of assets that have no active owner.
Map runtime and Business Central dependencies
Architects trace which assets depend on KIE Server, Business Central, the process designer, the rules workbench, specific persistence settings and any external systems called from service tasks or handlers. Each dependency is marked as portable, portable with changes, or tied to a Red Hat-specific packaging or deployment choice. The output is a dependency map that shows which items would need reimplementation under Apache KIE 10 on Quarkus or Spring Boot, and which would need changes if you moved to a different engine.
Request BAMOE subscription terms in writing
Procurement asks IBM for the BAMOE subscription terms in writing, covering the price basis, what is included, support scope, update and fix entitlement, term length, renewal conditions and any change in terms over the comparison period. Ask which product versions and support lifetimes apply, and how the subscription is counted for your deployment model. The step is complete when you hold a written quote and a list of open questions that IBM has answered in writing.
Cost migration and test effort per asset class
Engineering and QA estimate the effort to convert, re-test and certify each asset class from the inventory, including BPMN re-validation, DMN and rule regression testing, handler rewrites and instance draining or migration for in-flight work. Estimates are made by people who know the code, not copied from a template. The output is a table of effort per asset class with assumptions written beside each figure, and this effort is treated as one-time cost in the model.
Price internal or partner support for an incubating project
Finance and engineering management price the support model for Apache KIE, which is still incubating at the Apache Software Foundation. Include internal staff time for patch triage, security monitoring, build and dependency maintenance, and on-call coverage, and compare it with any partner retainer quote written against a stated scope. The output is an annual support cost line for each option, with the named owner and the skills it requires. Ask any partner to state which versions, response expectations and security fix handling are in scope.
Add an upgrade cadence and risk allowance
The platform team writes the upgrade calendar for each option, including the expected effort to move between Apache KIE releases and to absorb IBM's successor-version changes, and adds a contingency line for risk such as a stalled release, a breaking API change or an unplanned rewrite. The check is that every recurring upgrade has an owner and a trigger, and that the contingency is a stated amount with a documented basis rather than a hidden margin.
Model at least two cases over one period
Finance builds at least two cases over the same comparison period, for example a BAMOE case and a self-supported Apache KIE case, with one-time migration costs, recurring subscription or support costs, staffing and risk allowance shown separately. Run a sensitivity check on the drivers that move the result most, such as asset count, support staffing and the subscription term offered. The output is a model that a CISO, CIO and procurement can read, where each number traces back to a row in the earlier steps.
What incubation means for an Apache KIE support plan
Choosing self-supported Apache KIE means accepting that the project is still in incubation at the Apache Software Foundation, and that status shapes what you can expect from it. The Apache KIE site is explicit that incubation does not necessarily reflect the completeness or stability of the code. It only means the ASF has not yet fully endorsed the project. Treat that as a statement about governance maturity, not a verdict on quality, and plan your support model on that basis.
Operationally, the vendor's support work moves to your team. You carry the vetting of each KIE release before it enters your environment, tracking of security fixes across Drools, jBPM and Kogito, and upgrade testing of your BPMN, DMN and rule assets against each new line. Recent releases have been large: Apache KIE 10.2.0 replaced the legacy GWT-based BPMN editor, removed the classic BPMN and DMN editors and moved to Java 21. Each of those changes needs a regression plan, a named owner and a decision on whether your authoring tools still work. Price that ownership into the comparison with IBM BAMOE, not only the subscription line.
Note also that the Kogito Runtimes and Kogito Apps repositories are archived, and their code now lives in the apache/incubator-kie-drools repository. Any internal build pipeline, dependency pin or documentation link that points at the archived repositories should be found and repointed before you commit to a version. Ask the community directly, through its mailing lists and issue tracker, what release cadence, backport policy and security response window it intends to follow during incubation, and whether it publishes a security contact. Get those answers in writing before you put a support model in a budget.
Questions buyers ask before comparing BAMOE and Apache KIE
How much effort does a migration from Red Hat PAM to Apache KIE take?
The effort depends mostly on how much of your estate uses jBPM processes, Drools rules and Business Central authoring, and how much custom code sits on top of KIE Server. Each of these drives the work: the number of BPMN and DMN assets to re-test, the number of work item handlers to rewrite, the number of rule packages that depend on specific Drools behavior, and whether you move from KIE Server to a Kogito-based runtime on Quarkus or Spring Boot. Teams with a small, well-tested asset set usually find the work is mostly regression testing. Ask any provider for an effort estimate broken down by these items, and ask them to list what they will not change.
Can our team support Apache KIE ourselves?
Yes, if you have engineers who can operate Java applications on Quarkus or Spring Boot, manage Kubernetes or your chosen container platform, and debug Drools and jBPM behavior from source. Apache KIE is licensed under the Apache License 2.0 and is still in incubation at the Apache Software Foundation, which the project itself notes does not necessarily reflect the completeness or stability of the code. That means you own patching, upgrades and security response, and you need a plan for when the community is slow to answer. Assess your bench honestly before deciding, and treat self-support as a staffing decision rather than a licensing one.
What does a partner support engagement cover in general terms?
A partner engagement is usually scoped in writing before work starts and can include planning the migration, converting and testing assets, hardening and backing up the runtime, documenting it, and running upgrades. Ongoing support and continuous testing are typically offered as a retainer, separate from the one-time migration. DeployOpen implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope. Ask any partner which items are included, which are excluded, who holds on-call responsibility, and what happens when an upstream release changes behavior.
How long does a migration take?
No public duration applies to your case, so take the timeline from your own migration plan rather than from a generic figure. The main inputs are the number of process and rule assets, the depth of custom integration, the number of in-flight process instances that must drain or migrate, and the test coverage you already have. Ask your team to build the plan in phases, with a cutover window and a rollback path for each phase, and ask any partner to tie their timeline to the same phases in writing.
Can BAMOE and Apache KIE run side by side during cutover?
They can run side by side in principle, because they are separate runtimes, but the practical question is whether your processes, data stores and integrations can be split between them without duplicate work or conflicting state. Plan for in-flight process instances to finish on the runtime where they started, and confirm that no shared database schema or messaging topic is written by both. Confirm the exact coexistence pattern with IBM for BAMOE and with your own architects for the KIE side before you commit to a dual-running window.
What should we confirm with IBM and the Apache KIE community before signing?
Before signing with IBM, confirm the subscription term, the supported versions, the upgrade path from your current PAM 7 assets, the support scope for custom extensions, and what happens at the end of the term. For Apache KIE, confirm the current release line you will target, the release cadence, the security advisory process, and the project's incubation status and any graduation plans. Also confirm which Java, Quarkus and Spring Boot versions your target line supports. Get these answers in writing, and keep a record of the release notes you relied on.
What is the main risk of choosing self-supported Apache KIE?
The main risk is that a single incubating project becomes a key-person dependency, with security patches and upgrades depending on a small group of engineers and community responders. You can reduce that risk by pinning versions, keeping a tested upgrade path, documenting custom code, and deciding in advance who responds to a vulnerability. Weigh this against the recurring subscription cost and the lock-in that comes with a vendor, and record the decision with its assumptions so it can be revisited at the next release.
When a subscription still makes sense and when self-support fits
A vendor subscription lowers risk most when your organization cannot absorb a production defect in the process engine without a contractual party to call. IBM's BAMOE subscription puts a named vendor behind the runtime, with patches and support terms defined in the contract. That matters for regulated teams that must show an auditor who is accountable for a fix, for estates with few engineers who already know the jBPM and Drools internals, and for organizations whose change control requires a supplier to sign off on each upgrade. Before you sign, ask IBM for the support scope, the supported component list, the upgrade path from your current 7.x assets, and the end date of each version, and compare these against the sibling comparison of IBM BAMOE, Apache KIE and Flowable options.
A self-supported Apache KIE estate is viable when you have a platform team that can own the runtime, a partner that can take on patch and incident work under a fixed-scope agreement, and a tolerance for an incubating project. The Apache KIE site is explicit that incubation does not by itself say how complete or stable the code is, so the decision rests on your own testing. Teams that do well usually keep a written upgrade cadence, pin dependency versions, maintain a regression suite of BPMN and DMN assets, and document who triages a CVE. Ask any partner for the named engineers, the response expectations in writing, and how they will handle a fork if upstream stalls. The subscription line item disappears, but the staff time, testing and partner retainer remain.
Most organizations sit between these poles, and the right choice often depends on which risk your board or auditor will accept. A useful test is to write down the three incidents you most fear, such as a stalled upgrade during a regulatory deadline, a critical defect with no patch, or the loss of a key engineer, and then price each option against those scenarios rather than against list terms. Treat any cost figure you receive as incomplete until the quote shows migration effort, support hours, and the cost of running a test environment for each upgrade.
How DeployOpen scopes a fixed-price Apache KIE implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Red Hat PAM cost vs self-supported Apache KIE decision, we start with a written scope that shows which jBPM, Drools and Business Central assets move, what the support model looks like, and who owns each step.
How we scope
- Inventory of BPMN, DMN and Drools assets, KIE Server deployments and integrations, agreed in writing before work starts.
- Written cost comparison covering the IBM BAMOE subscription, in-house or partner support for Apache KIE, and migration effort.
- Clear decision on which in-flight process instances must drain, and which ones need a migration path.
How we build
- Proof-of-concept of representative processes on the Kogito-based runtime, run in your cloud account or data center.
- Hardening of the Apache KIE deployment, including container images, secrets handling and access controls agreed in the scope.
- Testing of BPMN and DMN behavior against your current results, with test evidence recorded for each migrated asset.
How we hand over
- Runbooks for installation, upgrades and backups, written for your platform team to operate without DeployOpen.
- Documentation of the upgrade path between Apache KIE releases, so your team can track incubating project changes.
- Compliance-ready evidence for your assessors, prepared by DeployOpen but issued only by your independent auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support scope is set in the written agreement, including which Apache KIE versions and environments it covers.
- Ask any provider to confirm response expectations and version coverage in writing before you sign.
