Camunda 8.9 lands on April 14, 2026. Camunda keeps pushing the direction it made more visible in 8.8: stronger agentic orchestration building blocks, a clearer Orchestration Cluster API story, fewer migration gaps from Camunda 7, and a more mature connector runtime.
The upgrade pressure is not the same for every team. If you mostly run Camunda SaaS with standard clients, the move should feel manageable. If you run your own connector runtime, build custom SDK integrations, or rely on specific API behavior, read the breaking changes carefully. The main watch-outs are the Spring Boot 4 requirement, MCP related connector changes, and broader client and API compatibility cleanup.
The date matters for another reason as well: Camunda 8.6 reaches end of maintenance on the same day. If you are still on 8.6, it is time to move.
Agentic AI And AI Facing Changes
Camunda is clearly putting more weight behind agentic orchestration. In 8.9, the platform pieces around that story get more concrete.
The clearest example is the built-in MCP support in the Orchestration Cluster. Camunda can now expose operational capabilities through an MCP server, so MCP-capable clients can discover and invoke Camunda tools without custom API glue code. That includes tools around process definitions, process instances, user tasks, incidents, and variables. Streamable HTTP support makes that more practical for real MCP clients.
Camunda also adds an MCP server for the Camunda docs. Agents should not only call tools, they also need a trustworthy way to read the product documentation they depend on. In practice, this gives them a cleaner path to Camunda docs instead of relying on copied snippets or ad hoc retrieval.
There is also movement on the A2A side. Camunda adds A2A Client, A2A Client Polling, and A2A Client Webhook connectors in 8.9. That fits the same direction: agents should not only call one model or one tool, but also work across more structured agent-to-agent patterns. This is still earlier-stage than the MCP story, but it shows where the AI integration model is expanding.
For me this is a clear sign that Camunda keeps investing in AI, and 8.9 shows they’re serious about it.
API Direction And Orchestration Cluster
The next theme is platform consolidation around the Orchestration Cluster API. Camunda introduced the Orchestration Cluster and its API with Camunda 8.8 in October 2025. So 8.9 is not the start of that story, but a clear continuation of it.
Operate now uses the Orchestration Cluster REST API as its single interface for accessing and managing process data. That reduces the distance between what the product uses internally and what customers use for their own tooling. On top of that, 8.9 adds more operational capabilities on the same path, for example deleting process and decision definitions or instances consistently through the Orchestration Cluster API and Operate. Even smaller behavior changes, like deletion endpoints now returning a response body, point in the same direction.
The takeaway for me is that the platform is getting more coherent around one API direction.
If you have custom scripts, generated clients, internal wrappers, or direct integrations, this is the release where it makes sense to review your assumptions. If you mostly stay on supported tooling, you mainly need to know where the platform is moving.
Migration Relevant Changes
This part of the release closes a few gaps that Camunda 7 teams have felt for a while. Camunda has pushed Camunda 7 Enterprise Edition end of life to April 9, 2030, but it still stays on the final 7.24 minor release. That gives customers more time, but it also makes the migration path more important. In that window, Camunda keeps trying to smooth out the move to 8 where it can.
The most obvious one is BPMN conditional events. Camunda 8 now supports conditional start, boundary, and intermediate catch events. It makes BPMN models more expressive, removes some workaround patterns, and makes migration conversations from Camunda 7 a bit less awkward.
Business ID is another good example. You can now create process instances with an immutable business identifier, and uniqueness validation can be enabled at cluster level for idempotent starts. That is useful far beyond migration, but migration teams will recognize the value immediately.
Taken together, I think this is probably the clearest “what got easier now” section in the release.
Connector Runtime And SDK Details
First, connectors now use a virtual threads executor by default. That should improve performance and scalability, especially for the I/O-heavy workloads that are typical in connector runtimes. In simple terms, the runtime should handle more concurrent jobs with lower resource consumption.
On the SDK side, the clearest headline is that the Camunda Spring Boot Starter now requires Spring Boot 4.0.x. That alone can decide how much work your upgrade takes, and Camunda ties it directly to the Spring Boot support policy, because support for Spring Boot 3 ends in June 2026. Also, OpenJDK 25 is now supported across Orchestration Cluster, Connectors, Optimize, and related tooling.
Other Practical Changes
After the four bigger themes, the rest of the release is mostly about operational maturity. These are not the headline items, but they still improve how the platform feels in day-to-day work.
Worth Mentioning
One of the nicest operational additions is the new audit log. It is available in Operate, Identity, Tasklist, and the Camunda 8 REST API. That improves traceability, governance, and troubleshooting.
One strong SaaS addition is the Cluster Metrics endpoint for Orchestration Cluster. That matters because it gives teams a cleaner way to get cluster metrics into their own observability stack instead of treating SaaS metrics as something locked inside the platform.
Self-Managed Quick Notes
Self-Managed is not the focus of this article, but there is one change that stands out more than the others: RDBMS support for Orchestration Cluster as an alternative storage path alongside Elasticsearch or OpenSearch.
That is a big deal. For teams that want a more familiar operational model, or already run database-centric platforms, this can lower the barrier to self-managed Camunda noticeably. It does not remove the need for real platform ownership, but it changes the conversation around what self-managed Camunda can look like.
Summary
Taken together, Camunda 8.9 looks like a consolidation release with a purpose. It sharpens the AI and API direction introduced in 8.8, closes a few migration pain points, and improves runtime behavior where it matters.
If you are on 8.6, the maintenance deadline is the forcing function. If you are migrating from Camunda 7, a few long-standing gaps get smaller here. And if you work with connectors, AI integrations, or custom SDK code, 8.9 is the point where a careful upgrade review pays off.
Having worked m on several of these features for months now, I’m really happy to read on how do you perceive them “from the other side”. It’s great to see that the API changes seem as intended- building on the baseline that we released with 8.8.
I’m particularly happy to read that you appreciate rdbms support as this one took almost 2 years to build - however we can already see a huge return on this investment with customers who prepare to migrate or start net new workloads because of that capability.