Although most configuration content can be migrated in most environments, some configuration cannot be migrated. Extra steps are required in some circumstances.
To migrate a WFINITIATE action, which initiates a workflow process, the workflow process must be active. Therefore, two deployments are required. Migrate the workflow process and activate it in the target environment first, and then migrate the action.
To migrate action groups that are created in the Actions application, you must also migrate all the actions that are in each action group. If you do not migrate the actions, the action groups cannot be used in the target environment.
A target environment must have the same base language as the source environment. If the target base language is different from the source base language, packages cannot be deployed.
Migration Manager does not migrate charts of accounts (GLs).
Data restrictions for objects and attributes are migrated, but collection restrictions are only partially migrated. Data in the SECURITYRESTRICT table is migrated. Data in the COLLECTIONAUTH table is not migrated.
In some situations you might need to create and deploy two separate Change packages. For example, consider the following scenario:
You have a security group that has a data restriction, and the data restriction references a condition. You create a package for application security and deploy the package to the target environment. You then remove the condition from the security group in the source environment, and delete the condition. You create a new package for application security and deploy the package to the target environment, but an error occurs.
The error occurs because during deployment, the Migration Manager attempts to delete the condition first.
To avoid this error, you must perform the migration in two steps. First, create a Change package that removes the condition from the security group, and deploy the package to the target environment. Then, create a second change package that deletes the condition, and deploy the second package to the target environment.
To migrate a crossover domain to which an attribute has been added, you must create and deploy two packages. The first package to deploy must contain the attribute but not the domain. The second package to deploy must contain the domain.
In Oracle databases, setting up a system to run with a login user name that is different from the schema owner is a complex manual task and might cause migration errors. To avoid errors, ensure that the system properties mxe.db.user and mxe.db.schemaowner have the same value.
Also for Oracle databases, ensure that the semantics are set to CHAR in all source and target environments. Migrations between environments that have different semantics (CHAR and BYTE) might cause database errors.
For DB2® databases, indexes might not be migrated.
If a package is deployed and an index exists in the target environment, the index in the package is not deployed. If an index does not exist in the target environment, the index is created. If the index in the package is marked to be deleted, the index in the target with the same table and attribute combination is marked to be deleted.
A Change package can listen for database configuration events that occur in the Database Configuration application. Event information (inserts, updates, deletes) are persisted in the event tracking table. If a user discards all the database configuration changes by using the Discard Configuration Changes action, the events that are already captured remain in the tracking table. A migration user might not be aware that the events remain in the tracking table and might proceed to create, distribute, and deploy a package. During deployment, the Database Configuration application can determine that the data provided by the package does not contain changes and does not configure the database. The deployment of such a package does not harm the target environment, but the event tracking entries might be confusing to a user.
If you use the Database Configuration application to enable electronic auditing, the settings that control electronic auditing are migrated. If any electronic auditing tables are created, the tables are only useful for the specific environment. Therefore, any auditing tables and the data they contain are not migrated.
You can migrate exchange rates only if the application servers in the source and target environments are configured to use the same time zone. If the time zones are different, a package might not deploy because of overlapping exchange rate validity periods. You cannot use exchange rates that have overlapping validity periods.
Changes to the Integration module interface tables, default queue tables MXIN_INTER_TRANS and MXOUT_INTER_TRANS, and any customized queue tables are not migrated. If you make any configuration changes in the source database to these tables, you must make the same changes in the target database.
When you migrate lookup maps for new business objects, the migration of a single package that contains both the lookup map records and the business object records fail. The migration fails because the lookup map is processed first and depends upon the business object, which is not processed yet.
To work around this limitation, define two Change packages: one to capture the new business object and another to capture the lookup map. Migrate the business object Change package first.
The source and target environments must define the same MAXVARS. Migration Manager supports the update of existing MAXVARS only.
After deployment of a package, a newly created organization in a target environment is inactive. It is inactive because a newly created organization cannot be activated without a clearing account (GL). The association of a GL account with an organization is a manual post-deployment step.
When a site is created, a default location of type HOLDING is generated. However, a location of type HOLDING cannot be associated with a person record. In order to associate a location with a new person record, you need to change the location type to another status, such as OPERATING.
If you try to migrate the site and person records in a single package, the location with type HOLDING causes a deployment error to occur. If this deployment error occurs, navigate to the Locations application and change the location type to OPERATING. Then return to Migration Manager and continue the deployment of the same package. Migration Manager now creates the person record and links it to the location record.
If an attribute is restricted by the Database Configuration application in a target environment, and an override of the restriction is not set up at the object structure level, the value of the attribute is not deployed.
Only the start center templates can be migrated. After you migrate a start center template, you can apply the template to an appropriate start center.
When you use the DMMAXPROP migration object, only system properties that meet specific conditions are migrated.
To be migrated, a system property must meet the following conditions:
When you configure the system-defined properties, always use the Systems Properties application within the target environment.
Migration Manager does not support migration of user interface system XML files between product environments. System XML files include lookups.xml, menus.xml and library.xml. These XML files are not application-specific. They store common user interface components or resources. Use the Application Designer application to manage the export and import of these system XML files.
If a person record is inactive and its related user record is also inactive, a deployment error occurs. The person record must be active for it to be added to a user record. To work around this limitation, migrate the person records, activate them in the target environment, and then migrate the user records.