EPX Migration Pitfalls, Limitations, and Workarounds - Precisely_EnterWorks - EnterWorks - 11.0

EnterWorks Guide

Product type
Software
Portfolio
Verify
Product family
EnterWorks
Product
Precisely EnterWorks
Precisely EnterWorks > EnterWorks
Version
11.0
Language
English
Product name
Precisely EnterWorks
Title
EnterWorks Guide
Copyright
2024
First publish date
2007
Last updated
2025-01-07
Published on
2025-01-07T07:44:20.997000

Work Item Types

Work Item Types, which are used to define submission forms must have their internal IDs match in both systems. If the Work Item Types are migrated from one EPX to another, there is no guarantee that their IDs will be the same. Similarly, if work item types are manually created in different orders within the different EPX environments, they will end up with different internal IDs. It would be best if this can be avoided by manually creating work item types in all environments at the same time and in the same order. If the work item types share the same internal IDs, then the workflows that reference them can be migrated without needing to be adjusted manually. If the internal IDs are not the same in each environment, then the incorrect submission form may end up being assigned to manual activities in the target EPX and will require manual correction. A SQL script to auto-correct the Work Item Types is to be supplied. Work item types are not automatically migrated when referenced in manual activities. They must be explicitly selected in the Import/Export migration tool.

Repository IDs

The repository IDs that are assigned to the manual activities are migrated along with the repository names. If the same repositories have different internal IDs in the different EnterWorks environments, the references in the manual activities may be incorrect in the target system. If the different EnterWorks environments are refreshed through database backup/restore, the IDs will be identical, and migration will not be a problem. Otherwise, it will be necessary to either manually check and correct the repository IDs in each manual activity to the appropriate values or run the SQL script that corrects them automatically (recommended).

Migrating Subflows

When migrating subflows, special care is needed since they are linked to process flows and possibly other sublfows. If a subflow is migrated by itself, it is recommended that the old subflow be renamed (with Old) so the new subflow does not collide. Once the new subflow has been migrated, each calling process flow and subflow will need to be edited to point to the new version of the subflow. If the old version of the subflow has any active work items, they must be advanced to exit the subflow before the transition is made. If this is not possible or practical, the steps for migrating process flows and subflows with active work items should be followed and the process flows migrated as well.

Manual Migration

If changes to a workflow or subflow are migrated manually (i.e., the changes are made in the target EPX through Design Console editing), the Compare Extract procedure should be followed to ensure that all changes have been made and exactly match the source EPX.