Executive Summary
Camunda 7’s published end-of-maintenance timeline has turned a strategic conversation into a planning imperative. Every enterprise running Camunda 7 today must decide: stay and self-support an increasingly expensive legacy stack, move to a different platform and strand existing process IP, or migrate to Camunda 8.9.
For most enterprises, the third option is now the rational default — and Camunda 8.9 (Migration Version 0.3.0) is the release that makes it so. It ships first-class data migration tooling capable of carrying live process instances, audit history, and identity across the platform boundary with no data loss. It introduces RDBMS as a first-class secondary storage option, eliminating the dedicated Elasticsearch dependency. It adds native BPMN conditional events, user-task lifecycle listeners, and first-class agentic orchestration controls. And it provides a code-conversion pathway that — combined with AI coding assistants — reduces the manual refactoring burden dramatically.
We validated the complete toolchain end to end on a loan-application process. The headline result: it works. Three live process instances carried across the platform boundary, parked at exactly the right flow node, with variables intact and forward execution fully preserved. History and identity migrated cleanly. The AI-assisted code conversion reduced a full Java delegate and external-task refactor to a matter of hours.
This paper reports what we did, what we learned, and what it means for enterprises planning the move.
1. The Migration Toolchain
Camunda’s migration story for 7 → 8.9 is a coordinated set of three tools, each addressing a distinct layer of the migration problem.
Diagram Converter
A Spring Boot web application that transforms Camunda 7 BPMN and DMN models into Camunda 8-compatible XML. It handles the structural mapping work automatically: camunda:class → zeebe:taskDefinition, camunda:topic → Zeebe job type, camunda:formData → Camunda User Task form, camunda:decisionRef → zeebe:calledDecision, FEEL-style conditions on sequence flows. As of 8.9, it also detects and converts Camunda 7 conditional events into their native Camunda 8 equivalents — a capability that was not available in earlier releases.
Code Conversion — OpenRewrite + AI-Assisted Pattern Migration
Code conversion is where the engineering effort in a typical migration lives. Camunda provides two tools for it, designed to work together.
The OpenRewrite recipe set (AllClientRecipes, AllDelegateRecipes, AllExternalWorkerRecipes) handles the high-frequency, well-structured refactorings automatically via a Maven plugin: JavaDelegate → @JobWorker, RuntimeService → CamundaClient, External Task Worker → @JobWorker, Camunda Platform Assert → Camunda Process Test. These run in seconds and cover most of the codebase in a typical migration.
For everything the recipes don’t reach — validation logic, error handling patterns, edge-case API usage, test setup — Camunda publishes a comprehensive library of code-conversion patterns in plain Markdown. This is where the AI-assisted migration story becomes concrete: those patterns are designed to be used verbatim as prompts for any modern coding assistant (GitHub Copilot, Claude, Cursor, or similar). In our engagement, we used this approach for Community Edition code — feeding the documented pattern alongside the C7 method, receiving C8-idiomatic output. What would otherwise be a week of manual refactoring was compressed into hours. The patterns are precise enough that the AI output required only light review, not rewriting.
The combination — automated recipes for the common patterns, AI-assisted pattern migration for the long tail — means the “we’d need to rewrite the whole thing” conversation no longer
As of 8.9, the full three-phase migration is available for self-managed deployments. History and identity modes require Camunda 8 with RDBMS as secondary storage — a prerequisite that is both a constraint and an opportunity, as discussed in Section 4.
2. The Workload We Migrated
The loan-application workflow we migrated from Camunda 7 to Camunda 8.9 represents a real-world enterprise process, encompassing:
- A None Start Event — the start event the Data Migrator’s runtime mode requires
- A Service Task backed by a Java delegate with asyncBefore=”true”
- A Business Rule Task invoking a DMN decision table (credit-risk-evaluation) to derive a risk level from loan amount and credit score
- An Exclusive Gateway with three FEEL-bound branches: HIGH risk (terminate), MEDIUM risk (route to user review), LOW risk (skip review)
- A User Task with form fields and a candidate group (loan-officers)
- Two External Task Service Tasks (notification-service, payment-service topics)
- A final Service Task with a second Java delegate for loan disbursement
- Three Terminate End Events
The Camunda 7 implementation is a Spring Boot service embedding a Camunda 7 CE engine on PostgreSQL with history-level: full. The existing data included a representative spread of instances: two LOW-risk instances that had auto-completed, three MEDIUM-risk instances parked at the user task (the runtime migration targets), two HIGH-risk instances that had terminated, and one incident scenario — eight historic instances in total, three of them live, covering every entity type the migrator handles.
3. What the Migration Delivered
We ran the toolchain in sequence. Diagram Converter on both BPMN and DMN files. OpenRewrite recipes against the Java codebase — ValidateApplicationDelegate and DisburseLoanDelegate became @JobWorker-annotated methods; the external-task workers became Job Workers for payment-service and notification-service. The remaining validation and error-handling logic was converted using the AI-assisted pattern approach against Camunda’s published pattern library.
The Data Migrator ran against a self-managed Camunda 8.9.2 cluster with PostgreSQL as secondary storage and Keycloak/OIDC authentication, in order: identity → runtime → history.
Identity migration brought across the camunda-admin group’s authorizations for all resource types that map to Camunda 8 (Authorization, ProcessDefinition, DecisionDefinition, Tenant, Batch, DecisionRequirementsDefinition, Deployment, System). Resource types without a Camunda 8 equivalent (Filter, Task, Dashboard, Report, Optimize and others) were skipped as documented.
Runtime migration recreated the three MEDIUM-risk process instances in Camunda 8 as active workflows, each carrying the original process variables (applicantName, amount, creditScore, riskResult) plus a legacyId variable injected by the migrator linking each new instance back to its Camunda 7 origin. All three appeared in Camunda 8 Operate at flow node Task_ReviewLoan — exactly where they had been parked in Camunda 7 Cockpit.
History migration brought all eight historic instances across as audit-only entries under a c7-legacy-loan-application definition. The five genuinely completed or terminated instances appear as COMPLETED. The three that correspond to the migrated active instances appear as CANCELED, with an end date set to the migration timestamp — the Camunda 7 audit record is preserved while the live Camunda 8 instance carries the workflow forward. The eight DMN evaluations from the credit-risk decisions came across as c7-legacy-credit-risk-evaluation decision instances.
The forward-execution proof is the demonstration that matters most to enterprise stakeholders: we opened Camunda 8 Tasklist, claimed one of the three migrated user tasks, and completed it with an approval decision. The instance advanced through the gateway, the payment-service Job Worker produced a transaction ID, the disburseLoanDelegate Job Worker disbursed the loan, and the instance reached its end state cleanly.
Forward execution preserved across the platform boundary. That is what migration feasibility ultimately means — not that data moved, but that live workflows continue.
4. Five Things to Know Before You Start
The journey to the result above was instructive. Five observations stand out — none are blockers, all are things an experienced team can absorb in advance to avoid losing time mid-engagement.
The Camunda 8 baseline is a prerequisite, not an optimisation. History migration requires Camunda 8 with RDBMS as secondary storage in a self-managed deployment. The default docker compose evaluation stacks use Elasticsearch, which cannot support history migration. For any migration engagement, “RDBMS secondary storage configured” must be treated as a day-one infrastructure requirement, not a post-migration tuning item.
Java 21 LTS specifically — not “any JDK ≥ 21”. The Data Migrator is published with a Java 21+ prerequisite. In practice, newer JDKs (24, 25) surface incompatibilities in the embedded Netty/gRPC and Camunda 7 engine code paths related to sun.misc.Unsafe removal and tightened native-access restrictions. Java 21 LTS is the version that works cleanly.
Windows timezone aliasing requires one flag. On Windows hosts in Indian Standard Time, the JVM resolves the system timezone to the legacy IANA alias Asia/Calcutta, which PostgreSQL rejects with a FATAL: invalid value for parameter “TimeZone” error. Adding -Duser.timezone=Asia/Kolkata to the JVM invocation resolves it. The failure surfaces deep in Spring bean creation as a generic “Constructor threw exception” without this context — not obvious without prior knowledge.
Externalised configuration has an undocumented discovery requirement. The migrator distribution ships with a configuration/application.yml next to the JAR. Spring Boot’s PropertiesLauncher does not auto-discover this path — its defaults are ./ and ./config/, not ./configuration/. The migrator must be launched with -Dspring.config.location=optional:classpath:/,optional:file:./configuration/ to load the YAML. A wrapper script that encodes this flag eliminates the issue entirely for subsequent runs.
The runtime listener validator is a literal-string match in v0.3.0. Camunda’s documentation describes a FEEL-expression pattern for the migrator execution listener intended to support transition periods where migrated and externally-started instances coexist. In Data Migrator v0.3.0, the validator performs a literal string comparison on the listener type attribute — it does not evaluate FEEL. With the FEEL guard deployed, every process instance is skipped. The correct approach is to deploy the literal type=”migrator” listener for the migration window, then redeploy the BPMN with the listener removed after migration completes.
5. Why Camunda 8.9 Is the Right Destination
A migration is only worth the effort if the destination is better than the origin. Camunda 8.9 clears that bar on five dimensions that matter to enterprise customers.
Process instance migration as a platform primitive
Camunda 8.9 promotes process instance migration from an exceptional operation to a routine one. Running workflows — including ad-hoc sub-processes and AI agent flows — can be moved from one process definition version to another without losing execution state, via both the API and the Operate UI. The state-preserving migration we performed during the C7 → C8 cutover is now a standard operational capability available within Camunda 8 itself. Long-running workflows can be modernised, schema-evolved, and restructured without drain-and-restart windows.
RDBMS as a first-class operational choice
Camunda 8.9 adds full support for PostgreSQL, Amazon Aurora, MariaDB, MySQL, Oracle, and Microsoft SQL Server as secondary storage for orchestration clusters — with Helm-chart integration out of the box. Elasticsearch and OpenSearch remain available; RDBMS is now an equal-first-class option, not a workaround.
For enterprises with existing PostgreSQL or Aurora infrastructure, this is significant: audit history, decision evaluations, and process state land inside the same managed database estate the business already operates, with the backup, DR, compliance, and cost profile that comes with it. It also eliminates a common operational objection to C8 adoption — the need to stand up and maintain a dedicated Elasticsearch cluster for process history.
Native BPMN conditional events
Camunda 8.9 introduces native support for conditional start events, conditional boundary events, and conditional intermediate catch events. Process logic like “wait until the customer balance exceeds the threshold” or “trigger a compliance review if a risk flag is raised mid-process” is now expressible directly in the BPMN model. The Diagram Converter also detects and converts Camunda 7 conditional events into their Camunda 8 equivalents during migration.
Every Camunda 7 deployment that grew up before this support has accumulated workaround patterns — polling jobs, custom schedulers, external event brokers. Migration is the natural moment to retire those workarounds and consolidate the logic into the model. The result is process definitions that are cheaper to reason about, faster to change, and smaller in operational surface area.
Agentic orchestration with enterprise-grade controls
Camunda 8.9 positions the orchestration cluster as an AI agent host with the controls enterprises require: AWS Bedrock API key authentication, per-model timeouts on AI Agent connectors, query-parameterised OpenAI-compatible endpoints, ad-hoc sub-process orchestration for agent tool-call patterns, and a global user-task listener API for full lifecycle management of task assignment, claim, and completion events.
Camunda 7 has no equivalent. The common alternative — a separate AI orchestration layer outside the process engine — duplicates audit infrastructure, splits the operational footprint, and creates a new failure domain. In Camunda 8.9, the same engine that runs the loan-application workflow is also the platform that runs next year’s AI-augmented variant of that workflow, with the same audit trail, retry model, incident handling, and human-in-the-loop semantics already in place.
For enterprises with an AI-process-automation roadmap, this collapses two separate platform decisions into one.
A developer experience that no longer asks for trade-offs
Camunda 8 historically asked developers to trade some Camunda-7-era ergonomics for the benefits of the new architecture. As of 8.9, that trade is largely gone. User-task listeners provide assignment, claim, and completion hooks without custom workers — closing one of the most frequently cited C7 → C8 functional gaps. The Camunda Spring SDK (camunda-spring-boot-starter, @JobWorker, OIDC built in, @Deployment for resource bundling) has reached production maturity. Camunda Process Test replaces Camunda Platform Assert with full parity, covered by the OpenRewrite recipes. A developer migrating a workflow in 2026 writes less glue code, less boilerplate, and less infrastructure configuration than a developer doing the equivalent work on Camunda 7.
6. Accelerating the Engagement
One of the outcomes of this validation is a set of reusable artifacts that materially compress the time between “we have the tools” and “the customer’s workload is running on the new platform.”
Pre-flight verification script — validates Java version, JDBC driver presence, network reachability to all dependencies, and that Camunda 7 is stopped before any migration phase runs. Encodes every environmental prerequisite as an automated check.
Migration runner script — wraps the Data Migrator JAR with the JVM flags required on every invocation (-Duser.timezone, -Dspring.config.location, LOADER_PATH for the JDBC driver). Eliminates the most common class of first-run failures.
Parameterised migrator configuration — a templated application.yml with the Spring Boot autoconfiguration exclusions, OIDC block, and C7/C8 datasource configuration pre-structured. Ready to fill in, not ready to debug.
Validation query catalogue — SQL queries confirming post-migration state in the Camunda 8 RDBMS: process instance counts by definition and state, active flow nodes, decision instances by definition, variable inventory, and migration-mapping integrity.
Runbook and step-by-step run guide — the long-form document captures every architectural decision and every issue encountered with root cause and fix. The run guide is a follow-along checklist for the next team.
Together, these artifacts reduce the typical “first successful end-to-end migration” loop from days to hours. The runbook in particular means the five observations in Section 4 are pre-empted, not discovered.
Conclusion
The Camunda 7 → 8.9 migration is no longer the heroic, multi-quarter rewrite it was before. The toolchain is real. It works. The rough edges are absorbable and documentable. And the destination — Camunda 8.9 — is a platform that delivers operational simplicity, functional depth, and a forward-looking AI orchestration capability that Camunda 7 cannot match.
For enterprises running Camunda 7 today, the question is no longer “is migration possible?” It is “what is the timeline, what does it cost, and who runs the project?”
We have validated answers to all three. If you are planning the transition, we would be glad to walk through the migration path on a process from your own portfolio. The discovery is short and contained, and it turns the abstract “should we migrate?” question into a concrete “here is what migration would actually look like — scoped, costed, and timelined.”
Hariharan B
Senior Engineer @Acheron Software Consultancy Pvt Ltd.,
Camunda Developer Certified, Workflow Orchestrator, AI Agent Orchestrator, Cloud Services
