Context

The overall goal of the feature is to set a variable to the global scope of the migrated process instance so that execution can continue without a further manual intervention like setting variables afterward.

However, there are two ways of achieving this:

• Set the variable before the process instance is migrated (variable is set to the old and migrated to the new process instance)
• Set the variable after the process instance is migrated (variable is set to the new process instance)

To be evaluated design decision: The variable is set before the process instance is migrated

Pros
I can execute my listeners or IO mappings because the variables they require are set before the migration

Cons

• Setting a variable before migration could trigger unwanted execution behavior, e.g., a conditional event listens to this variable and triggers before the migration takes place, which already changes the process instance state based on the old process definition
  • Maybe we can prevent this since it is unwanted execution behavior that shouldn't be triggered during a user operation
• The main use-case is to make process instances work after the migration since the data model between the process definitions is different and not to make IO Mappings and listeners succeed

To be evaluated design decision: I can configure whether a variable is set before or after the process instance is migrated

Pros

• The feature is more powerful
• If the use-case becomes more pressing, we already have a nice API and don't need to wrangle distinguishing setting a variable before or after in the already existing API

Cons

• We have no proof that users actually want to set the variable before migrating the process instance
• Extra effort in implementing (preventing state change of process instance when setting a variable before process instance migration), writing tests, and documenting the feature
• Users might wonder which way of setting the variable is the best one => might lead to confusion

Reasoning & Design Decision

The use-case for setting variables before the process instance migration might be a bit artificial. We don't know if users would benefit from it, which does not really justify the extra effort. Also, I currently cannot oversee the problems that might emerge revolving around triggering unwanted execution behavior when setting a variable before process instance migration. If required, we can still add a flag in the future to control whether variables are set before or after the process instance migration, which might result in a slightly less user-friendly but acceptable API.