• An Element is migrated with its Custom Fields and their Sections
  • [6.4.4] If the Custom Field or its value assigned to the Element does not exist in the target instance, it is created. If it already exists, it is not updated
• An Element displays correct value sourced from a Dataset that uses a User Map after the migration
• The Datasets that provide the source data for selected Elements are added to the export sequence automatically
• If the Also migrate Folder relationship checkbox is activated, the Folder that contains selected Element will also be migrated
  • That won’t automatically include other Elements that are stored in that same Folder
  • If the Folder already exists in the target system, it will be updated, and if not, the Folder will be created. This checkbox works with the Elements only

In versions prior to 6.3.4, when Elements with a Custom Field sourced from CSV Dataset were imported, no data was exported as part of the Dataset and no values as part of the Custom Field (linkage to Dataset and column remains).

In 6.3.4 Version this issue was fixed and it became possible to migrate the CSV Dataset with its data.

A Dataset that is sourced from another Dataset is migrated with its source Dataset(s). As of now, the Dataset that uses other Dataset(s) as its source can't be migrated individually.

• A Custom Field is migrated with its values (also when selected as a component of an Element) and the Section it belongs to. If a Section with the same name already exists on the target instance,it will be updated
• A Custom Field Section is migrated without Permissions and only with those Custom Fields that are added to the export list
• A Custom Field is migrated without its Elements
• All new or updated Sections are located at the bottom of the Custom Field Sections list
• If a Custom Field is included in, for example, Risk Section on a source instance and the same Custom Field has, for example, Default Section on a target instance, then after the migration it will exist in the migrated Risk Section
• If a Custom Field uses Source Dataset for values on a source instance, the Dataset will be migrated with the Custom Field to a target instance. If the Source Dataset uses a User Map on a source instance, the User Map will be migrated with the Dataset and the Custom Field to a target instance
• All Custom Fields settings are migrated for all Custom Fields types (Single, Multi, Text)
• While migrating a Custom Field with "User" type, the system searches for values of this Custom Field by a username
• After the migration the Custom Field Editor linkage to Dataset, column and hyperlink is the same as on a source instance
• History tab of an imported Custom Field becomes empty on a target instance after the migration process

Portal Pages can be migrated along with all types of Entities:

• Dataset Entity and Dataset itself
• Data Source Entity (with linkage to the selected Data Source if it exists on a target system)
• Custom Script Entity and Custom Script itself, including all parameters
• Internal Entity with correct settings

When Maintain any existing variable/content values set for included Portal Page(s) option is selected upon export, existing variables and values on the target instance are not updated upon import, new variables are added with values, and variables which are not on source but existed on target are removed.

Exceptions:

1. Git credentials are not migrated with Portal Page
   • If a Portal Page is created on a target system upon import, Git credentials won't be migrated
   • If a Portal Page is updated on a target system upon import, Git credentials won't be updated
2. If Portal Page A inherits access of Portal Page B and Portal Page A is imported to a target system, then Portal Page B won't be migrated. If Portal Page B exists on a target system, access will be inherited

The Portal Pages on the source and target systems are matched by their names and internal names:

• If the internal names of the Portal Pages are the same, but the names are different, all the data in the Portal Page on the target system will be updated according to the data of the Portal Page on the source system, including the name
• If the names of the Portal Pages are the same, but the internal names are different and there is another Portal Page on the target system with matching internal name, the import stops

• The system migrates all the Privileges in the Privilege set, but not Groups or Users that are matched with those Privileges
• The Privilege set exported from the source system is recreated on the target system
  • If there are no Privileges in the Privileges set on the source system, Privileges in the updated Privilege set on the target system will be erased

• The Folder is migrated with all the Elements stored in it 
• If the Apply updates to included elements when migrating Folder to target system checkbox is activated and the corresponding Folder already exists on the target system, all the Elements in the Folder on the target system will be replaced with the Elements from the source system
  • If this checkbox is deactivated, existing Elements will remain intact and only the non-existent ones are created in the Folder
• [6.4.4] If the Group with which a Folder is shared is exported along with another Element or Object, and that Group already exists on the target instance, its connection to the Folder is not updated
• [6.4.4] If the exported Group does not exist on the target instance, it is created and connected to existing Folders. In this case, connections an existing Folder has to other Groups on the target instance are not updated

• The User Group is migrated with all the Privileges and Permissions, but without Users
• The Permissions are migrated, but not the Elements those Privileges are applied to
• [6.4.4] If the Group is exported along with another Element or Object, i.e., the Portal Page is exported with the Group it is shared with, and the Group exists on the target instance, its connections to Folders are not updated
  • If the Group is exported along with another Element or Object and the Group does not exist on the target instance, it is created and connected to the existing Folders. In this case, connections an existing Folder has to other Groups on the target instance are not updated

The Groups on the source and target systems are matched by their names and aliases:

• If the names of the Groups are the same, but the aliases are different, all the data in the Group, as well as the alias of the Group on the target system will be updated according to the data of the Group on the source system
• If the aliases of the Groups are the same, but the names are different, all the data in the Group on the target system will be updated according to the data of the Group on the source system, but the name will be left unchanged

• The Business Unit is migrated with all information about the Business Unit  
• Groups associated with the Business Unit are included, but without Group related data (Group Privileges and Permissions are not included)
• If the Business Unit on the source system contains a Group that doesn’t exist on the target system, the new Group won’t be created on the target system 
• If an associated Business Unit's Group already exist on the target system it will not be updated with any Group information from the source system; only the association with the migrated Business Unit
  • The Group can be linked only to one Business Unit, so in this case, if the Group had a connection to another Business Unit it would be unlinked from it, and linked to the migrated Business Unit

A Dimension can be migrated as:

• Standalone object. The User adds a Dimension in the export sequence
• Element dependency. The User adds to the export sequence a Dimensioned Element 

In both cases, it can be migrated only if restrictions are not applied.

Email Templates are migrated without Permissions and attached Dataset(s). If you want to include the branding images into the migration process, they must have the following format:  

<img src='$IMAGE:{"type":"branding","file":"<%=digestTemplate.utf8_to_b64('footer.png')%>"

A target instance is checked against a pair of conditions "Name-Type" and:

1. If an Email Template of any type (Default/Not-Default) is migrated from a source instance and there is no Email Template with the same name and type on a target instance, then a new non-default Template will be created on a target system 
2. If an Email Template is migrated from a source instance and there is Email Template with the same name and type on a target instance, the Template on a target system will be updated with the information form the source system