Appendix B: Migrating Data from One Tenant Instance to Another Using Simple Mode or Advanced Mode

we do not recommend using these methods for migrating data see the four ways to migrate data docid\ xtgsi12juvvrmrhtaj dy for a list of the ways to migrate data we recommend enabling and using the ivanti service manager development project for migrating data, as described in migrating data using heat development project docid 4cdzr9ht uzme6dgkqbch about using simple mode and advanced mode docid\ stq b6ebnoc64jdl9kbizhow to use simple mode to migrate data docid\ stq b6ebnoc64jdl9kbizusing advanced mode to migrate data docid\ stq b6ebnoc64jdl9kbizmigration scenarios using simple mode and advanced mode docid\ t9nc3i l41hfwpczkgbui about using simple mode and advanced mode the relationship data between two business objects is copied from the source to the target under the following operations and conditions operations simple mode copy copy configuration and master data copy master data only condition only both business objects on both sides of the relationship are included for copying at the same time for example, if you copy user related data, but do not copy the users, then data such as user to team and user to group assignment is not copied as another example, if you want the service to category assignment to be copied, you must copy both the service (ci#service) and the category (category#) in the same push operation choose between the following simple mode see how to use simple mode to migrate data docid\ stq b6ebnoc64jdl9kbiz advanced mode see using advanced mode to migrate data docid\ stq b6ebnoc64jdl9kbiz how to use simple mode to migrate data using simple mode to migrate data docid\ stq b6ebnoc64jdl9kbizsimple mode migrated data docid\ stq b6ebnoc64jdl9kbiz using simple mode to migrate data when you start the migration, you see the copy dialog box in operations console with simple mode and advanced mode docid\ stq b6ebnoc64jdl9kbiz operations console with simple mode and advanced mode do not check advanced mode, which means you are choosing to use simple mode, which migrates a predefined set of data check skip target tenant backup before operation to not perform a database backup leave the box empty if you want to back up the database before proceeding with the migration check delete data items in target tenant instance that do not exist in source tenant instance to delete the data items in the target tenant instance that do not exist in the source tenant instance under copy the following selected data , check service request if you want to migrate service request information, and check escalation schedule if you want to migrate escalation schedule information do one of the following click preview to preview the changes that will be migrated the system generates an xml file for you to review you must save the xml file and open it with an xml editor to see the changes if you need to make additional changes, go back into the system and make them if you are satisfied with the changes, go back to the operations console and click execute click execute to start the data migration simple mode migrated data metadata docid\ stq b6ebnoc64jdl9kbizcustom validation data docid\ stq b6ebnoc64jdl9kbizmaster data docid\ stq b6ebnoc64jdl9kbizsettings docid\ stq b6ebnoc64jdl9kbiz metadata see types of data docid srybeqnhr2outxjfw8z for information about metadata deletes the metadata items in the target tenant instance that do not exist in the source tenant instance for the following items (equivalent to checking the box next to the metadata item name in the delete metadata items in target tenant instance that do not exist in source tenant instance section) role layout form grid trigger rule rule override validation data validation list definition does not delete the metadata items in the target tenant instance that do not exist in the source tenant instance for the following items (equivalent to not checking the box next to the metadata item name in the delete metadata items in target tenant instance that do not exist in source tenant instance section) business object branding workflow counter grid part metadata chart part metadata special part metadata search report dashboard quick action view part does not replace the metadata items in the target tenant instance that are newer than those in the source tenant instance for the following items (equivalent to not checking the box next to the metadata item name in the replace metadata items in target tenant instance that are newer than those in source tenant instance section) search report dashboard quick action see simple mode options top half docid\ stq b6ebnoc64jdl9kbiz custom validation data see types of data docid srybeqnhr2outxjfw8z for information about validation data deletes all custom validation data objects in the target tenant instance that do not exist in the source tenant instance this is equivalent to checking delete data items in target tenant instance that do not exist in source tenant instance in the custom defined validation list data objects section see simple mode options top half docid\ stq b6ebnoc64jdl9kbiz master data see types of data docid srybeqnhr2outxjfw8z in the terminology docid srybeqnhr2outxjfw8z section for information about master data migrates user related groups of master data this is equivalent to checking delete data items in target tenant instance that do not exist in source tenant instance in the master data copy options section migrates user related data (including employee, external contact, profile base, and profile employee information), which is the equivalent of checking user related in the copy the following selected data section see simple mode options top half docid\ stq b6ebnoc64jdl9kbiz and simple mode options bottom half docid\ stq b6ebnoc64jdl9kbiz simple mode options top half simple mode options bottom half settings see types of data docid srybeqnhr2outxjfw8z for information about settings, also referred to as configuration data deletes settings in the target tenant instance that do not exist in the source tenant instance this is equivalent to checking delete setting records in target tenant instance that do not exist in source tenant instance in the settings copy options section updates settings that were changed this is equivalent to checking update setting records that were changed in the settings copy options section applies the two options above to the following settings allowed attachments dynamic styles password policy approval status keywords email status update mapping settings ignore message with subject settings object mapping for email task assignment status keywords truncate body settings trusted sender domains see simple mode settings options docid\ stq b6ebnoc64jdl9kbiz simple mode settings options using advanced mode to migrate data migrating metadata and validation data (copy configuration) docid\ stq b6ebnoc64jdl9kbizupdating metadata, validation data, and master data (copy configuration & master data) docid\ stq b6ebnoc64jdl9kbizupdating master data (copy master data only) docid\ stq b6ebnoc64jdl9kbizoverwriting all metadata and validation data (copy to replace) docid\ stq b6ebnoc64jdl9kbizupdating only transactional data (copy data only) docid\ stq b6ebnoc64jdl9kbizupdating configuration data (copy settings) docid\ stq b6ebnoc64jdl9kbizupdating configuration data (copy translation) docid\ stq b6ebnoc64jdl9kbizincreasing the version number (no op \[increase version only]) docid\ stq b6ebnoc64jdl9kbiz migrating metadata and validation data (copy configuration) perform the following steps to update the configuration of a tenant instance by migrating metadata and validation data (see types of data docid srybeqnhr2outxjfw8z for information about metadata and validation data ) when you perform this migration, metadata and validation data that exist on the target tenant instance are overwritten by the data on the source tenant instance perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the copy dialog box, for the operation field, choose copy configuration to configure the operations console to copy metadata and validation data the dialog box expands and appears similar to the dialog box in copy dialog box (migrate metadata and validation data) docid\ stq b6ebnoc64jdl9kbiz you cannot change the value for the target landscape field, as it is read only and depends on the target you chose before you started the migration copy dialog box (migrate metadata and validation data) check skip target tenant backup before operation to select whether to back up the target tenant instance prior to the data migration to back up the target tenant instance, leave this checkbox empty if you have not yet backed up the target tenant outside of the operations console, we highly recommend that you back it up here to not back up the target tenant instance, select this checkbox if you have already backed up the target tenant outside of the operations console, it is generally not necessary to back it up here use the delete metadata items in target tenant instance that do not exist in source tenant instance section to select how to process items that were deleted in the source tenant instance prior to the migration for example, assume that staging is the source tenant instance and uat is the target tenant instance if you deleted some business objects on the staging tenant instance as part of a reconfiguration procedure, you can select whether to delete or retain those business objects on the uat tenant instance when you perform the data migration to delete business objects on the uat tenant instance, if those business objects were also deleted on the staging tenant instance, check business objects to retain business objects on the uat tenant instance even though they were deleted on the staging tenant instance (that is, to merge the staging and uat business object lists), do not check business objects use the checkboxes for other items (layouts, workflows, rules, and so on) in the same way if you do not select any options in this section, all data is merged, and no data on the uat instance of the tenant is deleted even if the target tenant instance is locked, you can still create, edit, and delete dashboards, quick actions, reports, and searches if you select any of these items, be aware that they could be deleted or updated when you execute a migration even if the target tenant instance is locked use the replace metadata items in target tenant instance that are newer than those in source tenant instance section to select how to process items that exist on both the source tenant instance and the target tenant instance when the version on the target tenant instance is newer than the version on the source tenant instance this situation is not typically encountered or recommended, but the ability to respond to it is provided because it does occur occasionally for example, assume that staging is the source tenant instance and uat is the target tenant instance during testing on the uat tenant instance, it was determined that a saved search needed to be modified, and the modification was performed on the uat instance of the tenant at the same time, another item (for example, change management processes and approvals) was updated on the staging instance of the tenant as part of a scheduled reconfiguration to merge the data on the staging instance of the tenant with the data on the uat instance of the tenant, check search this results in the most recent change updates (from staging) and the most recent saved search updates (from uat) coexisting on the uat instance of the tenant after the migration this is the recommended procedure because it ensures that the most recent version of all data is present on the uat instance of the tenant after the migration to overwrite all of the data on the uat instance of the tenant with data from the staging instance of the tenant (including overwriting the saved searches that were updated on the uat instance of the tenant), do not check search this results in the most recent change updates (from staging) migrating to the uat instance of the tenant, but the saved search changes that were made on the uat instance of the tenant prior to the migration are overwritten and reverted to the version on the staging instance of the tenant use the checkboxes for other items (dashboards, quick actions, and reports) in the same way if you do not select any checkboxes in this section, all data on the uat instance of the tenant is overwritten by data from the staging instance of the tenant to ensure that all data on the staging instance of the tenant is merged with the data on the uat instance of the tenant (instead of being overwritten), select every checkbox in this section even if the target tenant instance is locked, you can still create, edit, and delete dashboards, quick actions, reports, and searches if you select any of these items, be aware that they could be deleted or updated when you execute a migration even if the target tenant instance is locked use the custom defined validation list data objects section to select how to process validation lists that have been customized customized validation lists are not included in the validation data and validation list definition checkboxes shown in copy dialog box (migrate metadata and validation data) docid\ stq b6ebnoc64jdl9kbiz and described in step 3 to migrate customized validation lists, you must specify them in this step instead (see types of data docid srybeqnhr2outxjfw8z in the terminology docid srybeqnhr2outxjfw8z section for information about validation data ) for example, assume that staging is the source tenant instance and uat is the target tenant instance if a customized validation list already exists on the uat tenant instance, and the validation list is then further customized on the staging tenant instance, you can select whether to overwrite the uat version with the staging version or merge the two validation lists to see the customized validation lists, place the mouse pointer over the checkbox to delete customized validation list items on the uat instance of the tenant that were also deleted on the staging instance of the tenant (that is, to overwrite the uat validation list with the staging validation list), check delete data items in uat that do not exist in staging to retain customized validation list items on the uat instance of the tenant even though they were deleted on the staging instance of the tenant (that is, to merge the staging and uat validation lists), leave the delete data items in uat that do not exist in staging checkbox empty select one of these options to start or postpone the data migration execute starts the migration immediately preview creates an xml based patch file called metadatadiff xmlmetadatadiff metadatapatch you can review this file to see details of the data that will be migrated a preview takes the same amount of time to execute as an actual migration save setting saves your current selections without executing a migration the next time you open this dialog box it is populated with your saved settings save uat settings saves your current selections for use when you migrate from the uat instance of the tenant to the production instance of the tenant cancel exits the dialog box without saving any settings when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing (see about the events & audit history workspace docid\ ay7 esiqbyibct2dgixuy ) updating metadata, validation data, and master data (copy configuration & master data) do not use this feature if you have more than 100,000 records as the migration will fail if you have more data, we recommend that you either exclude some of the records from the data migration or use microsoft sql server scripts or some other tool to migrate the data from the operations console you can migrate master data together with metadata and validation data in the same migration (see types of data docid srybeqnhr2outxjfw8z in the terminology docid srybeqnhr2outxjfw8z section for information about master data, metadata, and validation data ) master data consists of data sets that are used across an organization and are typically unique to that organization user and role definitions, role assignments, and categories are examples of master data perform the following steps to update the configuration for a tenant instance by migrating master data together with metadata and validation data when you perform this migration, master data, metadata, and validation data that exist on the target tenant instance (uat in this example) are overwritten by the data on the source tenant instance (staging in this example) perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, choose copy configuration & master data to configure the operations console to copy master data together with metadata and validation data the dialog box expands and appears similar to the dialog box shown in copy dialog box (migrate metadata, validation data, and master data) top half docid\ stq b6ebnoc64jdl9kbiz and copy dialog box (migrate metadata, validation data, and master data) bottom half docid\ stq b6ebnoc64jdl9kbiz note that the top portion of the dialog box is identical to the dialog box shown in copy dialog box (migrate metadata and validation data) docid\ stq b6ebnoc64jdl9kbiz the bottom portion of the dialog box shown in copy dialog box (migrate metadata, validation data, and master data) bottom half docid\ stq b6ebnoc64jdl9kbiz (beginning with master data copy options ) is new copy dialog box (migrate metadata, validation data, and master data) top half copy dialog box (migrate metadata, validation data, and master data) bottom half fill in the top portion of the dialog box (the settings for metadata and validation data) as described in migrating metadata and validation data (copy configuration) docid\ stq b6ebnoc64jdl9kbiz use the master data copy options section to select how to process master data that was deleted in the source tenant instance prior to the migration for example, assume that staging is the source tenant instance and uat is the target tenant instance if you deleted master data on the staging tenant instance as part of a reconfiguration procedure, you can select whether to delete or retain that master data on the uat tenant instance when you perform the migration to delete master data on the uat tenant instance that was also deleted on the staging tenant instance (that is, to overwrite the uat master data with the staging master data), check delete data items in uat that do not exist in staging keep in mind that if deleted master data record definitions are used elsewhere in ivanti service manager, the deletion could break existing relationships or otherwise adversely affect the content of data records to retain master data on the uat tenant instance even though it was deleted on the staging tenant instance (that is, to merge the staging and uat master data), do not check delete data items in uat that do not exist in staging because of the implications of possibly breaking relationships and data records by deleting master data records in this step, it is sometimes advisable to fill in the copy the following selected data section as described in steps 4 and 5 before making your choice in this step use the copy the following selected data section to select which master data to migrate if you do not select any items in this section, no master data is migrated master data selection choices are as follows user only migrates user related data (including employee, external contact, profile base, and profile employee information) user related place the mouse pointer over this item to display an expanded list of all business objects contained in this item includes contact group, department, email address, organizational unit, and standard user team data) when you select this item, the operations console performs a full copy of all master data records in the tenant instance from each of the listed business objects if a tenant instance has more than 20,000 users in the system, we do not recommend selecting user related due to performance impact the profile base object is included in this selection, meaning that profile employee and profile externalcontact are migrated if the configuration includes a newly created child of the group object profile# (this is the profile base object), you must include the master data of the associated object as part of the additional data to be copied (described in step 5) the organizational unit definition is also included in this item if any changes were made to organizational units on other tenants through the ivanti service manager configuration console or by other means, they are overwritten when this item is migrated the address email object is also included in this item if the email addresses for the staging instance of the tenant are "scrubbed" to use the @saasitdemo com domain instead of the company domain, the scrubbed email addresses for all profile object records are migrated to the target domain if this configuration is eventually migrated to the production instance of the tenant, the @saasitdemo com domain setting is still in place, and various login, ldap import, notification, and email delivery issues will occur a workaround for this scenario is to not scrub email addresses on the staging instance of the tenant, and instead block all outbound email or redirect outbound email to a single email address the options to block email and to re direct all mail to a single account can be set in the email configuration business object because user and team email addresses on the staging and uat instances of the tenant might be scrubbed, the migration does not update existing users or teams instead, it migrates only new users and user teams user role assignments and user team assignments are updated as part of this selection service request place the mouse pointer over this item to display an expanded list of all business objects contained in this item when you select this item, the operations console performs a full copy (not a partial or selective copy) of all master data records in the tenant instance from each of the listed business objects to migrate a subset of the master data records shown in the list (for example, to migrate only the service request category (which has the object name "category")), do not check service request instead, include category in the additional data section as described in step 5 when you migrate data from the additional data section, it is a full migration (not a partial or selective migration) request offerings and their accompanying workflows are migrated when you select this item only those workflows that are part of a request offering design are migrated workflows that are associated with the service request business object are not migrated escalation schedule place the mouse pointer over this item to display an expanded list of all business objects contained in this item, such as escalation schedule, escalation setting, service level package, and service level target when you select this item, the operations console performs a full copy of all master data records in the tenant instance from each of the listed business objects as a general rule, all of the escalation parameters displayed in the ivanti service manager configuration console escalation tab are migrated note that when you migrate escalation schedules, existing schedules on the target tenant instance are overwritten use the additional data section to list additional master data or transactional data to migrate select one or more items to migrate the additional data section contains business objects that are not a part of metadata are not a part of custom defined validation data are not a part of the user only , user related , service request , or escalation schedule categories described in step 5 are not a part of typical transaction data such as incident, task, and change might be transactional data the operations console cannot autonomously differentiate between master data and transactional data business objects guidelines for selecting items are as follows you can select zero or more items from the additional data list do not select a business object that contains more than 10,000 records due to performance concerns if an object that is usually configured as metadata was for some reason configured as master data (or results in the creation of a related master data object), select the item here so that it is migrated for example, validation list data is migrated only if the validation list (that is, the pick list) is based on a business object that is part of the business object list for the validation business object if the validation list (that is, the pick list) is based on a master business object instead of a validation business object, it will not be migrated by checking validation data instead, you must select the validationlistdata item in the additional data list (as described here in step 5) in order for the validation list to be migrated click or \<ctrl> click items in the additional data list to migrate custom data configured as business objects keep in mind that migrating business objects with thousands of records can impact performance; these business objects should usually be migrated outside of the operations console smaller objects (such as category) are better candidates to select here for migrating within the operations console note that the operations console cannot perform selective copies during a migration that is, it can only copy a table to a table for example, if you select the additional data item table adfs/saml (frs authenticationprovider saml) ( example item selected in the additional data list docid\ stq b6ebnoc64jdl9kbiz ), all of the records from the source database are copied to the target database where frs authenticationprovider authtype = saml there is no option to copy only "active" or some selective option from the table frs authenticationprovider saml example item selected in the additional data list select one of these options to start or postpone the data migration execute starts the migration immediately preview creates an xml based patch file for review save setting saves your current selections without executing a migration you can continue the migration process later using your saved settings save target settings saves your current selections for use with the next migration in the migration sequence for example, if the current migration is from staging to uat, choose this option to save the settings for the uat to production migration that you will perform next cancel exits the dialog box without saving any settings when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing updating master data (copy master data only) from the operations console you can migrate master data only only do this after you have migrated the configuration data at least once do not use this feature if you have more than 100,000 records as the migration will fail if you have more data, we recommend that you either exclude some of the records from the data migration or use microsoft sql server scripts or some other tool to migrate the data master data consists of data sets that are used across an organization and are typically unique to that organization user and role definitions, role assignments, and categories are examples of master data (see types of data docid srybeqnhr2outxjfw8z for information about master data ) perform the following steps to update the configuration of a tenant instance by migrating master data only when you perform this migration, master data that exists on the target tenant instance (uat in this example) is overwritten by the data on the source tenant instance (staging in this example) perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, choose copy master data only to configure the operations console to copy master data only the dialog box expands and appears similar to the dialog box shown copy dialog box (migrate master data only) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (migrate master data only) fill in the dialog box (master data copy options) as described in steps 4, 5, 6, and 7 of updating metadata, validation data, and master data (copy configuration & master data) docid\ stq b6ebnoc64jdl9kbiz when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing overwriting all metadata and validation data (copy to replace) from the operations console you can perform a migration that overwrites all metadata and validation data on the target tenant instance with data from the source tenant instance (see types of data docid srybeqnhr2outxjfw8z for information about metadata and validation data ) this migration is equivalent to creating the first configuration on the target tenant instance as described in creating the first staging or uat instance of the tenant from the production instance of the tenant docid\ nk99nfacluuwabumozwcu perform the following steps to update a the configuration for a tenant instance by overwriting all metadata and validation data perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, select copy to replace this configures the operations console to overwrite all metadata and validation data on the target tenant instance the dialog box appears similar to the dialog box shown in copy dialog box (to overwrite metadata and validation data) docid\ stq b6ebnoc64jdl9kbiz perform the procedure described in updating metadata, validation data, and master data (copy configuration & master data) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (to overwrite metadata and validation data) click execute to initiate the migration when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing updating only transactional data (copy data only) the relationship data between two business objects is not copied from the source to the target when you select the updating only transactional data (copy data only) option from the operations console you can migrate transactional data (data records, including incidents, changes, service requests, and so on) without migrating any other type of data perform the following steps to update the configuration for a tenant instance by migrating transactional data when you perform this migration, transactional data that exists on the target tenant instance is overwritten by the data on the source tenant instance perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, select copy data only to configure the operations console to copy transactional data the dialog box expands and appears similar to the dialog box shown in copy dialog box (migrate only transactional data) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (migrate only transactional data) check skip target tenant backup before operation to select whether to back up the target tenant instance prior to the data migration to back up the target tenant instance, leave this checkbox empty if you have not yet backed up the target tenant instance outside of the operations console, we highly recommend that you back it up here to not back up the target tenant instance, select this checkbox if you have already backed up the target tenant instance outside of the operations console, it is generally not necessary to back it up here use the data only copy options section to select how to process transactional data that was deleted in the source tenant instance prior to the migration for example, assume that staging is the source tenant instance and production is the target tenant instance if you deleted transactional data on the staging tenant instance as part of a reconfiguration procedure, you can select whether to delete or retain that data on the production tenant instance when you perform the data migration to delete transactional data on the production tenant instance if that data was also deleted on the staging tenant instance, check delete data items in production that do not exist in staging to retain transactional data on the production tenant instance even though it was deleted on the staging tenant instance (that is, to merge the staging and production transactional data), leave this checkbox empty in the transactional data list, select the items to migrate click execute to initiate the migration or click preview to create an xml based patch file for review when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing updating configuration data (copy settings) from the operations console you can migrate configuration data, also known as settings perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, choose copy settings to configure the operations console to copy configuration data see copy dialog box (migrate settings) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (migrate settings) check skip target tenant backup before operation to select whether to back up the target tenant instance prior to the data migration to back up the target tenant instance, leave this checkbox empty if you have not yet backed up the target tenant instance outside of the operations console, we highly recommend that you back it up here to not back up the target tenant instance, select this checkbox if you have already backed up the target tenant instance outside of the operations console, it is generally not necessary to back it up here do one of the following to delete configuration data (settings) on the target tenant instance if that data was also deleted on the source tenant instance, check delete setting records in target tenant instance that do not exist in source tenant instance to retain configuration data (settings) on the target tenant instance even though it was deleted on the source tenant instance (that is, to merge the source and target configuration data), leave this check box empty to update configuration data (settings) that has changed in both the source and the target tenant instances, check update setting records that changed in the setting type list, select the configuration data types (settings) to migrate click execute to initiate the migration or click preview to create an xml based patch file for review when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing updating configuration data (copy translation) from the operations console you can migrate translation the system connects to the source database and copies over any translations that are different or more recent in the target database if there is no record in the source database but there is a record in the target, the system does not delete the record in the target database perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, choose copy translation to configure the operations console to copy translated data see copy dialog box (migrate settings) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (copy translation) check skip target tenant backup before operation to select whether to back up the target tenant instance prior to the data migration to back up the target tenant instance, leave this checkbox empty if you have not yet backed up the target tenant instance outside of the operations console, we highly recommend that you back it up here to not back up the target tenant instance, select this checkbox if you have already backed up the target tenant instance outside of the operations console, it is generally not necessary to back it up here click execute to initiate the migration when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing increasing the version number (no op \[increase version only]) you can only migrate data from one instance to another if there is a push link and the system only displays a push link if the tenant instances have different version numbers (the system automatically increases the version number of a tenant instance after a successful migration ) also, you can only migrate data from staging to production when the production instance of the tenant is at version 0 see version numbers of tenant instances docid\ stq b6ebnoc64jdl9kbiz for an example with push links and different version numbers for each tenant instance version numbers of tenant instances from the operations console you can increase the version number without changing any data by selecting no op (increase version only) perform steps 1 to 4 in starting the tenant instance migration docid\ nk99nfacluuwabumozwcu before you perform the steps in this section check advanced mode in the operation field in the copy dialog box, choose no op (increase version only) to increase the version number see copy dialog box (no op \[increase version only]) docid\ stq b6ebnoc64jdl9kbiz copy dialog box (no op \[increase version only]) click execute to initiate the migration when the data migration finishes, the system creates a log entry for it and updates the status of the affected tenants and tenant instances in the operations console migration dashboard as shown in migration dashboard docid\ nk99nfacluuwabumozwcu in starting the data migration docid\ nk99nfacluuwabumozwcu the system also displays an informational message with the results of the migration check the events & audit history workspace to review the warnings and errors before continuing