Migration limitations
Although most configuration content can be migrated in most environments, some configuration cannot be migrated. Extra steps are required in some circumstances.
Actions
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.
Action groups
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.
Base language
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.
Collection restrictions
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.
Crossover domains
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.
Database configuration
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.
Database indexes
For IBM® 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.
Charts of accounts
Migration Manager does not migrate charts of accounts (GLs).
Classifications
The following limitations affect the migration of classifications:
- Data that is related to the CLASSIFICATION table is not migrated.
- You cannot migrate a classification hierarchy in which a parent classification was changed to alter the parent-child classification relationship.
- In Snapshot packages, regardless of the selected processing action, a database update is performed for classification records.
- You cannot migrate two or more different classifications that have the same hierarchy path.
Conditions on security groups
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.
Different database platforms
A package cannot be migrated between different database platforms if it contains configuration records for objects, attributes, keys, indexes, or sequences. For example, you cannot deploy a package from an Oracle source environment to a DB2 target environment.
Migration Manager issues an error message indicating that it cannot deploy such a package. You can confirm the cause of the error by viewing the manifest of the package. You view the manifest to determine whether the DMMAXOBJECTCFG migration object is part of the package.
Discarded configuration changes
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.
Electronic auditing
If you use the Database Configuration application to enable electronic auditing, any electronic auditing tables that are created are not migrated.
Exchange rates
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.
Integration tables
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.
Lookup maps
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.
MAXVARS table
The source and target environments must have identical MAXVARS tables. Ensure that you use the same installation and upgrade procedures in the environments so that the tables are identical.
Organizations
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.
Restricted attributes
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.
Security settings
The following limitations apply to the migration of security settings:
- If you use LDAP, do not use the Migration Manager application to migrate user IDs. Use the LDAP server and tools to manage user IDs.
- When user IDs are migrated to a target environment, the passwords are reset and sent to the users in an email message. To receive the email message, the email server must be set up in the target environment. Additionally, the users must have configured email addresses in the target environment. The password sent in the email is a temporary password. The temporary password expires when the user logs in for the first time, at which time the user must reset the password. Use the mail.smtp.host system property in the System Properties application to set up the email server. The value for the property is the name of the host running the SMTP mail server.
- Password hint questions and answers are not migrated.
- Data in the MAXUSERSTATUS and LOGINTRACKING tables is not migrated.
- The product user data that is stored in the MAXUSER table is migrated. However, the corresponding native database user data that is stored in the data dictionary of the database is not migrated. If you want to maintain the product users as database users in the target environment, you must create the database users corresponding to the product users. You must also grant database access to these users. You can create the database users and grant them database access by selecting Database Access from the Select Action menu in the Users application.
- The following information in security groups is not migrated:
- Labor authorizations
- Limits and tolerances
- Purchase general ledger
- Status history
- Storeroom authorizations
- User storerooms are not migrated. You must ensure that the storerooms are the same in the source and target environments.
Start centers
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.
System properties
Only system properties that meet specific conditions are migrated when you use the DMMAXPROP migration object.
To be migrated, a system property must meet the following conditions:
- The property is user-defined.
- The property is not configured for a file override with a value in the maximo.properties file.
- The property value is tagged with COMMON and does not have an instance-specific value.
Always configure the system-defined system properties in a target environment.
System XML files
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.
Ticket templates
The following limitations affect the migration of ticket templates:
- When you deploy a ticket template that references a job plan, the job plan must exist in the target and have a status of ACTIVE. If the status of the job plan is not ACTIVE, the deployment of the ticket template will fail.
- When you deploy a ticket template, a new autokey value is generated for the record by default. If this behavior is unsuitable, you must customize the DMTKTEMPLATE object structure.
- If you migrate ticket templates by using Change packages, you must activate the package definition before any ticket templates are created or updated. After the Change package is deployed, you must reset the event tracking records for the package definition in the source environment.
- To migrate ticket templates that have activities and activity specifications, a classification must be associated with the template.
- The status of ticket templates is preserved. For example, if a template is active in the source environment, the template is also active in the target environment after migration.
User and person records
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.
