Migrating Service Request Data

This article applies to Service Now to Service Now Instance Migrations ONLY

Precision Bridge provides 2 templates specifically constructed to assist with migration of service request data. These templates generally assume that all referenced configuration records exist on the target server already.

Pre-Requisites

To ensure this is the case, it is advised to run the following Service Now -> Service Now templates first:

1. Organisation. This will migrate all users/groups/roles and locational data for all companies, or a specific company.
2. CMDB. All CMDB Records that may be referenced by the Catalog Items (including in their variables.
3. Workflow Definitions. Request workflow definitions and workflow tied to specific catalog items should be migrated if you are planning to migrate the workflow contexts relating to Requests and Request Items so that workflow will continue to process post-migration.

Any other tables that are referenced by variables defined for catalog items should be migrated.

Reference Record Correlation

It is strongly advised that sys_id's be maintained for all reference dates to make correlation easy to define and performance efficient. This will generally be the case when the data is migrated using Precision Bridge, or via an update set.

If users/groups have already been generated on target using an LDAP integration, they will likely not have the same sys_id's. The Precision Bridge Projects will still operate correctly if the groups have the same name and the users have the same user id on both source and target.

If CMDB records have been created on target using discovery, they will likely not have the same sys_id as their source. In this case, you are advised to create a Configuration Item reference mapping for all fields that reference Configuration Item (or one of its extended tables) Failure to do this will result in 'broken' references in the target records produced using these templates.

Migration of the Service Catalog

The first project to run relating to Service Requests is the Service Catalog.

Again, it is strongly recommended that the catalog items are migrated using Precision Bridge rather than re-creating them manually on the target in order to maintain sys_id values. If this is not done, additional reference mappings will be needed for any field that references the service catalog items, or any variables defined within. This will considerably complicate the migration project and reduce performance when the migration is run due to the need to correlate far more records with reference mappings. If it is required to migrate active workflow that references these variables, the task of ensuring the workflow continues to run correctly to completion on the target becomes virtually impossible.

If changes are to be made to the catalog items as part of configuring the new server you can migrate the existing catalog items to the target, then make any changes required, noting the possible impact of removing/changing variables on any workflow that makes use of them. 

An alternative to this approach is to migrate the legacy catalog items and their variables with status disabled. This will allow the request items that are migrated to display correctly, while also ensuring that no further requests are raised against the legacy catalog items.

Migrating the Requests

Always migrate the Service Catalog before the Requests.

Migration of workflow is optional. It is recommended that closed requests/request items do not migrate workflow to improve performance.

Test migration of individual requests first using the OTB source filter in the Requests mapping that will migrate a single request (identified by number) and all related records. Once you are happy that the mappings operate correctly, change the source filter to migrate a larger set of requests.

Variable Values that are references will be correlated using their display value. If this will not work correctly for specific referenced tables, you will need to create new mappings specific to these tables. More information is in the next section.

Complex Correlation of variable values - Example.

In this example, user values cannot be correlated using their user_id. Instead, they can be correlated by their email address. This will mean that the ID Replace Mapping will not work, since this correlates using the display value (user_id for the sys_user table)

We will therefore need to add a new mapping for tables that reference sys_user to update the value.

Overview of Steps:

• Change the source filter of the form mapping Options (Lookup/Reference) to exclude values referencing the table sys_user (suggested filter below)

@@QRY('item_option_new.choice_table!=sys_user^item_option_new.type=5^NQitem_option_new.table!=sys_user^NQitem_option_new.reference!=sys_user^item_option_new.type=8^NQitem_option_new.list_table!=sys_user^item_option_new.type=21^NQitem_option_new.lookup_table!=sys_user^item_option_new.typeIN22,18')

• Duplicate the form mapping Options (Lookup/Reference)
• Change the identifier of the duplicated mapping to Options (Lookup/Reference) - sys_user
• Change the source filter of the duplicated record to retrieve records where one of the table fields is set to sys_user (see below for suggested filter)

@@QRY('item_option_new.choice_table=sys_user^item_option_new.type=5^NQitem_option_new.table=sys_user^NQitem_option_new.reference=sys_user^item_option_new.type=8^NQitem_option_new.list_table=sys_user^item_option_new.type=21^NQitem_option_new.lookup_table=sys_user^item_option_new.typeIN22,18')

• Change the field mapping for Value to a reference mapping (see below)

• Open the Form Mapping User Reference Mapping. Map the email field using a simple mapping. In the key mappings tab, remove the user_id mapping and add the mapping for email (see below)

When the project is run now, the first form mapping will create the variable value records using display value correlation for references for all reference values excluding those referencing sys_user. The second form mapping, that we added, will then create the variable value records that reference the sys_user table to set the values using correlation by the value of the email field.

A similar approach can be used for other referenced tables. You will need to add reference form mappings for these tables to define the key mappings for this table

Migrating at Volume - Tips

• It is recommended that you make use of multithreading to improve performance when migrating large volumes of records.
• Make sure you have fully tested your mappings on individual requests first. It can be difficult sometimes to undo mistakes on a large volume of records.
• Use the source filtering to break up the records. Usually, this will be by defining a data range filter.
• Use project variables to allow the date range to be defined at execution time rather than hard coded into the project.
• Consider carefully whether workflow needs to be migrated. This will add a lot of additional processing and therefore reduce performance.