Eximee Team
Support for Camunda 7 Community Edition ended in October 2025 with the release of version 7.24, and from that point on, the system no longer receives security fixes. For banks and insurers in the European Union, this is a serious issue: the DORA regulation, in force since January 17, 2025, prohibits running critical processes on software that lacks current CVE updates. Migrating to Camunda 8, however, requires rebuilding the architecture around the distributed Zeebe engine and accepting a source-available license. For the financial sector, EximeeBPMS offers an alternative that preserves an embedded-engine architecture and a fully open-source Apache 2.0/MIT license without forcing an architectural migration.
What you should know:
To learn more about the technical details, check the EximeeBPMS documentation for a full description of the engine, API, and Camunda 7 migration paths.
The end of support for Camunda 7 CE affects every industry, but in financial services it carries an additional regulatory weight. Since January 17, 2025, the EU’s DORA (Digital Operational Resilience Act) has been fully in force—a regulation that explicitly covers banks, insurers, investment firms, and other financial entities with strict ICT risk management requirements, including risks tied to technology vendors. DORA mandates, among other things, maintaining a register of ICT vendor contracts, assessing concentration risk with individual providers, and having a documented exit strategy for each critical relationship.
In this context, the process engine underpinning a bank’s or insurer’s critical infrastructure is no longer just an IT team’s technical choice—instead, it becomes part of operational risk assessment that must be documented and justified to auditors or regulators. Running a system based on archived, unsupported code (Camunda 7 CE) is difficult to defend under DORA. Still, choosing the next step—a full migration to Camunda 8 or an evolutionary path—should be a deliberate architectural decision, not an automatic “newer version from the same vendor” choice.
| Feature relevant to the financial sector | EximeeBPMS | Camunda 8 | Why it matters in a regulated environment |
|---|---|---|---|
| Embedded engine in a JVM application | Yes | No | A shared ACID transaction between business logic and process state improves auditability and data consistency in credit, claims, and KYC processes. |
| Standard relational database for operational data | Yes | Partially | RDBMS provides predictability, transactional consistency, and the ability to archive operational data in line with security teams’ established policies. Support for RDBMS in Camunda 8 appeared only in versions 8.8/8.9 as an alternative to ES/OpenSearch and is still maturing. |
| Fully open-source license (OSI-compliant) | Yes (Apache 2.0 / MIT) | No | Camunda License v1 (formerly Zeebe Community License) is described by Camunda itself as “source-available,” not open source—a significant difference when evaluating vendor risk under DORA. |
| Operational tools free in production | Yes | No | Since version 8.6, the entire Self-Managed distribution, including Zeebe, requires a production license key—operational cost must be included in the ongoing budget, not only project cost. |
| Cloud deployment / Kubernetes support | Yes | Yes | Both products can be deployed in a cloud environment with Kubernetes orchestration. The cloud itself is not an area of clear advantage; what ultimately matters is the architecture of the specific deployment. |
| Event-driven model | Yes (Enterprise; OSS since version 1.4.0) | Yes | Zeebe was built from the ground up around an event-driven architecture and can cover a broader range of patterns than the current implementation of EximeeBPMS—it’s worth verifying how well each approach fits the specifics of a given project. |
| Dedicated migration tool for Camunda 7 code | Yes | - | The EximeeBPMS tool based on OpenRewrite automates package and dependency changes from org.camunda → org.eximeebpms, reducing migration time for critical processes. |
| Current technology stack: Java 25 LTS, Spring Boot 4.x | Depends on version | Depends on version | The current tech stack affects support cycles and compliance with a bank’s security policies—both products’ supported versions should be verified before making a decision. |
| Certifications and security mechanisms for regulated sectors | Depends on deployment | Depends on deployment | Camunda Enterprise offers its own compliance certifications. Neither side has a clear advantage here—the deciding factors are the specific deployment architecture and the institution’s audit requirements. |
EximeeBPMS was created as an architectural continuation of Camunda 7 rather than a brand-new product built from scratch—a practical advantage for banks and insurers that have invested for years in process models, integrations, and team expertise around this architecture. Today, it is widely used across most Polish banks, giving us first-hand insight into the sector’s requirements and priorities based not on theory, but on production deployments.
Maintaining the embedded architecture in EximeeBPMS was not a step backward, but a pragmatic response to the needs of regulated markets. In transactional banking, rewriting hundreds of processes for a distributed architecture—imposed alongside a vendor’s strategic and licensing shift—represents an enormous cost with no business justification. This holds true whether the target model would be full microservice orchestration or patterns such as Saga. Our clients expected continuity of operations and uncompromising security, and that is exactly what we delivered.
– Robert Mastalerek, Senior Fullstack Developer on the EximeeBPMS team
The distinction between truly open software (open source) and code with restricted access (source-available) becomes critical during a DORA compliance audit, when the compliance team must register the process engine within the institution’s ICT risk framework. Choosing Apache 2.0 or MIT—the licenses behind the EximeeBPMS Community edition—removes the risk of sudden pricing policy changes by the vendor. Camunda License v1 is a different case: since the vendor itself describes it as source-available rather than open source, the organization must explicitly justify this in its compliance documentation.
What is more, the production license requirement introduced in version 8.6 for Self-Managed deployments creates a real risk of vendor lock-in for a bank. Any future change in the vendor’s pricing terms forces the institution to absorb enormous reverse migration costs—something that auditors evaluating the bank’s operational resilience must formally record as elevated financial and operational risk.
The absence of a shared ACID database transaction is the key architectural difference between EximeeBPMS and Camunda 8, and it directly affects data consistency in banking processes such as lending or AML.
The most time-consuming part of migrating from Camunda 7 rarely involves BPMN itself. The real challenge lies in low-level integration elements—Java listeners and JUEL expressions—mechanisms that reference Spring components directly from code. Camunda 8 has no straightforward equivalents for these, requiring integration rewrites rather than simple dependency swaps. The EximeeBPMS migration tool based on OpenRewrite automates the mechanical part (changing packages from org.camunda → org.eximeebpms). This significantly reduces the time spent on mechanical code refactoring compared to manual migration, leaving teams free to focus on what actually requires attention: business logic and integration.
It is worth noting the strong side of a distributed architecture. Zeebe was designed for very high event throughput and horizontal scaling beyond a single node. In scenarios of extreme transactional load, this is a genuine advantage that an architecture based on a single relational database cannot reproduce in the same way. This narrow scenario—not general slogans like “cloud” or “event-driven model”, which EximeeBPMS supports equally well—should be the real deciding factor when choosing Camunda 8.
One may assume that the long-standing lack of RDBMS support has caused real issues with operation predictability and disaster recovery reproducibility in banking deployments, which may have prompted the vendor to change strategy and introduce RDBMS as an option in versions 8.8/8.9.
This also raises a question about the logic of the change itself: since Zeebe’s performance advantage is fundamentally based on avoiding the bottlenecks of classical relational databases, introducing RDBMS as an alternative in versions 8.8/8.9 invites the question of whether this option partially limits the very performance benefit that was meant to differentiate Zeebe from architectures such as EximeeBPMS. Camunda has not published a detailed explanation of the motivation behind this shift.
Outside this single, narrow scenario (extreme event throughput and scaling beyond a single node), the decision between platforms should be driven by the specific requirements of the project and by how easily the choice can be justified in the ICT risk register required under DORA rather than by broad associations like “cloud” or “event-driven model”.
EximeeBPMS is a universal solution for any financial institution looking for a secure alternative after the end of support for Camunda 7 and wanting to meet DORA requirements without stress. However, the system shows its true advantage in environments where the organization cannot afford even the slightest architectural compromise.
A perfect example of such a setting—and an ideal scenario for EximeeBPMS—is an organization migrating massive, highly critical services to the cloud (e.g., Microsoft Azure). Here, worth a mention is handling bank applications for government programs requiring extremely high-volume and high-availability processing, examples of which are large-scale government benefit schemes that provide monthly financial support to families with children (800+) and annual support for school-related expenses (300+).
Imagine an architecture with extremely strict security requirements, where the new infrastructure must meet uncompromising conditions:
It is precisely under such demanding conditions that attempts to implement Camunda 8 encounter the greatest resistance.
Why? Because building the above model on Camunda 8 requires maintaining a distributed cluster (Zeebe, Gateway, Operate, Tasklist, and the Identity component). For banking security and infrastructure teams, each of these new microservices is a separate element requiring its own Disaster Recovery procedures, its own hardening cycle, and a separate target for costly penetration tests. In contrast, EximeeBPMS is reduced to a single embedded Java application working with a classic relational database (e.g., PostgreSQL).
In case of such sensitive operations, the approach to auditability is also a major advantage. In Camunda 8, the process state is stored in the Zeebe event log, and what appears in analytical tools goes through Elasticsearch, which introduces eventual consistency. In EximeeBPMS, the process state and business data share one relational ACID transaction. For auditors and compliance teams, this means a durable, consistent, and indisputable trace: who, when, and under which request performed a given action in the system.
What is an embedded engine in BPMS systems?
An embedded engine is an architecture in which the process management mechanism (e.g., EximeeBPMS) runs directly within the application’s own memory space (such as the Java Virtual Machine – JVM), sharing its compute resources and database transactions. Unlike external engines, it does not require network calls.
Is Camunda 8 open source?
No, not according to the Open Source Initiative definition. Zeebe and the other Camunda 8 components are licensed under Camunda License v1, which Camunda itself describes as source-available—the code is visible, but the license imposes restrictions that are not OSI-compliant, including limitations on offering Zeebe as a cloud service.
When does support for Camunda 7 Community Edition end?
The final CE release, version 7.24, was published on October 14, 2025. From that moment, the repository is archived, and users no longer receive official security fixes or support.
How is the end of support for Camunda 7 connected to DORA?
DORA, fully in force since January 17, 2025, requires financial institutions to manage ICT risk, including maintaining a register of technology providers and assessing concentration risk. Running critical processes on an unsupported, archived engine is difficult to justify in such a register, increasing pressure to make a migration decision.
How does EximeeBPMS architecture differ from Camunda 8?
EximeeBPMS continues the embedded-engine model running inside a JVM application and uses a standard relational database for operational data with process history ultimately moved to a separate, event-fed database outside the engine. Camunda 8 operates as a remote, distributed component (Zeebe) and for most of its history required Elasticsearch or OpenSearch as a secondary store—RDBMS support appeared only in newer versions and is still maturing.
Powered by Consdata
hello@eximeebpms.org
+48 614 151 000
Consdata S.A.
Krysiewicza 9/14
61-825 Poznań
Poland
Download
Source Code
Documentation