Camunda, the staple in the workflow automation and BPM landscape, has evolved significantly since its inception in 2013, and the transition to Camunda Platform 8 marks a pivotal moment in this evolution, culminating the lessons learned, and development insights gained over the years.
The major 2022 update is a significant departure from the Camunda Platform as we’ve known it so far: with modernized architecture, introduced improvements and enhanced features. Most importantly, Camunda Platform 8 does not serve as a direct replacement for version 7, so businesses looking to migrate need to carefully plan their strategies.
In this article, we talk about the main differences between Camunda 7 vs Camunda 8 to help you navigate through this crucial change. We discuss the key considerations to make before you decide to migrate, as well as the reasons why it may be prudent to postpone the migration process to a later date.
Camunda platform evolution at a glance
Launched in 2013 from a divergence with Activiti 5, Camunda Platform 7 has since seen 20 minor updates and over 100 patches. The recent progression from version 7 to 8 is in fact an evolution of what has so far been known as Camunda Cloud 1.4. This update introduces significant enhancements and capitalizes on the insights gained through extensive development.
What the above diagram shows is that Camunda Platform 8 isn't a straightforward substitute for version 7. The release underscores a commitment to not leaving Camunda Platform 7 behind. For the forthcoming three years, Camunda will continue development and support for version 7, however, it will eventually be discontinued. Users now have the option to either continue with the existing version or upgrade to Camunda Platform 8.
Let’s take a look at the key differences between Camunda 7 vs Camunda 8 that should help you decide whether it’s time to migrate now or later.
Camunda 7 vs Camunda 8 - key differences
The transition from Camunda 7 to Camunda 8 introduces several key differences, reflecting the evolution of technology trends, scalability demands, and user experience improvements. The key distinctions include:
Architecture
Camunda 7 is traditionally more monolithic, designed for deployment within a single application server environment. It relies heavily on a relational database for storing process definitions, instances, and history data.
In Camunda 7, users have the flexibility to choose from various deployment strategies, including shared engine, embedded engine, and remote engine configurations. This is greatly simplified in Camunda 8, which offers a singular deployment approach that closely mirrors the remote engine configuration.
The remote engine setup places a greater distance between the engine and task execution, focusing on the sequencing rather than the execution details. This approach is similar to the External Task Worker pattern present in Camunda 7, which is designed for asynchronous task processing (more on this later).
Additionally, Camunda 8 introduces a more modern, microservices-oriented architecture. It is built on top of Zeebe, a highly scalable workflow engine designed for cloud-native applications. This shift emphasizes distributed systems and allows for horizontal scalability and resilience.
Engine
While both Camunda 7 and Camunda 8 serve the purpose of automating business processes following the BPMN 2.0 standard, they are powered by distinct process engines. Camunda 7 is built upon the foundation of the Activiti engine (a legacy that traces back to when Camunda was branched off from the Activiti project).
In turn, Camunda 8 operates on the Zeebe engine – a newer, more modern process engine that has been under development since 2017. Zeebe is capable of scaling both horizontally and linearly, which makes it a great suit for cloud environments and for managing workflows that generate a large volume of process instances.
Greater scalability is certainly the key advantage of Camunda 8 over Camunda 7.
The primary benefit of Zeebe over the Camunda 7 engine is its architecture, which does not depend on a relational database, eliminating the primary scalability constraint faced by its predecessor.
Communication
In Camunda, your custom code needs to chat with the process engine to get things done. In version 7, this conversation happened either through a REST API or directly with Java code (for embedded engines).
Camunda 8 brings a new approach. Here, communication goes through a Zeebe gateway, which uses a different protocol called gRPC. This might be unfamiliar to some developers used to REST. But fear not, Camunda provides client libraries for different languages to make things easier (client libraries in Java and Go, community-supported clients in C#, Delphi, Node.js, Python, Ruby, and Rust).
Another change is that Camunda 8 spreads its APIs around more. Unlike version 7 where things were more centralized, you'll find separate APIs for specific tasks. For managing task lists, there's a GraphQL API and a separate REST API.
Camunda Platform 8 - what’s new?
Architecture
New, microservice-based architecture now supports the following:
- Clustering: With Zeebe, Camunda 8 offers a completely different approach. Zeebe uses built-in clustering with at least three brokers (like engines) for redundancy. A gateway handles requests and routes them to the right broker, also balancing the load. Data is stored in event streams on each broker's disk (within Kubernetes) and replicated across all brokers, eliminating the need for a central database like in Camunda 7. In Camunda 7, clustering involved running multiple engines pointing to a single database. This database acted as a bottleneck and a single point of failure.
- Scaling: Camunda 8 ditches the database for a more scalable approach. It uses Zeebe with "horizontal scalability." This means that adding more brokers (processing units) directly improves performance to handle heavier workloads. It's a simpler and more efficient way to scale your workflows. In contrast, Camunda 7's scaling is limited by its central database. All engines rely on this single point, which can bottleneck performance as the workload increases.
- Geographic redundancy: As Camunda became more reliable, users needed a way to handle data center outages. "Geographic redundancy" is the solution, where your application runs in separate locations. Camunda 7 does offer it, but syncing data with remote databases was slow and caused issues. Camunda 8 fixes this. Zeebe replicates data to remote brokers in different data centers without hurting performance. There's a slight delay, but it's constant and manageable. This means your workflows keep running smoothly even if a data center goes down. (The example mentions successful replication between Europe and the US).
- Parallel execution: Camunda 7 relies on locking mechanisms to maintain data consistency. This can be a bottleneck when running many tasks in parallel (think branching workflows or multiple tasks happening at once). You'll either see errors or have to slow things down by processing tasks sequentially, hurting performance. Camunda 8 takes a different approach. It uses append-only logs, buffers, and a special design to avoid conflicts when accessing data (like the database in Camunda 7). This eliminates the need for locking and allows parallel tasks to run smoothly, significantly speeding up workflows with many parallel activities.
Installation
Setting up Camunda 7 involved manually configuring and installing each component, even for separate tools like Camunda Optimize. While straightforward, it required some effort. In turn, Camunda 8 streamlines this process. It leverages Kubernetes for installation and provides Helm charts to automatically configure and connect all components, including Camunda Optimize. Even better, the Camunda 8 SaaS offering removes the need for any Kubernetes or Helm knowledge – you get everything with a single click.
Web Modeler
Previously, integrating Modeler with the engine in Camunda 7 was technically challenging and user-unfriendly. Camunda 8's cloud-based Web Modeler is a lot more user-friendly than its predecessor, which had to be used jointly with Cawemo for design. The new modeler greatly supports collaboration, since it doesn’t require Cawemo, but instead, offers separate tabs for the different roles. It also offers play and design modes, as well as an AI generator for user task forms. This means that building and deploying models no longer requires complex local setups. Existing deployment methods from Desktop Modeler are still supported; there is also a dedicated API, so, unlike in Camunda 7, it’s possible to integrate it with version control systems and CI/CD pipelines.
Connectors
Camunda 8 introduces pre-built connectors to simplify communication with external systems in workflows. These reusable connectors will save developers time and effort. While Camunda provides some connectors, users can also build their own for internal systems. Importantly, this doesn't restrict developer flexibility – Camunda 8 isn't aiming to be a low-code platform. There’s an extensive connector marketplace that also includes partner-built connectors.
Feature improvements
Let’s take BPMN messaging as an example. Camunda 7 strictly followed the BPMN message standard, causing issues in real-world scenarios. Messages would fail if no process was ready to receive them. Camunda 8 introduces message buffering, making message handling more flexible. Messages can now wait in a queue for a process to be ready, improving workflow reliability in distributed systems.
Camunda Platform 8 - what’s missing?
As Camunda 8 undergoes ongoing development, it currently lacks several features and capabilities that are present in Camunda 7, including:
Plugins
Camunda 8 removes process engine plugins, which could potentially destabilize the engine. Alternative approaches, like exporters and interceptors, might be suitable for some use cases. However, it's important to note that exporters are limited to self-managed Zeebe deployments and are not available in the SaaS version.
On the migration front, Desktop Modeler plugins can generally be brought over to Camunda 8, as it uses the same infrastructure. Unfortunately, plugins for Cockpit or Tasklist cannot be migrated.
Execution listeners + task listeners
Camunda 7 allows for the implementation of technical details within processes through execution listeners and task listeners, reducing the need to model these operations as service tasks and keeping the process model streamlined. These features are currently missing in Camunda 8.
BPMN 2.0 standard implementation
The extent of BPMN 2.0 features supported by Camunda 8 is significantly less than that in Camunda 7. Notably, conditional, cancel and compensation events are not currently usable in Camunda 8. Additionally, transaction behavior is more restricted, and it’s impossible to define the process call activity version to be launched – you can only resort to the latest version.
Operational tools
The range of functionalities provided by Operate in Camunda 8, the equivalent of Cockpit in Camunda 7, is more limited. Notably, it’s currently impossible to suspend the execution of specific process steps, although the version is continuously being developed to include new features like retriggering task executions and manipulating stuck instances.
Process instance migration is also significantly limited in Camunda 8.
Custom FEEL Functions for DMN
Camunda 7 supports the creation of custom FEEL functions to simplify complex expressions in DMN tables, enhancing business-IT alignment. This feature is not available in Camunda 8, and its architecture makes it difficult to implement.
Synchronous execution and response times
Camunda 8 is not as optimized as Camunda 7 for scenarios where application users require immediate execution and results from BPMN processes or DMN decisions. The asynchronous nature of Camunda 8 leads to longer execution times and necessitates additional code development for synchronous response scenarios. Additionally, the SaaS variant of Operate in Camunda 8 displays the current status of processes slower than Cockpit in Camunda 7.
These missing features and limitations suggest that while Camunda 8 offers modern cloud technologies and scalability benefits, it may not yet meet all the specific functional requirements and use cases supported by Camunda 7, particularly in areas of technical process implementation, comprehensive BPMN support, and operational tooling.
Camunda 7 vs Camunda 8 - key considerations before migration
Camunda announced that the last release of Camunda 7 Community Edition is scheduled for October 14, 2025 (the repository will be deprecated on that date). Camunda 7 Enterprise Edition will have ongoing support, but only in terms of security and bug fixes.
This means you have some time to remain with version 7 or, you can start migration to the newer version 8, depending on their specific needs and preferences. Here’s what requires careful consideration in case you do decide migration is the right step for your business right now.
A lot of functionalities are currently missing
Since Camunda 8 is still in development, certain features may still be missing from this version. If there are specific functionalities or actions you need to perform on the platform, we advise identifying them and verifying on Camunda Community Forum pages whether they can already be carried out or not.
Lack of embedded engine in Camunda 8
In Camunda 7, the workflow engine operates in a tightly coupled manner with your application. It achieves this by being embedded as a library within the same Java Virtual Machine (JVM). This co-location allows for shared resources, including thread pools and even the data source and transaction manager.
Camunda 8 takes a different approach. Its workflow engine, Zeebe, functions as a separate, remote resource for your application. The key implication is the inability to directly share ACID transactions between your application code and the workflow engine, which means you’ll have to handle data consistency differently when planning the migration.
Lack of certain data types
While Camunda 7 lets you store various data formats, like serialized Java objects, Camunda 8 is stricter. It only accepts basic data types or JSON for process variables. This may mean extra work in your code when handling these variables.
Camunda 7 offered a tool called Camunda Spin to simplify working with XML and JSON. This isn't available in Camunda 8. The recommended approach is to create your own data transformation logic for full control (like using Jackson).
If you're migrating from Camunda 7 and rely heavily on Camunda Spin, you can still include the library in your application code. This will allow you to use the Spin API for data transformations, just like before.
Expression language differences
Camunda 7 gives expressions more freedom with its JUEL engine. They can even access Java objects within your application. This flexibility might require caution during migration.
Camunda 8 uses FEEL, a more restricted expression language. FEEL expressions can only work with data and variables directly tied to the process instance.
While many expressions can likely be converted (check out this community resource for help!), some might need a complete rewrite. In other cases, you might need to add a service task to prepare data that JUEL expressions could calculate on the fly in Camunda 7.
Connector infrastructure differences
Camunda 7 offers two ways to connect to external systems: an HTTP Connector and a SOAP HTTP Connector, both available through Camunda Connect. In contrast, Camunda 8 comes with a wider variety of Connectors built-in.
Migrating existing Connectors from Camunda 7 to Camunda 8 involves two main options:
- If your Camunda 7 Connector uses the REST protocol, you might be able to leverage the REST out-of-the-box Connector provided by Camunda 8. This could simplify the migration process.
- For Connectors that don't have a direct equivalent in Camunda 8, you can create a custom job worker in your code. This worker would act as a bridge, translating communication between your existing Connector and the Camunda 8 engine.
Limited scripting possibilities
Camunda 7 allows the implementation of scripting tasks in Groovy, JavaScript and several other programming languages, which allows developers to write custom logic and perform complex operations directly within the workflow.
With Camunda 8, only FEEL script is allowed in script task activities. It aims to provide a more standardized, simplified, and optimized approach to workflow automation. However, this limitation may require developers to adapt their existing scripts and may not be suitable for all use cases. In situations where more complex or custom logic is required, developers may need to explore alternative approaches, such as implementing external services or using other extension points provided by Camunda.
Multi-tenancy
While multi-tenancy is still in development for Camunda 8, there are already certain differences when it comes to how it works in comparison to Camunda 7:
- Camunda 8 relies solely on tenant identifiers for multi-tenancy. The “one engine per tenant” approach from Camunda 7 is gone.
- Similarly, shared resources like processes and forms are a thing of the past in Camunda 8. This feature is planned for the future, but for now, each tenant operates in its own silo.
- When multi-tenancy is off, Camunda 7 maps data to a "null" tenant ID, making everything shared. In Camunda 8, data gets a "<default>" tenant ID by default.
- Need to bypass tenant checks for admin tasks in Camunda 7? No problem (but be careful!). Camunda 8 doesn't allow this, but you can grant an admin user access to all tenants for a similar effect.
- Camunda 7 tries its best to guess the right tenant when a user triggers a command on a multi-tenant resource. Users with access to multiple tenants can also operate without specifying the tenant ID in many cases. This isn’t the case in Camunda 8, as Zeebe demands explicit tenant IDs for all operations.
Different application building process
Camunda 7 leverages a traditional, embedded engine architecture. This method utilizes familiar tools like Java and Spring Boot. A pre-built component from Camunda seamlessly integrates the workflow engine directly within the application. This offers convenience, similar to having all the necessary plumbing pre-installed. Developers can then create custom code (glue code) as Java delegates to interact effortlessly with the engine.
Camunda 8, on the other hand, introduces a modern, service-oriented architecture. Here, the workflow engine functions as a separate service, akin to a specialized subcontractor. Developers (still utilizing Java and Spring Boot) employ a distinct component, the Spring Zeebe Starter. It acts as a client, facilitating communication with the external engine. Custom code (now termed workers) can still be written, functioning as specialized assistants that interact with the engine remotely.
The overall structure of a process solution remains largely unchanged between Camunda 7 and 8. Both versions utilize a single Java application to house your process models and custom code. The key distinction lies in Camunda 8, where engine setup becomes independent of your core application, promoting a lighter-weight and more flexible architecture.
Still in doubt whether to migrate or not?
The decision to migrate from Camunda 7 to Camunda 8 can be a strategic one for your business. Understanding the key differences and considerations outlined above will equip you to make an informed choice.
However, navigating the migration process itself can be complex. As a Gold Certified Partner of Camunda, we have extensive experience in business process automation using both Camunda 7 and 8. Our team of experts can help you assess your migration needs, develop a customized plan, and ensure a smooth transition.
Don't hesitate to reach out to us via this contact form to schedule a free consultation. We'll answer any questions you may have and help you determine the best path forward for your organization. Let's leverage the power of Camunda 8 to streamline your processes and unlock new levels of efficiency.
