Migrate 500+ faulty instances

Assuming I’ve deployed a process definition and over 500 instances are currently utilizing it, what steps can I take to rectify a critical modeling error and migrate all affected instances to an updated version that includes a necessary hotfix?

I already found a community repo that can possibly provide this. Is this the way to go? GitHub - camunda-community-hub/camunda-7-migration: Fluent Java API for Camunda Platform 7 process instance migration

Best regards,

Thomas

Hi @Th0mas,

process instance migration from one version to another is part of the product. You can use the asynchronous batch migration for the numbers of process instances you have to migrate: Process Instance Migration | docs.camunda.org.

This is the REST Api endpoint to execute the migration: Camunda Platform REST API

Hope this helps, Ingo

1 Like

@Ingo_Richtsmeier is it also possible to redetermine the input for a service task (when migrating)? I’ve got serveral faulty instances stuck at a service task with missing local variables. I’ve fixed the model and would really like camunda to redetermine the input and than start the service task. When I try this using the migration API the input variables remain unchanged. I’ve tried with skipIoMappings false (and true). Adding the variables in the migration plan is not an option since they are instance specific. I’ve also tried migration to an edge or event just before the service tasks, that also seems no opion.

Hi @Ronald1,

I think the local variables are only created, when they come from an input mapping and you set skipIoMappings to false.

If the local variables are created from delegates or external task workers (they already exist when you migrate), you don’t have a chance to change the values with the migration.

Hope this helps, Ingo

External task workers are used. I the example a missing asynchronious continuation caused missing input variables. I think the easiest way to redetermine the input mapping is going to be to add a dummy activity with zero input which always succeeds which goes to the activity for which the inputs have to be recreated. We could use the migration API to migrate the faulty instances to the dummy activity and start from there to fix the inputs.