ITSM Task Migration Templates

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

These Templates are likely to be more suited to greenfield migrations where most of the referenced data has been migrated in such a way as to retain sys_id's. This allows performance to be optimized. 

The description below applies to the following Service Now -> Service Now templates:

• Change Management -> Change Requests
• Change Management -> Proposed Changes
• Incident and Problem Management -> Incidents
• incident and Problem Management -> Problems
• Customer Service Management -> Cases
• Service Request Management -> Requests

Source Filtering

All templates are defined with a source filter to migrate a single task record and all associated records, based on its number, defined as a project variable that is entered at execution time. If you wish to change this to use other criteria to identify the task records (for example a date range or status), change the source query for the Task record. You can make use of Project Variables in this query if needed. Below is an example that uses two project variables to define a date range.

Use of Reference /ID List Mappings

The general assumption is that referenced records can be correlated using the sys_id means that simple mappings have been used in place of reference mappings for most reference field mappings. This will give improved performance during migration.

The only referenced tables that are NOT assumed to correlate using sys ID are as follows:

• User (correlate using user_id)
• Group (correlate using name)
• Company (correlate using name)
• Location (correlate using name)

If other referenced tables do not correlate using sys_id in your migration, you are advised to update your project to use reference mappings or id list mappings to map any fields that reference these tables, where the field(s) that will be used to correlate source and target records can be defined.

If any of the above reference tables do, in fact, correlate on sys_id in your migration, you are advised to change these mappings to simple mappings to improve performance in a high volume migration.

Migration of Workflow

These templates support the migration of active workflow running on either the Task itself or on the SLA Task. These mappings are disabled OTB, but can be enabled in the mapping list.

For workflow migration to be successful, the workflow definition (sys_workflow) MUST already have been migrated and MUST have the same sys_id as the source. You can use the S2S Workflow Definitions project for this purpose.

The workflow definition does NOT need to have a published version for the migration of active workflow to work successfully. Precision Bridge will also migrate any missing workflow versions required.

Note that migration of workflow involves many tables, so performance will be degraded. It is advised to consider whether you need to migrate workflow, particularly for tasks that have already been completed.

Migration of SLA Tasks

OTB, these templates will also migrate any missing SLA Tasks relating to the task table being migrated (e.g Incident, Problem, Change etc). Again the assumption is that these will correlate on sys_id.

Migration of Audit Records

Migration of audit records is disabled OTB, consider carefully if you need to include this. In a high volume migration, the migration of audit records will degrade performance significantly. Audit records will automatically be included for journal entry/work note additions to the task to ensure that the activity log includes these. Also, note that where the value holds a reference to a record (via its sys_id) the assumption is that the referenced record can be correlated on source and target by its sys id. If this is not the case, additional mappings will be needed to support audit records for specific fields and performance will be further impacted.