Was ist Camunda? Ein Name, zwei verschiedene Produkte

Camunda ist heute zwei verschiedene Produkte mit einem gemeinsamen Namen. Camunda 7 ist ein Java-Framework: Die Prozess-Engine kann in Ihrer eigenen Anwendung laufen, im selben Prozess, oft an derselben Datenbank. Camunda 8 ist eine vollständige Neuentwicklung: Die Engine heisst Zeebe, läuft als eigener Dienst neben Ihrer Anwendung, und Ihre Anwendung spricht sie über das Netz an.

Fast jede Frage, die danach kommt, hängt an dieser einen Unterscheidung: was ein Upgrade kostet, welche Lizenz Sie brauchen, ob Ihr Code weiterläuft, und ob eines der Wartungsdaten Sie überhaupt betrifft. Deshalb steht sie hier vorn und nicht am Ende.

Wer steht hinter Camunda?

Hinter camunda.com steht laut Impressum die Camunda Services GmbH, Zossener Straße 55-58, 10961 Berlin, eingetragen beim Amtsgericht Charlottenburg (camunda.com, Imprint). Welche Camunda-Gesellschaft Vertragspartnerin ist, hängt in Camundas Vertragsbedingungen vom Sitz des Kunden ab. Für einen Sitz in Deutschland, Österreich oder der Schweiz nennen die Camunda Enterprise General Terms in Abschnitt 12 die Berliner GmbH, deutsches Recht und den Gerichtsstand Berlin. Die Self-Managed Non-Production Terms regeln es in Abschnitt 11 ebenso (Camunda Legal Center, Licensing and Other Legal Terms). Das ist für eine Beschaffungsabteilung in der Schweiz gelegentlich die erste relevante Information über das Produkt.

Ältere Unterlagen nennen dieselben zwei Produkte anders. Camundas eigene Support Announcements schreiben bis heute „Camunda Platform 7“ und „Camunda Platform 8“ (docs.camunda.org, Support Announcements). Der noch ältere Name Camunda BPM lebt bei Camunda 7 weiter, in der Maven-Gruppe org.camunda.bpm und im Namen des Repositorys camunda-bpm-platform.

Camunda 7: eine Engine, die in Ihrer Anwendung läuft

Camunda beschreibt Camunda 7 selbst als Java-Framework, das auf zwei Arten betrieben werden kann: „Camunda can be used both as a standalone process engine server or embedded inside custom Java applications.“ Und weiter: „The embeddability requirement is at the heart of many architectural decisions within Camunda.“ (docs.camunda.org, Architecture)

Die Dokumentation nennt drei Betriebsarten. Welche Sie fahren, entscheidet später darüber, wie teuer ein Wechsel wird.

Nur die dritte dieser drei Formen hat in Camunda 8 eine Entsprechung. Das ist der Kern des ganzen Themas, und es ist der Grund, warum zwei Unternehmen mit derselben Camunda-Version völlig verschiedene Migrationen vor sich haben.

Zu den Webanwendungen von Camunda 7 gehören Cockpit für Überwachung und Betrieb, Tasklist für die Bearbeitung von Benutzeraufgaben und Admin für die Benutzerverwaltung (docs.camunda.org, Web Applications).

Camunda 8: eine Engine, die neben Ihrer Anwendung läuft

Die Engine von Camunda 8 heisst Zeebe. Camunda beschreibt sie so: „Zeebe is the process automation engine powering Camunda 8. While written in Java, you do not need to be a Java developer to use Zeebe.“ Und zur Architektur: „Zeebe doesn’t rely on a central database, so there’s no performance bottleneck as process volumes increase.“ Die Daten werden über die Broker eines Clusters verteilt, mit Speicherung direkt auf dem Dateisystem des Servers. (docs.camunda.io, Introduction to Zeebe)

Was das für Ihre Anwendung heisst, steht in Camundas Migrationsleitfaden: Die Engine von Camunda 8, Zeebe, ist „always a remote resource for your application“, und der eingebettete Modus wird nicht unterstützt (docs.camunda.io, Conceptual differences).

Aus einer eingebetteten Bibliothek wird damit ein Cluster, den jemand betreiben muss. Camunda begründet mit genau dieser Bauweise die Skalierbarkeit von Zeebe. Für Ihr Team bleibt der Betrieb eine Daueraufgabe, solange die Plattform läuft.

Um die Engine herum hat Camunda 8 weitere Komponenten. Camundas Komponentenübersicht, am 28. Oktober 2026 in der Version 8.10, fasst Zeebe, Operate, Tasklist und Identity zum Orchestration Cluster zusammen und führt daneben Camunda Hub, den Desktop Modeler, die Connectors und Optimize auf (docs.camunda.io, Using Camunda 8). Bei Camunda 7 heissen die Oberflächen Cockpit, Tasklist und Admin. Die Namen sind der schnellste Weg, eine Frage zu beantworten, die als Screenshot kommt.

Woran erkennen Sie, welches Camunda Sie betreiben?

Vier schnelle Prüfungen. Nur für die erste brauchen Sie Zugriff auf Ihren Code.

