Camunda 7: Wartungsende je Version. Community Edition beendet, Enterprise bis April 2030

Camunda 7 wird nicht abgeschaltet. Für die Enterprise Edition endet die Wartung der Version 7.24 LTS im April 2030; danach bietet Camunda gegen Aufpreis und auf Anfrage beim zuständigen Customer Success Manager einen Extended Support bis April 2032 an. Für die Community Edition endete sie im Oktober 2025: Seit dem letzten Release 7.24 vom 14. Oktober 2025 erscheinen dort keine Releases mehr, auch keine Sicherheitspatches.

Der Unterschied zwischen den beiden Editionen ist der ganze Punkt, und die meiste Verwirrung entsteht, weil er weggelassen wird. Camunda schreibt auf der eigenen Migrationsseite: „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, geprüft am 28. Oktober 2026.)

Ist Camunda 7 am Ende seines Lebenszyklus?

Für die Community Edition: ja. Für die Enterprise Edition: nein. Wer den Satz ohne Edition schreibt, ist mit einem Klick widerlegt.

Camunda hat am 28. Februar 2025 angekündigt, das End of Life der Camunda 7 Enterprise Edition zu verlängern (Camunda-Blog). Im Wortlaut: „To give our customers greater flexibility in migrating to Camunda 8, we are extending the Camunda 7 Enterprise Edition EoL from April 2027 to April 2030.“ Für die Community Edition änderte sich an diesem Tag nichts. Im selben Beitrag steht: „The EoL date for Camunda 7 Community Edition has not changed.“

Praktisch heisst das zweierlei. Wer eine bezahlte Enterprise-Subscription hat und auf 7.24 LTS steht, hat bis April 2030 Wartung und danach eine kostenpflichtige Option auf Anfrage. Wer die Community Edition betreibt, bekommt seit dem 14. Oktober 2025 nichts mehr: keinen Bugfix, keinen Sicherheitspatch. Das Repository der Community Edition wurde im November 2025 archiviert (geprüft am 28. Oktober 2026), und das Artefakt org.camunda.bpm:camunda-engine:7.24.0 auf Maven Central trägt den Hinweis: „7.24.0 is the last community edition release published on Maven Central. This library will not receive any new versions or releases.“

Ein Beispiel mit Datum: Am 15. September 2026 hat Camunda die Security Notice 168 zu Camunda 7 veröffentlicht, zur Schwachstelle CVE-2026-64607. Unter „How to determine if the installation is affected“ steht: „You use the following Camunda 7 versions or lower: 7.24.14.“ Als Release mit der Korrektur nennt die Notice „Camunda 7: 7.24.15.“ Einen Schweregrad gibt sie nicht an. In der US-Schwachstellendatenbank NVD steht für die Schwachstelle eine CVSS-3.1-Bewertung von CISA-ADP: 5.3 (MEDIUM), in den NVD-Daten als Sekundärbewertung („Secondary“) gekennzeichnet. Eine eigene Bewertung der NVD gibt es nicht. Die Korrektur steckt in einem Patch-Release, und Patch-Releases sind laut Camundas Release Policy nur für Enterprise-Kunden verfügbar. Aus der Versionsangabe der Notice, der Release Policy und dem Stand auf Maven Central, wo die Community Edition bei 7.24.0 endet, schliessen wir (Camunda schreibt das so nirgends): Eine Installation der Community Edition auf 7.24.0 fällt unter die Versionsangabe der Notice, und Camunda liefert ihr diese Korrektur nicht. Die Seite mit den Security Notices schreibt allgemein: „Fixes are available as patches to the enterprise platform and alpha or minor releases of the community platform.“ Ein solches Release der Community Edition ist nach 7.24.0 nicht erschienen (alles geprüft am 28. Oktober 2026).

Nichts davon heisst, dass die Software aufhört zu laufen. Camunda definiert End of Maintenance eng; von erlöschenden Lizenzen ist in dieser Definition keine Rede. Wenn Ihnen jemand erzählt, Ihre Prozesse blieben an einem Stichtag stehen, ist das falsch.

Welche Camunda-7-Version erreicht wann das Wartungsende?

