Overview
Drools 7 and its enterprise ecosystem (JBoss EAP 7, Business Central, KIE Server, and KieScanner) are reaching end-of-life or extended support only. Organizations running Drools 7 in production face a critical platform decision affecting security posture, compliance status, and operational continuity. The path forward is not straightforward. This document analyzes the execution model changes, performance characteristics, governance shifts, and deployment model differences introduced in Drools 10 (the community release distributed through Apache KIE). It is intended for enterprise architects, platform owners, and technical leads responsible for modernization decisions.Architectural Constraint
Community Drools 10 is not a drop-in replacement for orchestration-heavy Drools 7 systems. Session isolation, execution model changes, and removal ofstartProcess() alter runtime behavior and performance characteristics.
Drools 10 preserves DRL syntax compatibility but changes the execution and deployment model fundamentally.
Key Findings
- Not a drop-in replacement: Community Drools 10 requires architectural changes for systems using BPMN orchestration, shared working memory, or
startProcess()patterns. - Core components removed: KIE Server, Business Central, KieScanner, and the KJAR runtime deployment model do not exist in community Drools 10.
- Execution model changed: Drools 10 uses session-per-task isolation; facts are no longer shared implicitly across BPMN tasks.
- Performance impact observed: 5× to 30× degradation measured in orchestration-heavy BPMN workflows under internal benchmarking conditions.
- Deployment model shifted: Every rule change requires container image rebuild and redeployment; no runtime hot-deploy capability exists.
- Governance gaps: Business Central retirement eliminates built-in audit trails, approval workflows, and visual DRL authoring; KIE Sandbox supports only BPMN and DMN editing.
- Migration feasibility varies: Simple rule-only projects can migrate; orchestration-heavy systems may require fundamental architectural redesign.
Scope and Methodology
This document synthesizes observed migration patterns, architectural mismatches, and operational challenges encountered across multiple enterprise Drools 7 environments attempting to move to community Drools 10 through Apache KIE. Observations reflect real migration efforts across regulated industries and analysis of upstream Apache KIE project changes. Outcomes vary significantly based on orchestration depth, execution model reliance, and governance requirements.How to Read This Document
Performance characteristics, governance impacts, and migration feasibility described here are observational. They reflect patterns encountered across real systems and may vary based on architecture, workload, and operational constraints.About the Authors
Aletyx Engineering has led multiple enterprise Drools 7 modernization efforts across regulated industries, including financial services, healthcare, and public sector environments. This document reflects patterns observed during those migrations and analysis of upstream Apache KIE changes. The approaches described here informed internal architectural models designed to mitigate orchestration and governance regressions introduced in community Drools 10.Problem Overview
Organizations running Drools 7 in production face three possible outcomes:- Accept unsupported platform risk — Continue running EOL software with no security patches
- Migrate to an alternative execution model — Evaluate commercial alternatives or different automation approaches
- Perform architectural redesign for community Drools 10 — Accept the breaking changes and rebuild
Migration Sensitivity by Execution Model Dependency
Systems with deep reliance on ruleflow orchestration experience the highest migration risk.
End-of-Life Component Status
The following table summarizes the lifecycle status of components in the Drools 7 ecosystem. Status definitions:- End of life: No further releases, patches, or support from the upstream project
- Extended support only: Vendor support available at additional cost; no new features
- Maintenance mode: Limited updates; approaching end of active development
- Retired: Component discontinued; no replacement with equivalent functionality
- Removed in Drools 10: Capability does not exist in community Drools 10
*URL may shift with future Apache KIE releases.
JBoss EAP 7.x has no planned successor releases that support Drools 7. JBoss EAP 8 targets Jakarta EE 10 and Java 17+, which is not certified with Drools 7.x and introduces dependency incompatibilities. Organizations on EAP 7 face a parallel migration challenge.
Security Implications
Java 17+ introduces security manager deprecation and module system enforcement that breaks many Drools 7 patterns:- Security Manager removal: Java 17 deprecates
SecurityManagerfor removal (JEP 411), and later Java releases progressively restrict or disable its functionality. Drools 7 deployments relying on security policies require rearchitecture. - Strong encapsulation: Internal JDK APIs used by reflection-heavy frameworks are no longer accessible by default. Common workarounds (
--add-opens) create maintenance burden. - Dependency chain breakage: Libraries compatible with Java 8/11 often fail on Java 17+ due to illegal reflective access, requiring version upgrades throughout the dependency tree.
Operational Implications
End-of-life creates compounding risks:- Security exposure: Known vulnerabilities in JBoss EAP 7, Java 8/11, Spring Boot 2.x, and related dependencies will not receive patches or require costly extended support contracts
- Compliance risk: Regulated industries require supported software stacks; running EOL software may violate audit requirements
- Operational fragility: Compatible dependencies, documentation, and skilled resources become increasingly difficult to source
- No forward path within 7.x: No Drools 7.x releases will address emerging Java runtime requirements or security issues
- Java runtime modernization: Organizations must migrate from Java 7, 8, or 11 to Java 17 or 21 to run community Drools 10, which cascades into dependency upgrades, module system constraints, and security policy changes
- Spring Boot migration: Spring Boot 2.x end-of-life forces migration to Spring Boot 3.x, which itself requires Java 17+ and introduces breaking changes in configuration and dependencies
Platform Lifecycle Alignment
Drools 7 deployments rarely exist in isolation. The rule engine is typically embedded within a broader platform stack including Java runtimes, application servers, Spring frameworks, CI/CD pipelines, and governance tooling. Drools 7 end-of-life often coincides with other platform end-of-life events:- Java Runtime: Many Drools 7 systems were certified on Java 7, 8, or 11. Community Drools 10 requires Java 17 or later, with Java 21 recommended for long-term support.
- Spring Framework: Drools 7 deployments using Spring Boot 2.x face a parallel migration to Spring Boot 3.x with its own breaking changes.
- Application Server: Enterprise deployments are frequently coupled with JBoss EAP 7.x or WildFly releases targeting older Java versions.
Architectural Impact
Migration outcomes are driven more by execution model changes than by rule syntax compatibility.What Changed in the Drools 10 Execution Model?
The following subsections detail the specific architectural changes introduced in community Drools 10.Execution Model Changes
Community Drools 10 introduces significant architectural changes from Drools 7, particularly in how orchestration and session management function. These changes began with the Drools 8 release3 and continued through subsequent versions:Spring Embedded Model and KieScanner
Many Drools 7 deployments use the Spring embedded model, where the rule engine runs within a Spring application context. This pattern often relies on:- KieScanner: Automatic polling for updated KJARs in Maven repositories, enabling hot-reload of rules without application restart
- Spring integration: KieContainer and KieSession beans managed by Spring dependency injection
- Embedded execution: Rules execute within the same JVM as the application
- KieScanner is not available; there is no mechanism for runtime KJAR updates
- Rule changes require container image rebuild and redeployment
- Spring Boot 3.x migration is required for Java 17+ compatibility
- Kogito’s code generation model replaces the embedded KieContainer pattern
Removal of startProcess()
ThestartProcess() API has been the foundation of orchestration models since Drools 5. As discussed on the Apache KIE developer mailing list (early 2025)9, maintainers indicated that the legacy process runtime supporting this pattern is being phased out in favor of the code-generated execution model.
Impact:
startProcess()is deprecated and is not supported under the Drools 10/Kogito execution model- The method signature may remain on shared interfaces due to jBPM dependencies, allowing code to compile but fail at runtime
- As indicated by project maintainers10, the legacy runtime that supported this pattern is no longer being maintained
- Insert multiple fact objects into working memory
- Invoke a BPMN-driven ruleflow via
startProcess() - Rely on shared session state across multiple tasks
Session Isolation
In Drools 7, a single KIE Session managed facts across an entire orchestration. In community Drools 10, each task in the BPMN process creates a new KIE Session. Session-per-task execution changes performance characteristics more than rule complexity.
Practical impact:
- Every fact previously implicitly available must now be explicitly declared as process variables
- Input/output mappings must be defined at each BPMN task node
- Parallel gateways become serial constructs requiring explicit synchronization
- Manual analysis of every task and data dependency is required
REST API Elimination
KIE Server provided a standardized REST API supporting command-based rule execution. All deployed KJARs were accessible through a single, consistent interface. Impact:- KIE Server is no longer present in community Drools 10
- No centralized prebuilt REST execution server equivalent exists
- Each execution path requires custom endpoint implementation
- Client systems integrated with KIE Server require interface rewrites
Business Central Retirement
Business Central provided:- Visual rule authoring environment for business users
- DRL, guided rules, guided decision tables, and spreadsheet decision table editing
- Deployment pipeline orchestration
- Version management and rollback capabilities
- Test scenario execution
- Audit trails and governance workflows
- Repository management and access control
- KIE Sandbox: Provides visual editing for BPMN and DMN assets only; does not support DRL, guided rules, guided decision tables, or other rule asset types
- GitOps workflows: Rules must be managed as source code in version control systems
- CI/CD pipelines: Deployment becomes pipeline responsibility with container image builds per version
- No direct governance replacement: Audit trails, approval workflows, and role-based access require custom implementation or third-party solutions
Excel Decision Table Changes
Excel decision tables require specific file naming conventions in community Drools 10:- Files must be renamed from
.xls,.xlsx, or.csvto.drl.xls,.drl.xlsx, or.drl.csv - In the current Kogito-based build tooling, the build does not fail if files are misnamed
- Rules are silently excluded from compilation with no warnings or errors
Performance Implications
Why Does Drools 10 Performance Differ?
Performance degradation is not uniform. Some systems experience modest impact; others experience severe nonlinear scaling degradation. The session-per-task model is the dominant variable, but orchestration structure often determines whether degradation is tolerable or catastrophic.Benchmarking Methodology
Performance observations in this document are based on internal benchmarking conducted by Aletyx Engineering across multiple client environments. Testing focused on orchestration-heavy BPMN workflows with 10+ tasks per process instance, comparing Drools 7 and community Drools 10 under equivalent infrastructure conditions (same hardware, JVM settings, and data volumes). These findings may not apply to simple rule services without BPMN orchestration or to workloads with fundamentally different execution patterns.Session-per-Task Model
The session-per-task execution model produces the most significant performance impact. Where Drools 7 maintained a single session across an orchestration, community Drools 10 creates a new session for each task in the BPMN process. Observed impacts:- Performance degradation of 5× to 30× measured across multiple enterprise environments with orchestration-heavy workflows
- Sub-200ms executions can degrade to multi-second runtimes
- Memory overhead increases due to fact recreation across task boundaries
- CPU utilization increases due to repeated session initialization and garbage collection
- Simple orchestration: moderate degradation
- Moderate orchestration: severe degradation
- Heavy orchestration: often fails to meet existing SLA thresholds
Resource Overhead
Performance Acceptability Criteria
Performance degradation may be acceptable when:- Execution times are well under SLA requirements
- Transaction volumes are low and horizontal scaling is feasible
- Orchestration is simple (limited tasks, no gateways)
- Existing execution times are close to SLA thresholds
- High transaction volumes make horizontal scaling cost-prohibitive
- Complex orchestration multiplies the degradation factor
Governance Impact
In most migrations, governance and operational gaps surface before functional incompatibilities. Community Drools 10 shifts to a primarily GitOps-based and container release strategy versus the traditional KJAR methods found in Drools 7 which could be released through multiple mechanisms.Capability Comparison
Operational Model Shift
Drools 7 operational model:- Business Central as deployment controller
- Hot deployment of KJARs via REST API
- KieScanner for automatic KJAR updates
- Centralized monitoring and management
- Single point of configuration for exception handling
- Immutable container images built per version
- CI/CD pipeline-driven deployments
- Container rebuild required for any rule change
- Distributed monitoring across services
- Exception handling implemented per service
- GitOps workflows for version control and deployment
Deployment Model Change
The shift from KJAR deployment to container images represents a fundamental operational change:- Drools 7: Deploy KJAR artifacts to running KIE Server; use KieScanner for automatic updates
- Community Drools 10: Build new container image for every rule change; deploy through container orchestration
- Code generation and compilation
- Container image build
- Image registry push
- Container deployment/restart
Exception Handling
The pluggableConsequenceExceptionHandler, which allowed centralized exception handling at the KIE Server level, is not available in community Drools 10 as KIE Server itself has been retired.
Implications:
- Exception handling becomes fragmented across services
- Each microservice must implement its own exception capture logic
- Inconsistency risk increases across different team implementations
- Observability and compliance exposure increase without centralized handling
Migration Patterns by Execution Dependency
In practice, projects cluster into patterns based on their execution model dependency.Migration Effort by System Type
Rule-Only Systems
Characteristics:- Limited BPMN complexity (small number of tasks)
- No parallel or complex gateways
- Minimal reliance on shared working memory
- Clean Java 17 compatibility
- Relatively simple dependency footprints
- No reliance on KieScanner for dynamic updates
- Replace BPMN orchestration with programmatic Java flows
- Implement custom REST endpoints
- Rename Excel decision tables
- Establish unit testing before migration
- Implement container build pipelines
Orchestrated Systems
Characteristics:- Heavier use of workflow orchestration (moderate task counts)
- Gateway constructs requiring conditional logic reimplementation
- Multiple processes within a single project
- Reliance on KieScanner or hot-deploy patterns
- Loss of visual workflow representation
- Uncertain performance under load
- Increased testing burden
- Potential for subtle behavioral differences
- Container rebuild overhead for rule changes
Session-Dependent Systems
Characteristics:- Heavy reliance on
startProcess()orchestration with large numbers of tasks - Deep dependencies on shared working memory across task boundaries
- Facts created dynamically during execution that must persist across tasks
- Performance requirements incompatible with session-per-task model
- Critical dependency on KieScanner for runtime updates
- Remain on unsupported Drools 7 (security and compliance risk)
- Rebuild using alternative technology (high cost, loss of existing investment)
- Evaluate commercial alternatives that preserve architectural patterns
Testing Considerations
Passing unit tests does not imply orchestration equivalence.Common failure modes include:
- Silent rule exclusion due to file naming
- Behavioral drift caused by session isolation
- Performance collapse under load
- Correct results produced through incorrect intermediate states
Silent Failure Detection
The most challenging testing requirement is detecting silent failures:- Rules excluded due to file naming (no compilation error)
- Behavioral differences due to session isolation
- Missing fact propagation between tasks
- Performance degradation that only appears under load
- Establish comprehensive test coverage before migration
- Implement automated verification that all expected rules fire
- Create integration tests that validate end-to-end behavior
- Perform load testing with production-representative data volumes
Regression Testing Limitations
Traditional regression testing may be insufficient because:- Functionality may pass unit tests but fail under orchestration
- Performance characteristics are fundamentally different
- Session isolation may produce correct results with incorrect intermediate states
- Excel decision table changes may introduce subtle data type coercion issues
Test Environment Requirements
Test environments must account for:- Java 17 or 21 runtime requirements
- Container-based deployment model
- Custom REST endpoint testing
- Performance baseline comparison with Drools 7
- Container build and deployment pipeline validation
Cost Factors
Cost multiplier ranges reflect internal estimates based on multiple enterprise migration engagements. Actual values vary based on organizational size, regulatory environment, and existing infrastructure maturity.Common Underestimations
Organizational Impacts
Skills transition:- Teams must adapt to Quarkus or Spring Boot 3.x development patterns, even if already familiar with earlier versions
- DevOps skills for container orchestration become essential
- Business users lose direct access to rule authoring for non-BPMN/DMN assets
- Container build and deployment expertise required across teams
- Platform teams absorb workflow orchestration responsibilities
- Engineering owns deployment pipelines previously managed by Business Central
- Governance becomes distributed rather than centralized
- Every rule change triggers container rebuild and redeployment
Migration Path Options
The following paths reflect strategies organizations have attempted. None represent a universally correct approach. Outcomes have varied significantly depending on system architecture, governance requirements, and performance sensitivity.Option 1: Community Drools 10 Migration
Approach:- Accept the architectural constraints of the community release
- Implement workarounds for removed capabilities
- Build custom governance and operational tooling
- Establish container build pipelines for deployment
- Projects are primarily rules-based with minimal orchestration
- Performance degradation is within acceptable bounds
- Organization has capacity to build and maintain custom tooling
- Container rebuild per rule change is acceptable
- Bug resolution timelines depend on community prioritization and contributor availability
- Performance constraints may block some projects
- Governance gaps require significant custom development
- KIE Sandbox limitations affect rule authoring workflows
Option 2: Phased Migration with Project Triage
Approach:- Classify portfolio by migration feasibility
- Migrate feasible projects first to establish patterns
- Evaluate alternatives for blocked projects
We have only seen this succeed when:
- Portfolio has mixed complexity levels
- Organization needs to demonstrate progress while managing risk
- Time allows for iterative learning
Option 3: Platform Re-evaluation
Approach:- Evaluate whether Drools remains the appropriate technology choice
- Consider commercial alternatives or different automation approaches
- Factor in total cost of ownership over 5-10 year horizon
- Significant portion of portfolio is blocked from migration
- Strategic direction favors commercial support and SLAs
- Governance requirements exceed community release capabilities
Runtime Selection: Quarkus vs. Spring Boot
Throughput characteristics are workload-dependent and may vary based on rule complexity, JVM configuration, and infrastructure.
The orchestration model—not the runtime—is the primary determinant of migration feasibility.
Frequently Asked Questions
Is Drools 10 a drop-in replacement for Drools 7?
No. Community Drools 10 introduces breaking changes to orchestration, session management, and deployment models. Systems usingstartProcess(), shared working memory across BPMN tasks, or KIE Server REST APIs require architectural redesign. Simple rule-only services without orchestration have higher compatibility.
What happened to KIE Server in Drools 10?
KIE Server has been retired and does not exist in community Drools 10. There is no centralized runtime server for deploying and executing KJARs via REST. Each rule service must implement its own REST endpoints, and deployment occurs through container images rather than runtime artifact deployment.What replaces Business Central in Drools 10?
There is no direct replacement. KIE Sandbox provides visual editing for BPMN and DMN assets only. DRL files, guided rules, and decision tables must be managed as source code through GitOps workflows. Audit trails, approval workflows, and role-based access control require custom implementation.Why is Drools 10 performance different?
Community Drools 10 uses session-per-task isolation in BPMN orchestration. Each task creates a new KIE Session with its own working memory, requiring facts to be explicitly marshalled between tasks. As measured in internal benchmarking, this architectural change produces 5× to 30× performance degradation in orchestration-heavy workflows compared to Drools 7’s shared session model.How do I migrate from Drools 7 to Drools 10?
First, classify your projects by migration feasibility based on orchestration complexity andstartProcess() usage. Establish comprehensive test coverage before migration. For feasible projects, replace BPMN orchestration with programmatic flows, implement custom REST endpoints, and establish container build pipelines. Blocked projects require architectural redesign or evaluation of alternative platforms.
Summary
Platform Status
- Migration is required for organizations needing security updates and supported dependencies
- The ecosystem is retiring: Business Central, KIE Server, KieScanner, and KJAR deployment model are removed
- Remaining on Drools 7 carries escalating security, compliance, and operational risk
- Java 7, 8, 11 and Spring Boot 2.x end-of-life compounds migration requirements
Architectural Changes
startProcess()removal breaks a common enterprise orchestration pattern- Session isolation eliminates shared working memory between tasks
- Performance degradation of 5×–30× observed in orchestration-heavy enterprise environments under internal benchmarking conditions
- No centralized prebuilt REST execution server equivalent exists
- Requiring a container rebuild for every rule change is an operational shift, not a tooling detail
- KIE Sandbox supports only BPMN and DMN editing
Migration Constraints
- Not all Drools 7 systems can migrate to community Drools 10 without architectural redesign, particularly those with orchestration-heavy usage
- Governance gaps emerge before functional gaps in most migration efforts
- Cost multipliers from governance reconstruction, client integration, and regulatory re-approval are consistently underestimated
- Container-based deployment model changes operational workflows
Patterns Observed in Successful Evaluations
- Classify portfolio by migration feasibility before committing to timelines
- Establish test coverage before attempting migration
- Validate performance under production-representative load conditions
- Plan for governance reconstruction as a parallel workstream
- Consider total cost of migration versus alternative platform strategies
Glossary
Business Central: Web-based development and governance environment for Drools 7, providing rule authoring, deployment management, and audit capabilities. Retired in community Drools 10. Community Drools 10: Open-source release of Drools 10.x from the Apache KIE project, distinct from commercial distributions. DRL (Drools Rule Language): Native syntax for defining rules in Drools. DRL syntax compatibility is preserved in community Drools 10, though execution context differs. KIE Sandbox: Web-based design tool in community Drools 10 for creating and editing BPMN and DMN assets. Does not support DRL, guided rules, or decision table editing. KIE Server: Runtime execution server for Drools 7 providing REST APIs for rule execution and KJAR deployment. Retired in community Drools 10. KIE Session: Runtime context in which rules execute. In Drools 7, a single session could span an entire orchestration. In community Drools 10, each task creates a new session. KieScanner: Component in Drools 7 that automatically polls Maven repositories for updated KJARs, enabling hot-reload of rules. Not available in community Drools 10. KJAR (Knowledge JAR): Packaging format for Drools artifacts deployable to KIE Server at runtime. Removed in community Drools 10. Ruleflow Group: Mechanism for organizing rules into execution groups activated in sequence or through BPMN orchestration. startProcess(): API method for initiating BPMN-driven rule orchestration in Drools 7. Deprecated and not supported under the Drools 10/Kogito execution model. Working Memory: Runtime fact store where objects are inserted for rule evaluation. In Drools 7, shared across tasks. In community Drools 10, each task session has isolated working memory with facts created and destroyed per task.Sources and References
- Apache KIE GitHub – Drools release history: https://github.com/apache/incubator-kie-drools/releases ↩
- Apache KIE Project Blog – KIE Tools releases and roadmap: https://blog.kie.org/2024/08/the-new-kie-tools-releases.html ↩
- Drools 8 Final: Toward a Modular and Cloud-Native Rule Engine (October 2022): https://blog.kie.org/2022/10/drools-8-final-toward-a-modular-and-cloud-native-rule-engine.html ↩
- Drools 10.1.x Decision Tables Reference – File naming conventions: https://kie.apache.org/docs/10.1.x/drools/drools/language-reference/index.html#decision-tables-con_decision-tables ↩
- Apache KIE Migration Documentation – Kogito migration guide: https://docs.kie.apache.org/kogito/latest/migration-guide/index.html (URL may shift with future Apache KIE releases) ↩
- Oracle Java SE Support Roadmap: https://www.oracle.com/java/technologies/java-se-support-roadmap.html ↩
- Spring Boot Support Policy: https://spring.io/projects/spring-boot#support ↩
- Red Hat JBoss EAP Lifecycle Policy: https://access.redhat.com/support/policy/updates/jboss_notes/ ↩
- Apache KIE Developer Mailing List – Discussion on startProcess() deprecation and removal (early 2025): https://lists.apache.org/thread/t3o842mbj03c57cg5yw3tmo25qf2br1t ↩
- Apache KIE Developer Mailing List – Legacy runtime removal discussion: https://lists.apache.org/thread/cftmsopn0tgz9prt3ronfkrz9l4llq1o ↩