There are two different types if process instance migration. 1. From old versions. From jBPM to kogito. There is no such tool provided in community and i dont think there will ever be.
2. Migration within kogito ecosystem. This is supported and the example link provided works. It does not do things automatically though. That would not make sense. There is no tool for creating the migration plan file. Saludos, Enrique González Martínez :) El vie, 27 mar 2026, 3:04, Alex Porcelli <[email protected]> escribió: > Kogito does not currently provide out-of-the-box tooling for process > instance migration. Some of the building blocks exist, and examples have > been referenced, but putting them together requires custom code or > scripting. Commercial downstream distributions, such as IBM, may provide > more in this area. > > For jBPM to Kogito, there is no direct migration path. This is essentially > a porting/rewrite effort, since the runtime model, components, semantics, > and persistence model are different. > > Regarding the database, jBPM and Kogito use different database models, with > no direct mapping between them. Any similarity would be coincidental. In > practice, you should keep the jBPM database for audit/history purposes if > needed, but use a new database/schema for Kogito. > > I’m also not aware of any official open source end-to-end migration tooling > or documentation from jBPM to Kogito. > - > Alex > > On Thu, Mar 26, 2026 at 9:37 PM Arif Mohammed < > [email protected]> wrote: > > > 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] > > > > > > > > >
