Assess models, application code, and runtime data before planning a transition. Camunda 8 is not a drop-in replacement for Camunda 7.
List processes, DMN models, forms, delegates, API dependencies, active instances, and operational integrations. Group repeated patterns so effort estimates reflect the actual solution rather than the count of files alone.
Try it: Create an inventory for three sample processes and flag every Camunda 7-specific API or execution behavior used by application code.Camunda describes simplified and advanced journeys. Some solutions can be rebuilt and drained in parallel; others need model conversion, code refactoring, and state migration. Decide per process rather than assuming one big switch suits all workloads.
Try it: For one short-running and one long-running process, compare a drain-out approach with a coordinated instance migration.Review BPMN and DMN behavior, expressions, Java delegates, transaction assumptions, and observability under Camunda 8. Converted diagrams and code still require functional and operational testing.
Try it: Select an approval process, document its expected outcomes in Camunda 7, and design tests that prove the Camunda 8 implementation preserves them.Define how new instances are routed, how old instances complete or move, and when the old platform can be decommissioned. Include data reconciliation and a recovery decision if the new route fails.
Try it: Write a rollout checklist with owner, evidence, and go/no-go criterion for each stage of one process migration.Short-lived processes may be allowed to finish on Camunda 7 while new work starts on Camunda 8. Long-running instances may require more careful coordination or a supported instance-migration approach. The choice depends on business duration, legal audit needs, data state, integration contracts, and whether the process can be paused. Avoid equating a count of BPMN files with effort: a small diagram that calls several Java delegates may require more application refactoring than a larger model built around external services. Camunda's migration guide separates the journey, conceptual differences, tools, and preparation because these decisions cannot be collapsed into one library change.
Try it: Classify three processes by typical duration, active-instance count, Camunda 7-specific code, and external dependencies. Propose drain, rebuild, or deeper migration analysis for each, with a reason.A converted BPMN file may deploy yet behave differently around transactions, expressions, task implementation, variable scope, or failure handling. Compare observed Camunda 7 outcomes with the intended Camunda 8 flow, including delayed messages, retries, user-task assignment, and decision results. Replace embedded platform-specific delegates with an implementation that matches the new architecture rather than trying to preserve old class names. For every changed behavior, write an acceptance case that a business owner understands and a technical assertion that can be run. This catches a process that appears to complete but silently skips an approval or repeats a side effect.
Try it: Choose one approval process and list five old behaviors to preserve. Write the Camunda 8 test input, expected business outcome, and technical observation for each.During transition, two engines may process different instances of the same business journey. Define how new requests are routed, how support teams locate an existing instance, and how status reports combine data without double-counting. Reconcile external side effects and ensure callers use the right endpoint for old and new work. Decommissioning Camunda 7 should be a decision based on completed or deliberately migrated instances, retained audit evidence, and a rollback boundary—not a calendar date alone. Treat migration as a staged project with owners for process models, worker code, data, operations, and business validation.
Try it: Draft a cutover runbook for one process: routing switch, monitoring period, exception owner, rollback trigger, reconciliation query, and evidence that no old instance was abandoned.This topic is an independent ITCertPath learning guide, not a separately named Camunda credential. Check current product behavior in the official documentation.
Read the official Camunda documentation ↗Tell us your goal, country and preferred schedule. Ask for the written syllabus, trainer, delivery format, fee and cancellation terms before enrolling.