So steht es auf der Support-Announcements-Seite von Camunda (docs.camunda.org/enterprise/announcement). Die Release-Daten sind dort als „scheduled for“ formuliert; Camunda nennt also das geplante Datum. Ob die Veröffentlichung an diesem Tag stattfand, sagt die Seite nicht. Beim Wartungsende steht dieser Vorbehalt nicht.

Ein Enterprise-Vertrag verlängert die einzelnen Minor-Versionen nicht. Nur 7.24 LTS läuft bis 2030. Jede ältere 7.x-Linie hat ihren eigenen Termin nach Camundas Standard-Supportzeitraum von 18 Monaten („The announced end of maintenance dates are based on our standard support period of 18 months.“); 7.24 LTS ist mit rund viereinhalb Jahren die Ausnahme von dieser Regel. Wer mit Subscription auf 7.23 oder 7.22 steht, bekommt für diese Version keine Patches mehr. Der von Camunda vorgesehene Weg zurück in die Wartung ist ein Versionsupgrade auf 7.24 LTS innerhalb von Camunda 7. Der Supportvertrag endet dabei nicht: Camunda schreibt, Support sei bis April 2030 Teil der Subscription.

Was bedeutet „End of Maintenance“ bei Camunda genau?

Camunda definiert es selbst, auf derselben Seite: „End of maintenance means that Camunda will not perform any maintenance or release any bug fixes and patch releases related to the mentioned version after the specified date.“

Mehr steht dort nicht, und das ist die wichtigste Auslassung im ganzen Thema. Die Definition sagt nicht, dass Camunda 7 aufhört zu funktionieren, dass Lizenzen erlöschen, dass Binaries zurückgezogen werden oder dass der Zugang zur Dokumentation entfällt. Was endet, ist die Lieferung von Bugfixes und Patch-Releases für die genannte Version.

Der Unterschied entscheidet, ob Sie ein Sicherheits- und Betriebsthema haben (das haben Sie, sobald niemand mehr Patches liefert) oder ein Abschaltdatum, das Sie nicht haben.

Was hat Camunda wann angekündigt?

Die Ankündigungen verteilen sich über zweieinhalb Jahre, und mehrere Originalbeiträge wurden nachträglich überarbeitet, ohne dass sich das sichtbare Datum geändert hat. Deshalb hier die Reihenfolge mit dem jeweils massgeblichen Stand.

Zwei Fallen in dieser Liste. Erstens zeigt der Forenbeitrag von 2024 weiterhin sein ursprüngliches Datum, wurde aber im Juli 2025 überarbeitet; der Text, den Sie dort heute lesen, ist nicht der Text von 2024. Zweitens stammt der zweite Forenthread vom selben Tag wie der Blogbeitrag. Das Mai-Datum, das die Seite anzeigt, gehört zum automatischen Schliessungshinweis. Wer daraus „Camunda hat das Monate später noch einmal bestätigt“ macht, zitiert eine Systemmeldung.

Warum steht auf vielen Seiten noch ein Endtermin aus dem Jahr 2027?

Weil er einmal richtig war. Bis zum 28. Februar 2025 galt für die Enterprise Edition ein früherer Termin, und Camunda hat ihn an diesem Tag ersetzt. Der Satz, der ihn ersetzt hat, steht oben im Wortlaut und nennt beide Daten in einem Zug, den alten und den neuen.

Wer eine Seite vor diesem Datum geschrieben und seither nicht angefasst hat, führt den alten Termin weiter. Das sind erstaunlich viele, auch unter den Ergebnissen, die im deutschsprachigen Raum zu Camunda weit oben stehen. Wir nennen hier niemanden. Ein veralteter Termin auf einer Beratungsseite lässt sich in einer Zeile korrigieren; dahinter steckt kein böser Wille.

Eine zweite Quelle der Verwirrung steht auf Camundas eigener Seite. Für Cawemo On-Premises, ein anderes Produkt, ist dort ein eigener Termin im selben Jahr verzeichnet. Wer die Seite überfliegt, nimmt leicht den falschen mit.

