Erstellt am
07.12.2025
|
Von
Alois und Johannes
Sonstiges
Unternehmenskultur
Health
Methode
FinsurTech
Business
Tech

Von Camunda 7 zu Camunda 8: Unser Realitätscheck aus der Praxis

Unser Praxistest zeigt: Der Umstieg von Camunda 7 auf Camunda 8 ist kein Upgrade, sondern ein Architekturwechsel. Wir teilen Erfahrungen aus einer Self-Managed Umgebung, beleuchten Hürden und zeigen Alternativen für Unternehmen auf.

Camunda positioniert Camunda 8 (C8) als die Zukunft der Plattform. Spätestens mit der Ankündigung, dass Camunda 7 keine funktionalen Weiterentwicklungen mehr erhält, wurde die Frage nach Migration, Weiterbetrieb oder Alternativen in vielen Unternehmen plötzlich sehr real.

Gerade in Branchen wie Banken und Versicherungen, in denen Prozesse seit Jahren stabil und tief integriert auf Camunda 7 laufen, ist ein schneller Wechsel nicht trivial – und schon gar nicht risikolos.

Wir haben uns daher gefragt:
Jetzt migrieren? Erst einmal abwarten? Oder sogar auf eine Alternative setzen?

In diesem Beitrag teilen wir unseren ersten Realitätscheck zu Camunda 8 – konkret aus einer self-managed Umgebung im Enterprise-Kontext.

Ausgangslage: Warum wir Camunda 8 früh evaluiert haben

Wir arbeiten seit vielen Jahren produktiv mit Camunda 7, self-hosted in einer komplexen Konzernumgebung. Die Engine ist eng mit Java-Anwendungen, Berechtigungssystemen und konzernweiten Sicherheitsstandards verzahnt.

Als das Ende der Weiterentwicklung von C7 absehbar wurde, war klar:
Wir müssen Camunda 8 technisch evaluieren – lieber früher als später.

Unsere Erwartung war einfach:
C8 als moderne Weiterentwicklung und damit der logische nächste Schritt.

Die Realität sah anders aus:
👉 Camunda 8 ist kein Upgrade – es ist ein Architekturwechsel.

Was wir mit Camunda 8 konkret getestet haben

Wir haben Camunda 8 umfassend technisch evaluiert – vollständig self-managed und in der bestehenden Konzernarchitektur integriert.

1. Infrastruktur & Architektur

  • Aufbau eines Self-Managed C8 Clusters im eigenen Rechenzentrum
  • Integration in zentrale Systeme (Datenbanken, Authentifizierung, Security Policies)

2. Migration & Implementierung

  • Migration erster reale BPMN-Prozesse von C7 auf C8
  • Umsetzung eigener Job-Worker und Connectoren
  • Anbindung einer bestehenden externen User-Tasklist/Postkorb-Lösung

3. Tooling & Plattformkomponenten

  • Vergleich Web Modeler vs. Desktop Modeler
  • Bewertung von Operate im Vergleich zum bekannten C7-Cockpit
  • Analyse von Optimize und Console für Monitoring und Betrieb

Unser Fazit an dieser Stelle:
Technisch lief das stabil – aber es fühlt sich nicht wie „Camunda 7++“ an, sondern wie eine neue Plattform.

Unterschiede, die man erst im praktischen Einsatz merkt

Viele Veränderungen sind nicht nur „neu“, sondern haben tiefgreifende Auswirkungen auf Architektur, Entwicklung und Betrieb.

Die wichtigsten Paradigmenwechsel:

  • Kein Embedded-Modell mehr
  • Wegfall von Java-Delegates & des transaktionalen ACID-Modells
  • Service-Tasks müssen idempotent sein
  • Kommunikation über gRPC/REST statt Java-Integration
  • JSON-only statt Java-Objekte
  • Externe Worker statt Inline-Logik
  • FEEL statt freier Skriptsprachen
  • Operate nur mit Enterprise-Lizenz voll nutzbar

Das ist modern – aber eben ein massiver Architekturwechsel, der tief ins System eingreift.

Wo Camunda 8 uns (noch) überrascht oder ausbremst

In der praktischen Umsetzung traten folgende Herausforderungen auf:

  • Fehlende BPMN-Features für komplexe echte Prozesse
  • Unvollständiges User-Management
  • Nur eingeschränkte Abbildung typischer Enterprise-IT-Patterns
  • Modellmigration kaum automatisierbar
  • Komplexere Architektur → aufwendigeres Setup & Betrieb
  • Debugging & Observability deutlich anspruchsvoller
  • Updates im Cluster erwiesen sich als fehleranfällig

Nichts davon ist ein „No-Go“. Aber vieles davon erzeugt spürbaren Mehraufwand.

Die echte Entscheidungsfrage: Welche Alternativen gibt es?

Häufig wird die Diskussion auf „Camunda 7 oder 8“ reduziert.
Für Unternehmen, die aus Compliance- oder Datenschutzgründen zwingend auf self-managed setzen müssen, gibt es jedoch zwei realistische Pfade.

Option 1: Camunda 7 bewusst weiterbetreiben

Durch den verlängerten Support bis 2030 (optional bis 2032) bleibt C7 eine stabile und zukunftssichere Plattform.

Für viele Unternehmen ist das heute der vernünftigste Ansatz:

  • Betrieb stabil halten
  • Risiken beherrschbar halten
  • Modernisierung außerhalb der Engine vorantreiben

Das ist kein Stillstand – sondern eine kontrollierte Evolution.

Option 2: Forks von Camunda 7 als Langzeitstrategie

Projekte wie CIB seven oder EximeeBPMS bieten echte LTS-Alternativen.

Die Vorteile:

  • Bestehende BPMN-Modelle weiter nutzbar
  • Keine komplette Architektur-Neuerfindung
  • Fokus auf Stabilität und Enterprise-Langlebigkeit

Für viele Organisationen kann das ein strategischer LTS-Pfad sein – und keine Notlösung.

Unsere ehrliche Zwischenbilanz zu Camunda 8

Nach unseren ersten realen Tests lässt sich sagen:

Die positiven Punkte:

  • Architektonisch stark
  • Sauberer technologischer Ansatz
  • Hervorragende Skalierbarkeit

Die Realität für bestehende C7-Setups:

  • Der notwendige Umbau ist oft größer als der Mehrwert
  • Der verlängerte Support nimmt den Druck aus der Entscheidung
  • Ein übereilter Umstieg ist selten sinnvoll

Wie es weitergeht – Vorschau auf Teil 2

Wir bleiben an dem Thema dran.  

In Teil 2 dieser Serie werden wir:

  • Eine echte End-to-End-Migration durchführen
  • CIB seven detailliert testen
  • Aufwand & Risiken realistisch beziffern
  • Zeigen, was in der Praxis funktioniert – und was nicht

Neugierig geworden?

Vereinbare einen Termin mit Sebastian, um gemeinsam herauszufinden, wie wir Dich unterstützen können.

Oder schreib mir:

01759723518

Sebastian Schwiedernoch

ssc@codecamp-n.com

Neugierig geworden?

Vereinbare deinen Video-Call mit Sebastian, um gemeinsam herauszufinden, wie wir dich unterstützen können.

Oder schreib mir: