Migrer de Camunda 7 à 8, un processus à la fois
4 min de lecture · Mis à jour le 11 nov. 2026
Camunda 8 n'est pas une mise à jour de Camunda 7 mais un nouveau moteur. Ce qui change, ce qu'il faut réécrire, et comment migrer sans bascule en une seule fois.
Une migration, pas une mise à jour
Camunda 7 tourne comme une bibliothèque dans votre application Java, ou comme un moteur partagé à côté. Votre code de processus (Java delegates, listeners, scripts) s'exécute dans le même processus que le moteur et écrit dans la même base de données.
Camunda 8 est construit autrement. Le moteur de workflow, Zeebe, tourne dans son propre cluster. Votre code ne s'exécute plus dans le moteur : il tourne dans des job workers qui demandent du travail au moteur par le réseau et lui renvoient le résultat. Operate, Tasklist et les autres outils de Camunda 8 lisent ce cluster, pas votre base de données.
C'est ce qui permet à Camunda 8 de passer à l'échelle, mais un projet Camunda 7 ne peut pas simplement être pointé vers une nouvelle version. Certaines parties se déplacent telles quelles, d'autres s'adaptent, d'autres se reconstruisent.
Ce qui change, élément par élément
| Camunda 7 | Camunda 8 | Ce que cela implique |
|---|---|---|
| Diagrammes BPMN | Diagrammes BPMN | Largement réutilisables, attributs propres à Camunda convertis |
| Java delegates et listeners | Job workers | Réécrits en workers qui tournent hors du moteur |
| Expressions JUEL | Expressions FEEL | Conditions et mappings réécrits en FEEL |
| Formulaires embarqués et générés | Camunda Forms ou vos propres formulaires | Les formulaires HTML embarqués sont à reconstruire |
| Tables de décision DMN | Tables de décision DMN | Se déplacent en général telles quelles |
| Historique du moteur dans votre base | Historique dans le cluster Camunda 8 | L'ancien historique ne suit pas tout seul |
Camunda publie un guide de migration et des outils qui convertissent les diagrammes et signalent ce qui doit changer. Mieux vaut les lancer tôt : ils transforment une inquiétude vague en liste.
Les deux points que les équipes sous-estiment
Les instances en cours. Des dossiers démarrés sur Camunda 7 tournent encore au moment de la bascule. Les choix habituels : les laisser se terminer sur Camunda 7 pendant que les nouveaux dossiers démarrent sur Camunda 8, ou les déplacer avec des outils dédiés. Dans les deux cas, il faut savoir combien il y en a et où ils en sont.
L'historique. Auditeurs, support et responsables de processus doivent encore consulter les dossiers de l'an dernier après la migration. Si Camunda 7 est arrêté, cet historique doit rester lisible quelque part.
Migrer un processus à la fois
Une migration en une seule fois, c'est tout réécrire, tout tester et tout basculer à une date. Cela se passe rarement comme prévu. Une approche plus sûre consiste à déplacer un workflow à la fois :
- Inventorier. Lister chaque workflow, formulaire, table de décision, morceau de code et instance en cours.
- Choisir un premier workflow. Un workflow qui compte, sans être le plus complexe : il vous dira combien de temps prendra le reste.
- Vérifier la cible. S'assurer que le cluster Camunda 8 peut recevoir les déploiements avant de déplacer quoi que ce soit.
- Déplacer et vérifier. Déployer le workflow avec ses formulaires et ses décisions, réécrire ses workers, et y faire passer de vrais dossiers.
- Garder la même expérience pour les utilisateurs. S'ils gardent la même boîte de tâches et les mêmes formulaires, le moteur qui tourne en dessous ne les concerne pas.
- Recommencer, en ne gardant Camunda 7 que pour ce qui n'a pas encore bougé.
Une liste de contrôle avant de commencer
- Quels workflows ont encore des instances en cours, et combien ?
- Quels Java delegates, scripts et expressions demandent un job worker ?
- Quels formulaires sont des formulaires HTML embarqués à reconstruire ?
- Où chercher les dossiers Camunda 7 terminés après la bascule ?
- Qui valide chaque workflow une fois qu'il tourne sur Camunda 8 ?
Dans Bridge
Bridge se connecte à votre Camunda 7 et liste ce qu'il trouve : workflows, formulaires, tables de décision, le code qui demande un job worker, l'historique et les instances encore en cours. Vous cochez les workflows à déplacer ; les formulaires et décisions qu'ils utilisent suivent, et chaque élément figure dans un devis dont le prix est figé à l'envoi de la demande.
Avant tout déplacement, Bridge vérifie que votre cluster Camunda 8 peut recevoir les déploiements. L'exécution déploie ensuite avec une progression en direct et une trace par élément, et les relances des mêmes éléments sont gratuites. Les instances Camunda 7 terminées restent consultables dans une archive historique en lecture seule, et comme la boîte de tâches et les formulaires ne changent pas, les personnes qui font le travail remarquent à peine le changement de moteur.