Migration von Camunda 7 auf 8
Wir planen und führen Migrationen von Camunda 7 auf 8 durch. Wir erfassen Ihre Modelle, Ihren Delegate-Code, Ihre Ausdrücke und Ihre laufenden Instanzen. JavaDelegates werden zu Job Workern, JUEL-Ausdrücke werden zu FEEL, und laufende Instanzen ziehen mit dem Data Migrator um oder laufen auf Camunda 7 zu Ende. Auch der Verbleib auf Camunda 7 Enterprise bis April 2030 ist eine Option.
Die Aufgabe.
Die Camunda 7 Community Edition hat im Oktober 2025 ihr End of Life erreicht, ihr letztes Release ist 7.24. Der Support für Camunda 7 Enterprise endet im April 2030. Sie haben drei Wege, und jeder hat seinen Preis.
Eine Migration ändert mehr als die Engine. Camunda 7 ruft Ihren Java-Code innerhalb seiner eigenen Transaktion auf. Camunda 8 übergibt die Arbeit an Job Worker außerhalb der Engine. Modelle, Code, Ausdrücke und Daten brauchen jeweils einen Plan.
Was wir tun.
Bestandsaufnahme
Wir erfassen jedes Modell, jeden JavaDelegate, jeden Listener, jeden Ausdruck und jede laufende Instanz. Sie sehen, was sich direkt umwandeln lässt und was neuen Code braucht.
Der Weg
Camunda 8, Camunda 7 Enterprise bis April 2030 oder ein Community-Fork wie Operaton oder CIB seven. Camunda 8 Self-Managed braucht im Produktivbetrieb eine Lizenz, daher gehört die Lizenz zur Entscheidung.
Von JavaDelegates zu Job Workern
Jeder Delegate wird zu einem Job Worker mit eigenem Job-Typ. Logik, die sich auf die Transaktion der Engine verlassen hat, bekommt ein neues Design.
Von JUEL zu FEEL
Ausdrücke in Gateways, Ein- und Ausgaben wechseln von JUEL zu FEEL. Wir testen jeden umgewandelten Ausdruck gegen Ihre Daten.
Laufende Instanzen
Laufende Instanzen können auf Camunda 7 zu Ende laufen, während neue auf Camunda 8 starten. Oder der Data Migrator von Camunda überträgt sie, zuerst auf einer Kopie getestet.
Umstellung (Cutover)
Den Ansatz für die Umstellung wählen wir mit Ihnen, Prozess für Prozess. Jede Umschaltung hat einen Termin, einen Test und eine Rückfallebene.
Aus einem JavaDelegate wird ein Job Worker
// Camunda 7: the engine calls the delegate inside its own transaction
-public class CheckCredit implements JavaDelegate {
- @Override
- public void execute(DelegateExecution execution) {
- String customerId = (String) execution.getVariable("customerId");
- execution.setVariable("approved", creditService.check(customerId));
- }
-}
// Camunda 8: a job worker fetches the job and completes it
+@JobWorker(type = "check-credit")
+public Map<String, Object> checkCredit(@Variable String customerId) {
+ return Map.of("approved", creditService.check(customerId));
+}Scrollen Sie den Code seitlich, um jede Zeile zu lesen.
Schematisch. In Camunda 7 ruft die Engine den Delegate innerhalb ihrer eigenen Transaktion auf. In Camunda 8 holt ein Worker den Job ab, erledigt die Arbeit außerhalb der Engine und schließt den Job mit den zurückgegebenen Variablen ab (die Annotation @JobWorker des Camunda Spring Boot Starters). Im Modell wird aus der Delegate-Referenz ein Job-Typ.
Typische Projekte.
Migrationsbewertung
Wir erfassen Ihre Modelle, Ihren Code, Ihre Ausdrücke und Ihre laufenden Instanzen. Sie erhalten eine schriftliche Bewertung, die die drei Wege vergleicht.
Migration Prozess für Prozess
Es zieht jeweils ein Prozess um, getestet auf einer Kopie. Die anderen bleiben auf Camunda 7, bis sie an der Reihe sind.
Migration mit Ihrem Team
Wir migrieren die ersten Prozesse gemeinsam mit Ihren Ingenieuren. Ihr Team migriert den Rest, mit unserem Review.
Passt das zu Ihnen?
Passt gut
- Sie haben Camunda 7 im Produktivbetrieb, als Community oder Enterprise Edition.
- Ihr Java-Team verantwortet die Job Worker nach der Migration.
- Sie möchten den Weg auf Basis einer Bestandsaufnahme wählen, nicht auf Basis einer Vermutung.
Passt nicht
- Sie erwarten eine Migration ohne Änderung an Ihrem Java-Code.
- Sie suchen Personalgestellung, ohne technische Leitung auf Ihrer Seite.
- Sie suchen den Weiterverkauf von Lizenzen, ohne Migrationsarbeit.
Versionen und Termine.
Aus den veröffentlichten Seiten der Hersteller, geprüft am 19. Oktober 2026.
Das aktuelle Release von Camunda 8 ist 8.10; das letzte Release der Camunda 7 Community Edition ist 7.24.
Diese Termine beenden den Support des Herstellers, nicht die Software.
Nächster
13. April 2027
Camunda 8.8
Der Standard-Support für Camunda 8.8 endet.
April 2030
Camunda 7
Der Support für Camunda 7 Enterprise endet; kostenpflichtiger erweiterter Support bis April 2032.
Oktober 2025 Beendet
Die Camunda 7 Community Edition hat ihr End of Life erreicht; das letzte Release ist 7.24.
Fragen.
Können Sie uns von Camunda 7 auf Camunda 8 migrieren?
Ja, wir planen und führen Migrationen von Camunda 7 auf 8 durch. Wir beginnen mit einer Bestandsaufnahme der Modelle, des Delegate-Codes, der Ausdrücke und der laufenden Instanzen. JavaDelegates werden zu Job Workern, und JUEL-Ausdrücke werden zu FEEL. Auch der Verbleib auf Camunda 7 Enterprise bis April 2030 ist eine Option. Den Ansatz für die Umstellung wählen wir mit Ihnen.
Müssen wir Camunda 7 jetzt verlassen?
Sie müssen Camunda 7 nicht sofort verlassen: Der Support für Camunda 7 Enterprise läuft bis April 2030, mit kostenpflichtigem erweitertem Support bis April 2032. Die Camunda 7 Community Edition hat im Oktober 2025 ihr End of Life erreicht, mit 7.24 als letztem Release. Ein Community-Fork wie Operaton oder CIB seven ist ein dritter Weg.
Was passiert mit unseren laufenden Prozessinstanzen?
Laufende Instanzen laufen entweder auf Camunda 7 zu Ende oder ziehen mit dem Data Migrator von Camunda auf Camunda 8 um. Wir entscheiden pro Prozess, je nachdem, wie lange seine Instanzen leben.
Wie wird aus JUEL FEEL?
Jeder JUEL-Ausdruck in einem Gateway, einer Eingabe oder einer Ausgabe wird in FEEL neu geschrieben, der Ausdruckssprache von Camunda 8. Einfache Vergleiche lassen sich direkt umwandeln. Ausdrücke, die Java Beans aufrufen, brauchen ein neues Design, oft einen Job Worker.
Auf welcher Version sind Sie?
Nennen Sie uns die Plattform, die Version und was sich ändern muss. Wir antworten mit Fragen oder einem Vorschlag für den nächsten Schritt.
Ihre Migration planen