Die belastbare Prüfung dauert zwanzig Sekunden: Öffnen Sie docs.camunda.org/enterprise/announcement, suchen Sie die Überschrift Ihrer Version und lesen Sie die Zeile „End of Maintenance“. Was dort steht, gilt. Alles andere, auch dieser Artikel, ist eine Wiedergabe.

Warum nennt Camunda selbst zwei verschiedene Tage im April 2030?

Weil die beiden Quellen nicht übereinstimmen, und wir halten es für richtiger, das zu sagen, als uns einen Tag auszusuchen. Die Dokumentation nennt für Camunda 7.24 LTS „End of Maintenance: 13th of April 2030 (Extended Support until April 2032)“. Der Blogbeitrag vom 28. Februar 2025 nennt für das End of Life der Enterprise Edition „New EoL Date: April 9, 2030“.

Es können zwei verschiedene Dinge sein: ein editionsweites End of Life gegenüber dem Wartungsende einer einzelnen Minor-Version. Camunda hat die beiden Angaben nirgends miteinander in Beziehung gesetzt. Für Ihre Planung ist der Unterschied bedeutungslos. An ihm zeigt sich, wie genau jemand seine Quelle liest. Wir schreiben deshalb überall „April 2030“ ohne Tag, und wo ein Tag steht, steht er nur in Camundas eigenem Wortlaut.

Ebenfalls mit Vorbehalt zu lesen ist der Extended Support. Er ist laut Camunda kostenpflichtig und läuft von April 2030 bis April 2032, und die Dokumentation ergänzt: „If you require Camunda Extended Support, contact your assigned Customer Success Manager.“ Ein Anspruch darauf ist an keiner Stelle zugesichert, und einen Preis veröffentlicht Camunda nicht.

Wohin können Sie migrieren, und was spricht jeweils dagegen?

Fünf Ziele sind ernsthaft belegbar. Für jedes gibt es einen dokumentierten Camunda-7-Pfad oder eine dokumentierte Begründung, warum es keinen gibt. Die Spalte, die zählt, ist die letzte.

Der Satz, der die meisten Projektpläne verändert, steht in Camundas eigener Migrationsanleitung (Camunda 7 to Camunda 8 migration guide): „It is important to understand that Camunda 8 is not a drop-in replacement for Camunda 7.“ Und zur Architektur, eine Seite weiter (Conceptual differences): „the workflow engine in Camunda 8, Zeebe, is always a remote resource for your application, while the embedded engine mode is not supported.“ Wenn Ihre Anwendung die Engine als Java-Bibliothek eingebettet hat und sich eine Transaktion mit ihr teilt, ist der Wechsel ein Umbau Ihrer Anwendung.

Und, weil es selten zitiert wird, obwohl es von Camunda selbst stammt (Migration-ready solutions): „Those hacks are the real showstoppers for migration, as they cannot be migrated to Camunda 8.“ Gemeint sind Casts auf Implementierungsklassen, ThreadLocals und Spring-Beans hinter JUEL-Ausdrücken, also genau das, was eine eingebettete Engine über zehn Jahre möglich gemacht hat.

Was hat sich im Oktober 2026 geändert?

Zwei Dinge, und sie haben verschiedene Termine. Im Oktober 2026 hat Camunda 7.23 das Wartungsende erreicht. Seitdem ist 7.24 LTS die einzige Linie der Camunda 7 Enterprise Edition, die noch in Wartung ist. Das ist der ganze Effekt dieses Datums, und er ist kleiner, als er klingt: Für einen Enterprise-Bestand auf 7.23 ist die von Camunda vorgesehene Antwort ein Versionsupgrade auf 7.24 LTS.

Das zweite ist das Environment Update Release für 7.24 LTS in der Enterprise Edition, das Camunda zunächst nur mit dem Monat angekündigt hatte. Sein Block auf der Support-Announcements-Seite nennt jetzt „Release Date: October 8th, 2026“ und „Patch Version: 7.24.16“; Version 7.24.16 ist ein Patch-Release, und Patch-Releases sind laut Camundas Release Policy nur für Enterprise-Kunden verfügbar. Für Enterprise-Installationen nennt der Block fünf Umgebungen, deren Support endet:

