Process instance migration is a very important feature of long running BPM workflows. I thought kogito would automatically migrate the instances when the new version of the process is deployed. But from Alex's answer, it looks like Apache Kogito did not have this feature inbuilt. And then Enrique's answer is confusing. Are we going to have the PIM feature in the upcoming Apache Kogito release or not?
We are planning to move from jBPM to Kogito and I know we have to terminate the existing process instances in jBPM and restart new instances in Kogito. Having said that 1) Does the current jBPM database is compatible with Kogito? Or should we discard the jBPM database completely and go with a new database? The reason I am asking this question is because we need to maintain at least the process instance diagrams of the completed processes for auditing purposes. 2) Do we have any migration plans or some sort of documentation/guidelines to move from jBPM to Kogito? Also, do we have any examples or the documentation for migration plans from open source jBPM to Kogito? I know I have to terminate the existing process instances in jBPM and restart new instances in Kogito. Should the existing jBPM DB work or we should forget On Wed, Mar 25, 2026 at 6:31 AM Enrique Gonzalez Martinez < [email protected]> wrote: > Hi Alex, > There is an example how to migrate inflight processes right here: > > > https://github.com/kiegroup/kogito-examples/tree/main/kogito-quarkus-examples/process-instance-migration-quarkus > > This is file based approach > > Cheers :) > > El mar, 24 mar 2026 a las 23:08, Alex Porcelli (<[email protected]>) > escribió: > > > > Hi Parthasarathy, > > Great questions! So, as of now, the approach is to treat every in-flight > > process instance as attached to the version of the process it was started > > with until it finishes. You'd version your processes using side-by-side > > versioning, similar to how you version APIs (e.g., /v1/ and /v2/). > > There is some work on in-flight migration here: > > > https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/jbpm/jbpm-flow-migration > , > > and probably elsewhere too, but honestly, there's nothing in the open > > source community that fully leverages it yet. I believe one of the > > downstream commercial distributions from IBM might have something to do > > with this. If commercial is an option for you, worth checking out: > > https://kie.apache.org/docs/community/commercial-support > > About documentation contributions, yes, please! Pull requests are very > > welcome. The docs live in the Apache KIE repositories on GitHub, and > > contributions follow the standard Apache contribution process. Just open > a > > PR, and the community will be happy to review it. We really appreciate > > folks willing to help improve the docs! > > Thanks for reaching out and for your willingness to contribute! > > > > - > > Alex > > > > On Wed, Mar 11, 2026 at 2:48 PM Parth <[email protected] > > > > wrote: > > > > > Hello Kie/Kogito Team, > > > > > > I am currently working with BPMN workflows and had a question regarding > > > handling *in-flight process instances when there is a version update > to the > > > BPMN structure*. > > > > > > Specifically, I would like to understand the recommended approach for > > > managing existing running instances when a new version of the BPMN is > > > deployed. For example: > > > > > > - > > > > > > What happens to the in-flight instances that were started with the > > > previous BPMN version? > > > - > > > > > > Is there a supported approach for migrating them to the new > version, or > > > should they continue using the old version until completion? > > > - > > > > > > Are there any best practices for handling structural changes (e.g., > > > added/removed tasks, changed gateways, or timers)? > > > > > > I tried looking through the official documentation and blogs but > couldn’t > > > find clear guidance on this topic. > > > > > > Additionally, I would also like to know *the process for contributing > to > > > the documentation*. If there is a recommended workflow (for example, > via > > > GitHub pull requests or another contribution process), I would be > happy to > > > help improve the documentation around this area. > > > > > > Any guidance or references would be greatly appreciated. > > > > > > Thank you for your time and support. > > > > > > Best regards, > > > Parthasarathy > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
