When Camunda 7 announced end-of-life, we were running it at the core of our process automation platform. Here’s the honest account of how we evaluated alternatives, ran the migration, and kept production stable throughout — without a “big bang” cutover.
Challenge
Our Entire Process Automation Stack Ran on a Dead-End Engine
We had built years of business process automation on Camunda 7 — an embedded Java-based workflow engine deeply integrated across multiple internal systems. When Camunda announced it was ending active development of version 7, the vendor sales cycle kicked off immediately: every alternative platform showed up with a “seamless migration” pitch.
The obvious next step — Camunda 8 — turned out to be a fundamentally different product. A distributed cluster (Zeebe brokers, gateway, Operate, Tasklist) designed for Kubernetes and horizontal scaling is a completely different animal from an embedded Java engine sharing a database. The migration path wasn’t an upgrade. It was a rewrite.
Beyond the architecture gap, Camunda 8 introduced a reduced BPMN profile, an event-driven paradigm shift, new infrastructure requirements (Kubernetes, Helm, gRPC clients, full observability stack), and a commercial licensing model that significantly changed TCO compared to the free Community Edition we were running. Staying on Camunda 7 indefinitely wasn’t viable — but jumping to Camunda 8 wasn’t either.
Solution
A Four-Phase Migration: Audit First, Ship Last
We rejected the vendor-driven approach and built our own structured path. Every phase was designed to generate real data before any production decision was made.
Phase 1: AS-IS Audit. Before evaluating a single alternative, we inventoried everything — total process count, active vs. dormant processes, average BPMN node complexity, cross-service transaction dependencies, custom plugins, middleware versions, and team expertise levels. This audit surfaced a key architectural split: some processes were BPMN-heavy flows crossing multiple systems; others were high-volume simple automations inside a single service. The replacement strategy turned out to be different for each category.
Phase 2: Alternatives Evaluation. We built a weighted scoring matrix — migration cost, infrastructure fit, licensing, BPMN compliance, integration complexity — and scored each candidate 1–5. The shortlist we evaluated included Flowable, Temporal, and Zeebe Open Source, in addition to Camunda 8. Our conclusion: Flowable was the natural fit for BPMN-heavy processes with deep notation dependencies; Temporal suited event-driven, microservice-oriented, and long-running distributed workflows by design. The matrix isn’t meant to be copied — it’s meant to be rebuilt around your own constraints.
Phase 3: Proof of Concept. Before touching production, we stood up isolated test environments for our shortlisted candidates — separate namespaces in Kubernetes, dedicated CI/CD pipelines, and a lightweight adapter layer connecting the new engine to existing systems via REST and Kafka. We ported 2–3 representative processes from each category, ran full dev-deploy-monitor-support cycles, and collected metrics: development time per process, error rates, infrastructure load, and team feedback. Load testing was applied where throughput was a factor.
Phase 4: Phased Migration to Production. We prioritized processes by risk and change frequency — starting with non-critical but frequently-modified workflows, not the most important ones. Each process migration followed the same sequence: dependency analysis → rewrite on the new engine → integration testing → parallel production run → controlled cutover. OpenTelemetry-based observability was configured before any process went live on the new platform.
On Camunda 7 forks: Community forks (such as CIB seven) have emerged to extend Camunda 7’s lifespan. This isn’t a long-term solution — but it does provide a realistic runway for teams who need 12–18 months to migrate properly rather than scrambling under deadline pressure.
Result
Zero Downtime. Zero Big-Bang Cutover. Full Team Buy-In.
The migration is ongoing — by design. Here’s where we stand and what the approach delivered:
- Production remained stable throughout — no business process interruptions at any stage of migration
- PoC phase surfaced real complexity estimates before any engineering commitments were made
- BPMN-heavy processes migrated to Flowable; event-driven workflows routed to Temporal — right tool for each job
- Unified observability via OpenTelemetry across both legacy and new engines from day one of cutover
- Camunda 7 is now a controlled legacy island with defined decommission timelines — not an unmanaged liability
- Engineering team onboarded through hands-on sandbox environments — adoption resistance was minimal
Approach
4 phases
Audit → PoC → Migrate → Optimize
Outcome
0 outages
During active migration
Signal
2 weeks
PoC to real complexity data
Five principles that held throughout:
- Don’t rush. Community forks buy real time. Use it for a controlled migration, not a panicked one.
- Audit before evaluating. Without an inventory of your processes, any technology discussion is just opinion.
- Test on real processes. Two to three processes over two weeks will reveal complexity that no vendor demo ever will.
- Involve your engineers early. Your developers know where the bodies are buried. They’re your best risk signal.
- Always have a rollback plan. Parallel runs, feature flags, and defined rollback criteria — before every cutover, not after.
Bottom line
“Platform end-of-life is a forcing function, not an emergency. Teams that treat it as an opportunity to audit, test, and migrate deliberately end up with better infrastructure than they started with. Teams that panic end up with a bigger mess.”
