Migration Point Restrictions

You should be aware of a number of restrictions when designing your process to be sure that it can migrate correctly.

• The task name is used to identify a migration point. This means that all tasks must have names.
  Note: By default, gateways do not have names. This means that you must specify a name for all gateways in your process if you want them to be valid migration points.

  Note that:

  • task names must not be duplicated.
  • task names in source and destination process templates must be the same.
• Migration cannot be performed on pageflow processes. Pageflow processes are short-lived processes whose data is not persisted, therefore migration should not be required.
• For a user task, migration should be set before the user task is scheduled. Migration does not happen if the changes are made after the user task is OFFERED to a user.
• Valid migration points are points of the process template where a single process thread executes. Therefore, a task that starts a parallel path is a valid migration point but any tasks that follow are not until those paths are rejoined.
• Part of a process that does not appear to be a parallel flow may be treated as a parallel flow. A primary example of this is incoming request tasks without inflows and any sort of task boundary event. If the flows out of these tasks are not merged back into the process then everything after that point is treated as a parallel flow. This is because without an explicit merge back into the flow then there is an implicit merge at the end of the process (hence all other activities on those flows are counted as "in-parallel" with the incoming request task).
• Any tasks inside embedded sub processes cannot be migration points, but the embedded sub process itself may be a migration point. See Embedded Sub-Processes. Migration takes place before starting the sub process.
• These events cannot be migration points:
  • start events
  • events placed on the boundaries of tasks.

    See Events.

• Tasks that follow these gateways are not valid migration points:
  • Inclusive
  • Complex
  • Parallel
• Tasks following tasks that have Timer events placed on their boundary with Continue Task on Timeout selected are not valid migration points:
• Tasks following tasks with multiple instance loops with ordering set to Parallel and flow conditions that are set to One are not valid migration points. This is equivalent to an exclusive gateway, and means that only the completion of the first activity instance causes flow to continue.
• BPM Validation Configuration on the Resource properties tab of a process is used to suppress problems markers for the ’No migration point activities in the process’ Problem. It gives you the choice of validation, suppressing the error until the next process flow change, or suppressing the error until a manual reactivation via Resource properties.
• Migration points cannot be set on an event handler flow but it is possible to modify an event handler flow which can then be triggered after a process migration from a migration point set somewhere on the main flow.
• Event handlers are automatically re-initialized during process migration. This means that they will be re-activated using the new values for correlation data.
• When adding an ad-hoc event to a new process version, the initializer for the ad-hoc event must be defined as the migration point or come after the migration point in order for the ad-hoc event to be available after process migration. If the initializer is in a part of the process that has already been executed before migration, the ad-hoc event will not take effect in process instances that have been migrated.
• Migration is delayed with an audit message if the event handler thread is not complete. The migration will complete once all outstanding event handler threads have been completed.
• When you add a new ad-hoc activity, and then upgrade and migrate, you must define an initializer for the activity. This could actually be the migration point itself.