Export and Import Recommendations
-
Since an application is represented by all its packs, you have to collect all of them to transfer the application to another instance.
-
Do not make any changes to the existing functions (either incremental or decremental changes) during migration. To implement any important improvements, follow the guidelines below:
- Go through the development cycle stages (including testing).
- Or implement these improvements after the migration is completed.
-
Configuration migration is done with the Configuration Packages. To simplify this process, merge some packs before exporting. To ensure importing only actual versions, create snapshots of each application imported using the instructions below:
-
Create a local pack for an application to migrate. For example, a local pack for the Simple Application tables snapshot may be named as a [SA] - Snapshot diff.
-
Set this local pack as current.
-
Navigate to System Settings → Server Scripts and run the script below to create snapshots of all versioned tables:
Table Shapshot Scriptconst table = new SimpleRecord('sys_db_table');
table.addQuery('is_vcs_enabled', true);
table.addQuery('sys_id', '!=', '999999999999999998'); // exclude REM
table.selectAttributes('name');
table.query();
while (table.next()) {
const vcs = new SimpleVcs();
const versionCount = vcs.createTableSnapshot(table.name);
if (versionCount > 0) {
ss.info(`${table.name.padStart(80, " ")}: ${versionCount} versions created`);
}
}warningWhen transferring an application, pay attention to the dependencies with the other applications that it has.
For example, an application on the target instance may lack the roles used within the ACLs of the migrated applications. In this case, the access restrictions cannot work properly.
-
-
Also, do not forget to import the related records of the following tables:
Table system name Table title Description sys_search_index Search Index Stores search indices.
You cannot create, edit, or delete records in the Search Index (sys_search_index) table. Only users with the admin role can read them.
sys_activity_feed_item Activity Feed Item Stores record field changes recorded by the Activity Feed.
You cannot create, edit, or delete records in the Activity Feed Item (sys_activity_feed_item) table. Only users with the admin role can read them.
sys_history History Stores field changes history.
You cannot create, edit, or delete records in the History (sys_history) table. Only users with the admin role can read them.
sys_activities_stream_field Activity Stream Field Stores record field changes recorded by the Activity Stream Widget.
You cannot create, edit, or delete records in the Activities Stream Field (sys_activities_stream_field) table. Only users with the admin role can read them.
sys_email Emails Stores Incoming and Outgoing Emails. -
Most users have their own interface usage patterns. Include the tables below into your migration process so as not to disrupt them:
Table system name Table title Description sys_menu_favorite Menu Favorite Stores user Favorites. sys_filter Filter Stores user filters. sys_user_preference User Preference Stores User Preferences. -
When performing user migration in a complex way, remember to import roles and group objects.
Table system name Table title Description user Users Stores instance Users list and related information. employee Employees Stores Employees list and related information. sys_role Roles Stores available Roles list. sys_role_contains Role Contains M2M table, stores relationships between parent and child roles. sys_group Groups Stores available Groups list. sys_group_contains Group Contains An M2M table, stores relationships between parent and child groups. sys_user_has_role User has Role An M2M table, stores relationships between users and roles they are granted. sys_user_group User Group An M2M table, stores relationships between users and groups they are granted. sys_user_criteria User Criteria Stores User Criteria list.