Migration Plan

We implemented a simple migration plan using the rest engine.

After execution, the activities are migrated and this is verified from cockpit processes tab.
However, tasklist is showing the old activity Id after migration.
Why is this?

Migration plan: migration_plan.txt (607 Bytes)

Our BPMN model diagram:

Tasklist after migration:

Thank you.

Hi @davekant,

does the problem occur even if you clean caches?

Cheers,
Askar

I’m pretty sure this is by design - as i recall the the task id is maintained after a migration in order to have as little impact on the user as possible.

e.g. If a user is in the middle of filling out a webform user task and meanwhile in the background the process is migrated, the user can still complete the task as if nothing had changed.

Exactly. I think what tasklist displays there is the name of the task, not the name of the activity the task belongs to. These two things are the same in the default case, but not neccessarily after migration. When a task is created, the name is initialized as the name of the activity it belongs to. Migration does not reinitialize the task, as documented here: Process Instance Migration | docs.camunda.org

Cheers,
Thorben

OK, so one has to take care when implementing business logic based on the Task Name.
For example, if we had a parallel gateway and there were multiple tasks associated with the workflow instance, any logic based on the Task Name post migration may not be executed.

Thanks

Well, yes and no. Migration instructions are supposed to map semantically equivalent activities. That is also why we decided to change as little attributes as possible during migration. Perhaps process instance modification is better suited for that use case, i.e. cancel the Remediation Review activities before migration and start new instances of Approve Request after migration. That said, I understand that modification and migration cannot be easily combined via API, especially when using the batch migration feature.