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] > > > > >