• Java 11 („End of Support Java 11“)
• Quarkus 3.33 LTS („End of Support Quarkus 3.33 LTS“)
• Spring 6 („End of Support Spring 6“)
• Spring Boot 3.5 („End of Support Spring Boot 3.5“)
• MariaDB 10.6 („End of Support MariaDB 10.6“)

Läuft Ihr Bestand auf einer dieser Umgebungen, war das Environment Update der Termin mit tatsächlichen Folgen für Sie. Läuft er auf keiner davon, hat dieses Update für Sie nichts geändert. In dieselbe Liste schreibt Camunda unter anderem Java 25, Spring Boot 4.1, PostgreSQL 19 und den WildFly Application Server 41. Java 25 und Spring Boot 4.1 hat Camunda dabei schon vorher ausgeliefert: Laut eigenem Patch Level Update Guide kam die Java-25-Kompatibilität mit dem Enterprise-Patch-Release 7.24.9, und mit dem Enterprise-Patch-Release 7.24.10 wurden Camunda Run und der Camunda Spring Boot Starter auf Spring Boot 4.1.0 umgestellt; Java 25 steht in der Umgebungsliste für 7.24 heute schon. Patch-Releases sind laut Camundas Release Policy nur für Enterprise-Kunden verfügbar und laut Patch Level Update Guide in der Community Edition nicht. Unter Camundas Zeile „Support for PostgreSQL 19“ steht als Unterpunkt „Delivery might be pushed into November if released too late“; das Update selbst hat Camunda am 8. Oktober 2026 als Enterprise-Patch-Release 7.24.16 ausgeliefert, und die Umgebungsliste für 7.24 nennt PostgreSQL 15, 16, 17 und 18, noch nicht 19. Was dieses Update im Einzelnen ändert, geht Camunda 7: Java 25 kam mit Enterprise-Patch 7.24.9 durch.

Was wir verkaufen, und warum dieser Artikel dagegen argumentiert

Peak Code Consulting verkauft Camunda-7-Migrationen. Lesen Sie das Folgende in diesem Wissen.

Der ehrlichste Satz in diesem Artikel arbeitet gegen dieses Geschäft: Für einen Enterprise-Bestand auf 7.24 LTS gibt es bis April 2030 keinen Termin, der eine Migration erzwingt. Camunda liefert für die Enterprise Edition weiter Patches, zertifiziert weiter neue Umgebungen und sagt selbst, Camunda 7 Enterprise bleibe bis April 2030 unterstützt. Wer Ihnen für diesen Fall Dringlichkeit verkauft, verkauft Ihnen ein Datum, das es nicht gibt.

Zwei Fälle sehen anders aus, und beide stellen Sie an Ihrem eigenen Bestand fest. Erstens: Sie betreiben die Community Edition; dann bekommen Sie seit Oktober 2025 keine Sicherheitspatches mehr. Zweitens: Sie stehen auf einer Version unterhalb von 7.24; dann liefert Camunda für Ihre Version schon heute nichts mehr. Beides beschreibt einen Zustand, der bereits besteht.

Wir haben in diesem Artikel bewusst keine Angabe zu Aufwand, Dauer oder Kosten einer Migration gemacht. Die hier zitierten Camunda-Quellen nennen dazu für eine ganze Migration keine Zahl, und wir veröffentlichen keine Zahl, die wir nicht belegen können.

Neben Migrationen automatisieren wir einzelne Prozesse: Sie können einen Prozess automatisieren lassen, der danach ohne Ihr Zutun läuft.

Zwei Artikel gehen die Fragen weiter, die hier nur gestreift werden: Was ist Camunda? klärt, welches der beiden Produkte bei Ihnen läuft, und Camunda 7 vs. Camunda 8 geht durch, was ein Wechsel technisch bedeutet.

Wenn Sie lieber zuerst selbst lesen: Das Handbuch Der Camunda PATH geht dieselbe Entscheidung auf 87 Seiten durch, mit fünf tragfähigen Wegen und dreizehn Kandidaten, die darin ausdrücklich ausgeschlossen werden.