To help better understand the snapshot and process instance migration, this overview
shows the involved actions and behaviors.
Migration tasks are performed in the following order during snapshot and instance migration.
Snapshot data migration
While snapshot data is migrated, various settings are migrated from the source snapshot to the
destination. These actions are all performed as one transaction. The data for EPV, environment
variables (ENVs), and teams is migrated depending on the following behaviors. After migration, the
source snapshot is deactivated and the target snapshot is activated. If the source snapshot was the
default, that property is also transferred to the target.
EPV data migration
Runtime EPV changes are migrated from the source snapshot to the target snapshot. An entry is
added for each effective date and value pair. Default values set at design time are not migrated.
For more information about EPV management, see
Managing exposed process values (EPVs).
Note: If the
<epv-deploy-default> property is set to true, a runtime EPV change is
applied to each EPV during deployment with an effective date of the deployment time and a value
equal to the EPV's default value.
Environment variable migration
Runtime environment variable and server configuration settings are migrated from the source to
the target snapshot. Default values set at design time are not migrated. The changes to the
environment variable or server configuration that occur during run time are migrated from the source
if they have a modified date that is more recent than any change that occurred at run time in the
target snapshot. A change at run time always overrides the snapshot default settings.
Team migration
The contents of teams from the source are merged with the teams in the target. Any users or
groups listed for a team from the source snapshot are added to the team in the target. Dynamic teams
cannot be migrated.
Note: If the <disable-team-sync> property is set to true,
teams are not migrated.
Process instance migration
Process instances with a status of active, failed, or suspended are migrated from the source to
the target snapshot. Each process instance is migrated in its own transaction. Multiple threads
process the instance migration work based on the value of the
<thread-pool-size> setting.
Tip: Do not use the source and
target snapshot processes during migration because doing so could lead to lock contention and
failures.
Tasks are migrated depending on the
<migrate-tasks> and
<defer-ec> settings. Depending on the
<migrate-tasks> setting, all task, all tasks except closed ones, or no tasks
are migrated. By default, all tasks except closed ones are migrated. When the task is migrated,
references to source snapshot objects are updated to target snapshot objects. If
<defer-ec> is false, the task execution context is loaded and migrated to
the target environment. If objects are missing from the source snapshot, migration failures might
occur when the execution context is loaded. If task or execution context migration is skipped,
migration occurs the next time the task runs. Business object definition version references are not
updated in the task execution context.
Note: If tasks are not migrated, deleting snapshots those
tasks refer to is prevented. Certain deprecated task assignment methods lead to dynamic teams which
cannot be migrated from the source snapshot. These tasks will block the original snapshot's deletion
until they are deleted.
If a token policy file is used, you can move or delete tokens
associated with an orphaned activity during the instance migration. Some token migration failures
will not prevent instance migration. If this occurs, you can perform the token commands after the
instance migration is completed. If all tokens for a process are deleted, the process moves to the
completed state. The Process Inspector in the Process Admin Console shows orphaned tokens if any
were created from instance migration.