1. Die Abhängigkeit in Ihrem Build. Steht dort die Gruppe org.camunda.bpm, etwa org.camunda.bpm:camunda-engine, ist es Camunda 7. Steht dort die Gruppe io.camunda, etwa io.camunda:camunda-client-java, ist es Camunda 8 (docs.camunda.io, Java client). Camundas eigener Leitfaden zur Code-Umstellung ordnet das eine dem anderen zu: Importe aus org.camunda.bpm.engine.* werden durch io.camunda.client.* ersetzt (docs.camunda.io, Code conversion).
2. Der Name der Oberfläche. Cockpit bedeutet Camunda 7. Operate bedeutet Camunda 8.
3. Die Dokumentation, die Ihr Team liest. docs.camunda.org enthält das Handbuch von Camunda 7, für die Versionen 7.0 bis 7.24 (docs.camunda.org, Architecture). Die Seiten auf docs.camunda.io tragen im Titel „Camunda 8 Docs“ (docs.camunda.io, Java client).
4. Die Versionsnummer. Alles, was mit 7. beginnt, ist Camunda 7; die letzte Minor-Version ist 7.24. Alles, was mit 8. beginnt, ist Camunda 8.

Den letzten Punkt formuliert Camunda selbst so: „Camunda 7.24 LTS (Long Term Support) is the last minor release of Camunda 7. No new feature-adding releases of Camunda 7 will be built anymore.“ (docs.camunda.org, Support Announcements)

Wenn Sie Camunda 7 betreiben, sind die nächsten Fragen Ihre Minor-Version und Ihre Edition, denn an beiden hängen die Wartungstermine. Die Community Edition endet bei 7.24.0. Auf Maven Central trägt das Artefakt org.camunda.bpm:camunda-engine in der Version 7.24.0 die Beschreibung „7.24.0 is the last community edition release published on Maven Central.“ (Maven Central, camunda-engine 7.24.0) Die Versionsliste des Artefakts führt nach 7.24.0 keine Version mehr (Maven Central, camunda-engine, maven-metadata.xml). Patch-Releases sind laut Camundas Release Policy nur für Enterprise-Kunden verfügbar (docs.camunda.org, Release Policy). Für die Enterprise Edition nennen die Support Announcements den 8. Oktober 2026 als Release-Datum der Patch-Version 7.24.16 (docs.camunda.org, Support Announcements). Im Patch Level Update Guide steht über dem Abschnitt „7.24.16 / 7.23.18 Oct/2026“ ein Abschnitt „7.24.17 Nov/2026“, datiert auf einen Monat, der am 28. Oktober 2026 noch nicht begonnen hat. Einen Tag nennt Camunda für 7.24.17 nicht, und die Support Announcements erwähnen diese Version nicht (docs.camunda.org, Patch Level Update). Die vollständige Matrix je Version steht in Camunda 7: Wartungsende je Version.

Zur Enterprise Edition fasst Camundas Migrationsseite die eigene Position so zusammen: „Camunda 7 Enterprise Edition remains supported through April 2030, but we recommend all new projects be developed on Camunda 8.“ (camunda.com/platform-7/migrate)

Unter welcher Lizenz steht Camunda, und was ist daran kostenlos?

Camunda veröffentlicht für keine kommerzielle Variante einen Preis. Was veröffentlicht ist, sind die Lizenzbedingungen. Für Camunda 7 schreibt die Dokumentation zur Community Edition: „If you are using the community edition, the entire software is provided under various open source licenses (mainly Apache 2.0 and MIT).“ (docs.camunda.org, Licenses) Das Repository camunda/camunda-bpm-platform trägt auf GitHub die Apache-2.0-Lizenz und ist archiviert (GitHub, camunda/camunda-bpm-platform).

Die Camunda 7 Community Edition hat ihr End of Life im Oktober 2025 erreicht. Ihr letztes Feature-Release, 7.24, hatte Camunda für den 14. Oktober 2025 angesetzt. In der Forumsankündigung vom 28. Februar 2025 nennt Camunda den Monat des End of Life der Community Edition und schreibt dazu, dass nach diesem Datum keine weiteren Releases der Community Edition folgen (forum.camunda.io, Camunda 7 Community End of Life clarification).

Für Camunda 8 ist die Lage anders. Der Quelltext von Zeebe, Operate, Tasklist, Identity und Optimize steht unter der Camunda License v1, die kompilierte Software unter einer proprietären Lizenz, und die Dokumentation ist an dieser Stelle unmissverständlich: „To use the software in production, purchase the Camunda Self-Managed Enterprise Edition.“ (docs.camunda.io, Licensing)

Für einen Bestand, der Camunda 7 Community Edition jahrelang kostenlos betrieben hat, ist das die unauffälligste und teuerste Zeile im ganzen Vergleich: Aus einer kostenlosen Bibliothek wird eine lizenzpflichtige Plattform. Wir nennen hier keine Zahl, weil es keine veröffentlichte gibt. Was Camunda zur Preisfrage tatsächlich schreibt, und was die Enterprise Edition für dieses Geld liefert, steht in Camunda 7 weiterbetreiben.

Welche Standards deckt Camunda ab?

Camunda 7 implementiert drei Standards der Object Management Group: BPMN 2.0 für Prozesse, DMN 1.3 für Entscheidungen und CMMN 1.1 für Fallmanagement (docs.camunda.org, Implemented Standards). Der wichtigste davon ist BPMN, und er ist auch der einzige, den Sie kennen müssen, um bei einer Migrationsentscheidung mitreden zu können. Was BPMN ist und was es ausdrücklich nicht ist, steht in Was ist BPMN?. Wie Sie BPMN-Modelle mit Camundas eigenem Werkzeug zeichnen und lesen, zeigt die Camunda Modeler Anleitung. Soll einer Ihrer Prozesse ohne Ihr Zutun laufen, können Sie diesen Prozess automatisieren lassen, der zwei Wochen nach dem Kickoff-Workshop live ist.

Wenn Ihre Antwort Camunda 7 lautet und Sie wissen wollen, was ein Wechsel auf Camunda 8 tatsächlich bedeutet: Camunda 7 vs. Camunda 8 geht die Unterschiede durch, die Camunda selbst dokumentiert.