Guidance on backward compatibility of persisted process instances after BPMN/model changes (Kogito 10.2, Spring Boot, JDBC)

21 views
Skip to first unread message

Carlos Santos

unread,
Sep 2, 2026, 9:07:18 AM (3 days ago) Sep 2
to Kogito development mailing list
Hi everyone,

We run a Spring Boot 3.5 / Java 21 application with Kogito 10.2.0 and kie-addons-springboot-persistence-jdbc on PostgreSQL. Our main BPMN contains long-running user tasks, call activities, and Java-typed process variables.
After some BPMN/data-model changes, previously persisted active instances could no longer be loaded, failing with an unmarshalling/process-instance marshalling exception.
Could you help clarify the supported compatibility and migration model in Kogito 10.2?
  • Which BPMN changes are expected to be backward compatible: adding/removing/renaming variables, changing Java variable types/classes, and adding/removing/renaming nodes while preserving or changing node unique IDs?
  • Does JDBC persistence deserialize an old instance against the currently loaded process definition? Which incompatibilities commonly cause ProcessInstanceMarshallerException?
  • Is the Spring Boot process-instance-migration addon recommended for moving active instances between versions? Does it migrate node mappings only, or can it transform process variables?
Any recommended migration protocol, known limitations, or Kogito 10.2 references would be very helpful?

Given that we frequently make changes to the BPMN models, I would like to know if there is an established process or solution for handling this incompatibility.

Jozef Marko

unread,
Sep 3, 2026, 11:55:15 PM (2 days ago) Sep 3
to kogito-de...@googlegroups.com
Hi, to my knowledge, the process-instance-migration (PIM) addon is the recommended tool for moving active process instances. However I think its main purpose was to address differences in the active nodes. By default it tries to map old active node instance to a new node instance that has the same name, type and id in the BPMN definition file. If the old node and the new node differ in these parameters, the user can provide an explicit mapping of nodes.

I think the PIM does not migrate variables in an advanced way. I think it only tries to create copies of old variables and for new variables it initializes them with en empty value.

--
You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kogito-development/3154c93c-326f-4853-9621-1de77c06473cn%40googlegroups.com.


--
Regards, Jozef
Red Hat Partner Engineer
Reply all
Reply to author
Forward
0 new messages