Prerequisites

  • You must have access and execution rights in the $FIC_HOME/utility/Migration/ directory in both the source and target environment.
  • Folders (segments) and user groups that are designated for the import should be present in the target.
  • The source and target environment should have the same installed locales.
  • OFSAA users in source should be the same in target (at least for users associated with objects migrated).
  • OFSAA users should have access to folders in target as well as source.

Underlying tables of the objects being migrated should exist in target.

For example, if you want to migrate a Data Element Filter based on "Table A" and "Table B" in the source, those two tables should exist in the target.

  • For AMHM Dimensions and Hierarchies:
  • The key processing Dimensions should be the same in both the source and target environments.
  • For Member migration, the Dimension type should have the same attributes in both source and target environments.
  • Numeric Dimension Member IDs should be the same in both the source and target environments, to ensure the integrity of any Member-based objects.

    Note:

    If you have used the Master Table approach for loading Dimension data and set it up to generate surrogate keys for Members, this results in different IDs between the source and target, so it may cause errors if you have objects which depend on these IDs.
  • All objects that generate new ID after migrating to a different information domain and all components which are registered through the Component Registration window, which will be used in the RRF, must be manually entered in AAI_OBJ_REF_UPDATE table in the Configuration Schema. The implicit migration of dependent objects is not supported. They should be migrated explicitly. The attributes present in the table are:
    • V_OBJECT_TYPE- EPM Object Type
    • V_RRF_OBJECT_TYPE- RRF object Type. The ID can be referred from pr2_component_master table
    • V_ICC_OBJECT_TYPE- ICC object type, can be referred from component_master table.
    • F_IS_FILTER- Is the object to be migrated as a filter/not?
    • N_BATCH_PARAMETER_ORDER- the order of parameter in task (if used in a batch).