The migration tool in EPX provides users with a way to move data from one EPX system to another. If the objects (i.e., users, groups, roles, etc.) being migrated already exist in the system, most of them will be overwritten. However, in the case of process flows, a new flow will be created with “-migrated” appended to the original flow name. Now, users have a way to transfer all the work items from one process flow to another.
Work items can be transferred from a process flow, or from a subflow and are described either as a source flow or a target flow. If a source flow contains a subflow activity that is mapped to a subflow activity in the target flow where the subflows are different, the work item versions that are in the source subflow will have to be transferred to the target subflow in a separate operation from the main flow transfer.
If some of the activities from the source flow have not been mapped to target activities, the transfer utility will create a hidden activity in the target flow where these unmapped work item versions can be placed so that they are not lost. Only work item versions that are not current will be placed in the hidden activity. The hidden activity name will be deleted_activity, and the activity will be marked as deleted so that it will not appear in the Design Console for the flow. Any work item version that is placed in this hidden activity will also be marked as deleted.
If the actor at a target activity is different than the actor at the corresponding source activity, the actor will be changed to the target activity’s actor for work item versions that are current at the target activity. If the actor has been changed to a dynamic actor role or to a selection role, the work item will not be transferred. If the actor has been changed from one automatic activity to another, the BIC manager will need to be restarted in order to recognize the change.
If the work item contains a work item version in the process flow or subflow that is current and is at an activity that has not had a target activity mapped, the work item will not be transferred.
If an error occurs during transfer, everything is rolled back and none of the changes are committed to the database. A log file is created on the server with the name witransfer_timestamp.log where timestamp is the time that the transfer began.
Note: Before transferring work items, it is recommended that the tomcat services be stopped so that no work occurs during work item transfer. If this is not an option in production, the BICs should be disabled temporarily and then enabled after the transfer.
After work items have been transferred, the Process flows need to be renamed and the old flow’s starting points disabled.