Hi everyone,
I have a rather simple question: when migrating process instances to a newer version (by using cockpit in the enterprise edition or the java api), is it possible to migrate tokens to a non-wait-state? Or does the target of the migration always have to be a wait state?
Thanks in advance,
Ben
Hi Ben:
While using the Cockpit Migration wizard in the EE version of Cockpit, any attempt to map to an ineligible flow node will show as a “mapping error” in red. It should give you a tooltip showing that it is an “Incompatible Type” as shown here.
I believe that the information that you are looking for is regarding what are allowed mappings for the “migration plan”. This is outlined in our documentation:
https://docs.camunda.org/manual/7.16/user-guide/process-engine/process-instance-migration/
Specifically this part:
"Migration instructions have the purpose to map semantically equivalent activities. In consequence, migration interferes with activity instance state as little as possible which ensures a seamless transition. For example, this means that a migrated user task instance is not re-assigned. From the assignee’s point of view, migration is mostly transparent, so that a task that was started before migration can be completed successfully after migration. The same principle is applied to the other BPMN element types.
For cases in which activities are not semantically equivalent, we recommend combining migration with the process instance modification API, e.g., canceling an activity instance before migration and starting a new instance after migration."
In other words, it has nothing to do with the “wait state”, nor the transaction. It has to do with whether they are “semantically equivalent activities”. Using the Cockpit EE wizard is a nice cheat to find this out quickly.
Hope this help.
Chris
Thank you @tofertek for the conclusive answer 
Quick followup, @tofertek, could you elaborate on what would happen if one would provide a migration plan that does not follow these guidelines, using the java API?