Migrate from Red Hat PAM to Apache KIE

This pattern routes new process starts to Apache KIE while instances already running on PAM finish on the old platform. It fits processes with short lifespans, processes whose state you can safely restart, and new business flows with no existing instances. Both platforms stay live until the last PAM instance completes, so the old environment remains the fallback.

• Routing point: Decide where starts are switched, such as an API gateway, a calling service's configuration, or a feature flag, and confirm each caller can target either platform.
• Instance ownership: Record which platform owns each instance so support staff know where to look for a given case.
• Parity testing: Replay representative start payloads against both engines and compare outcomes, including DMN decision results and human task assignments.
• Rollback: Revert the routing point so new starts return to PAM. Instances already on Apache KIE continue there, so rollback covers only new work.
• Retirement: Keep PAM read-only for audit and history queries until your retention rules allow removal.

Before switching, confirm with your environment owners how long your slowest process runs and whether the Apache KIE runtime you deploy matches your tested version.

This pattern stops new starts on PAM, lets in-flight instances complete there, and migrates only what cannot finish in time. It fits long-running processes, such as those with timers or waits for external events, where a restart would repeat work or send duplicate messages. Drain time depends on your longest process path, which you must measure yourself rather than assume.

• Drain window: Measure the longest realistic instance duration from PAM history, including timer and wait states, and agree the window with process owners.
• Instances that cannot drain: Identify instances that will outlive the window and decide, per process, whether to migrate their state or to close and restart them under written business approval.
• Message and timer checks: Confirm that correlation keys, signals and timers are handled exactly once during the switch.
• Rollback: Until the drain completes, PAM remains authoritative for in-flight work, so you can reopen new starts there. Once instances move, rolling back requires reversing those moves.
• Evidence: Export completed-instance history and keep it with your change records for the audit trail.

Before switching, confirm with your process owners which instances are business-critical and whether your state migration method has been tested on a copy of production data.

This pattern sends the same decision inputs to both the PAM rule service and the Apache KIE DMN service, uses the PAM result for production, and records the Apache KIE result for comparison. It fits rule-heavy decisioning such as eligibility, pricing or risk scoring, where a silent change in output carries material risk. Shadow results never change customer outcomes until you decide to switch.

• Comparison scope: Define which fields must match exactly and which differences are expected, such as timestamps or versioned rule identifiers.
• Input capture: Store anonymized or tokenized inputs according to your data protection rules, and confirm the shadow store sits inside your own boundary.
• Mismatch review: Set a process for reviewing every difference, with named owners who can classify it as a defect or an accepted change.
• Switch criteria: Agree written criteria for promoting Apache KIE to primary, and keep PAM serving until they are met.
• Rollback: Flip the primary flag back to PAM. Because PAM stays deployed during shadowing, this rollback is immediate.

Before switching, confirm the Apache KIE rule and DMN assets were converted and tested against your own decision samples, not only the vendor examples.

A small estate has a handful of BPMN processes, few or no custom work item handlers, and limited rule usage. The migration scope is mostly about re-validating models and rebuilding the deployment pipeline on Apache KIE's current runtime, not about rewriting logic. Because the asset count is low, a single engineer or a small team can usually inventory every process and decide on each one individually. The main risk is assuming a small estate is a simple one: a single process that calls an unlisted handler or depends on a Business Central form can still block a cutover.

• Inventory: list every BPMN, DMN and rule asset, and every work item handler, with its owner and last execution date.
• Editor change: the BPMN editor in Apache KIE 10.2.0 replaces the legacy GWT-based tooling, so confirm that models edited in Business Central still open and save cleanly.
• Runtime choice: decide between Quarkus and Spring Boot early, since it affects packaging and the deployment pipeline.
• Retire the old stack: plan a single cutover date with the old KIE Server still available for rollback.
• Test coverage: run each process path with representative input data and compare outputs with production records.

Before cutover, ask your team to confirm that every asset in the inventory has a passing test and a named owner.

A rule-heavy estate depends on Drools rules and DMN decision models that many processes call. Here the risk sits less in the process flow and more in rule behavior, because a rule that fires in a different order or a DMN table that evaluates differently can change decisions without any visible error. Apache KIE 10.2.0 adds DMN 1.6 support, which may affect how existing models are read, so the migration should include a regression suite that compares decision outputs across the old and new engines. Rules and decisions also tend to be owned by a different group than processes, which adds coordination work.

• Decision regression: build input sets that cover edge cases, then compare outputs from the old and new engines for each decision table.
• DMN version check: confirm how existing DMN models behave under DMN 1.6 support before changing their definitions.
• Rule ordering: review salience, agenda groups and rule flow groups, because they must produce identical outcomes after the move.
• Ownership: agree in writing which team signs off on decision changes, since rule owners are often outside the process team.
• Separate deployment: consider versioning rule packages independently from process packages so each can roll back on its own.

Before cutover, ask for evidence that the decision outputs match on the full regression set, not only on the sample cases.

A large estate has many processes, long-running instances that may wait days or months on human tasks or timers, and Business Central used daily by business analysts and administrators. The migration scope expands to cover in-flight instance state, persistence, user roles and the way Business Central content is exported and reviewed. The central risk is instances that started on the old runtime and must complete there or be migrated safely, which is an operational decision as much as a technical one. Business Central usage also means workflows, permissions and team habits must be documented and rebuilt, not assumed to carry over.

• In-flight instances: classify running instances by version and state, and decide which will drain on the old runtime and which will be migrated.
• Persistence: confirm the database schema and backup plan for both runtimes during the overlap period.
• Business Central dependence: list every role, space and user workflow that depends on the old interface, and assess each for the new BPMN editor.
• Capacity testing: load test the new runtime with realistic concurrency before moving production traffic.
• Operational runbook: document restart, scaling and incident steps for the Quarkus or Spring Boot deployment.

Before cutover, ask your team to confirm the count of in-flight instances per process and the agreed handling for each group.