Out-of-box data migration settings

The Data Migration Tool provides the following out-of-box data migration settings.

Problem data migration

Considering that Problem does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode (especially for migrating a large volume of closed tickets).

Note After you migrate the Problem data, remove the “Problem_Library_disabled_by_PDHD” knowledge base as this legacy library is no longer used.

The out-of-box example data migration is based on the following three key fields:

  • status
  • category
  • current.phase

Note You can add additional fields if needed, but do not remove these three fields. 

Problem

Default settings:

Source Table

rootcause

Target Table

rootcause

Filter Condition

category="BPPM"

Field Mapping:

Target Field

Source Field

category

category

current.phase

current.phase

rcStatus

rcStatus

Value Mapping:

Target Value Mapping Field

Mapping Type

Condition

Target Value

category

fixedValue

category="BPPM"

problem

current.phase

fixedValue

(current.phase="Problem Detection, Logging and Categorization" or 
current.phase="Problem Prioritization and Planning") and rcStatus~="Closed"

Categorization

current.phase

fixedValue

current.phase="Problem Investigation and Diagnosis" and rcStatus~="Closed"

Investigation

current.phase

fixedValue

current.phase="Problem Resolution" and rcStatus~="Closed"

Resolution

current.phase

fixedValue

current.phase="Problem Closure and Review" and rcStatus~="Closed"

Review

current.phase

fixedValue

rcStatus="Closed"

Closure

rcStatus

fixedValue

(current.phase="Problem Detection, Logging and Categorization" or  current.phase="Problem Prioritization and Planning") and rcStatus~="Closed" and rcStatus~="Deferred"

Categorize

rcStatus

fixedValue

current.phase="Problem Resolution" and (rcStatus="Pending Vendor" or rcStatus="Pending User")

Pending

rcStatus

fixedValue

(current.phase="Problem Investigation and Diagnosis" or current.phase="Problem Resolution") and rcStatus~="Closed" and rcStatus~="Deferred"

Work In Progress

rcStatus

fixedValue

current.phase~="Problem Closure and Review" and rcStatus="Deferred"

Deferred

rcStatus

fixedValue

current.phase="Problem Closure and Review" and rcStatus~="Closed"

Resolved

rcStatus

fixedValue

rcStatus="Closed"

Closed

Problem Task

Default Settings:

Source Table

rootcausetask

Target Table

rootcausetask

Filter Condition

task.category="Default"

Field Mapping:

Target Field

Source Field

task.category

task.category

current.phase

current.phase

rcStatus

rcStatus

Value Mapping:

Target Value Mapping Field

Mapping Type

Condition

Target Value

task.category

fixedValue

Investigation

current.phase

fixedValue

rcStatus~="Closed"

Active

current.phase

fixedValue

rcStatus="Closed"

Closure

rcStatus

fixedValue

rcStatus="Work In Progress"

Work In Progress

rcStatus

fixedValue

rcStatus="Pending Vendor" or rcStatus="Pending User"

Pending

rcStatus

fixedValue

rcStatus="Closed"

Closed

rcStatus

fixedValue

rcStatus~="Work In Progress" and rcStatus~="Pending Vendor" and rcStatus~="Pending User" and rcStatus~="Closed"

Assigned

Task Planner data migration

In versions of Service Manager earlier than 9.40, Task Planner data is stored in the changeModel and changePlan tables. However, in Service Manager 9.40, Task Planner data is stored in the changePlan table only. Therefore, two data migration settings are provided to migrate Task Planner data from Service Manager 9.40 and earlier versions.

Migrate legacy change model Task Planner data to new Task Planner

Default settings:

Source table

changeModel

Target Table

changePlan

Query

not null(tasks)

Batch Update

false

Field mapping:

Target field

Source field

fileName

 

number

id

Value mapping:

Target value mapping field

Mapping type

Condition

Target value

fileName

fixedValue

changeModel

Post script:

for(var i=0;i<$sourceTable.tasks.length();i++){
	$targetTable.tasks[i].taskId=$sourceTable.tasks[i].taskId;
	$targetTable.tasks[i].taskCoords=$sourceTable.tasks[i].taskCoords;
	$targetTable.tasks[i].dependentIds=$sourceTable.tasks[i].dependentIds;
	$targetTable.tasks[i].dependentCoords=$sourceTable.tasks[i].dependentCoords;
	$targetTable.tasks[i].taskCategory=$sourceTable.tasks[i].taskCategory;
	$targetTable.tasks[i].taskTemplate=$sourceTable.tasks[i].taskTemplate;
	$targetTable.tasks[i].taskDescription=$sourceTable.tasks[i].taskDescription;
	$targetTable.tasks[i].openInPhase=$sourceTable.tasks[i].openInPhase;
	$targetTable.tasks[i].closeByPhase=$sourceTable.tasks[i].closeByPhase;
	$targetTable.tasks[i].activeCond=$sourceTable.tasks[i].activeCond;
	$targetTable.tasks[i].activeCondXML=$sourceTable.tasks[i].activeCondXML;
	$targetTable.tasks[i].activeCondDesc=$sourceTable.tasks[i].activeCondDesc;
	$targetTable.tasks[i].mandatory=$sourceTable.tasks[i].mandatory;
}
$targetTable.doUpdate();

Migrate legacy change instance Task Planner data to new Task Planner

Default settings:

Source table

changePlan

Target Table

changePlan

Query

null(fileName)

Batch Update

true

Field mapping:

Target field

Source field

fileName

fileName

Value mapping:

Target value mapping field

Mapping type

Condition

Target value

fileName

fixedValue

 

cm3r

Migrate legacy change/task data to new Task Planner

In Service Manager Hybrid, task information is stored in the change’s task plan. Change task information must be migrated to the new Task Planner. To do this, use the “Legacy change/task data to new taskplanner” data migration setting in the data migration tool.

Default settings:

Source table

cm3r

Target Table

changePlan

Query

open=true

Batch Update

 

Field mapping:

Target field

Source field

fileName

 

Number header,number

Value mapping:

Target value mapping field

Mapping type

Condition

Target value

fileName

 

 

 

Known Error data migration

Known Error data migration differs from Interaction, Incident, and Problem because Known Error data must be copied from the knownerror file to the rootcause file, and the field mapping is also more extensive than in other modules.

Because it is a data copy, you cannot use the batch update mode. However, knownerror data volume is usually much less than that of Incident or Interaction.  Therefore, the normal copy mode should be sufficient for most environments.

Note After you migrate the knownerror data, remove the “KnownError_Library_disabled_by_PDHD” knowledge base as this legacy library is no longer used.

The Data Migration Tool provides four migration settings, which you should run in their corresponding scenario as described in the following table.

Scenario Migration setting(s)
Migrating from legacy Known Error

Legacy known error to new known error

Legacy known error related record migration

Legacy known error attachment to new known error attachment

Migrating from legacy Process Designer Known Error

Legacy Process Designer known error to new Process Designer known error

For more information about how to use this migration setting, see Migrating from legacy Process Designer known error records.

Additionally, because knownerror data is copied and the records are re-created in the rootcause file, you must also update the screlation file to correct the relations of known errors. To do this, the out-of-box Process Designer provides another migration script called “Legacy known error related record migration”.

Note Attachments for legacy knownerror records are migrated as attachments for the new known error records.

Default Settings:

Source Table knownerror
Target Table rootcause
Filter Condition true

Field Mappings:

Target Field(Problem) Source Field(Known Error)
id id
category category
assignment assignment
status status
logical.name logical.name
brief.description brief.description
description description
root.cause root.cause
update update
open open
open.time open.time
opened.by opened.by
update.time update.time
updated.by updated.by
close.time close.time
closed.by closed.by
reopen.time reopen.time
reopened.by reopened.by
priority.code priority.code
ticket.owner ticket.owner
severity severity
sysmodtime sysmodtime
sysmodcount sysmodcount
sysmoduser sysmoduser
assignee.name assignee.name
subcategory subcategory
product.type product.type
problem.type problem.type
company company
dump dump
resolution resolution
workaround workaround
incident.category incident.category
current.phase current.phase
incident.count incident.count
initial.impact initial.impact
future.impact future.impact
impact impact
users.affected users.affected
problem.start.time problem.start.time
expected.resolution.time expected.resolution.time
location.type location.type
frequency frequency
proposed.solution proposed.solution
review.notes review.notes
cause.code cause.code
affected.ci matching.ci
ci.device.name matching.device.name
ci.device.type matching.device.type
ci.assign.group matching.assign.group
ci.location matching.location
affected.companies affected.companies
affected.ci.count matching.ci.count
last.task.no last.task.no
kpf.id kpf.id
kpf.file kpf.file
folder folder
closure.code closure.code
estimatedCost estimatedCost
estimatedMandays estimatedMandays
rootcauseDate knownerrorDate
solutionDate solutionDate
affected.item affected.item
rcStatus rcStatus
interaction.count interaction.count
publishWorkaround publishWorkaround

Value Mappings:

Target Value Mapping Field Mapping Type Condition Target Value

category

fixedValue

true

known error

current.phase

fixedValue

rcStatus~="Closed"

Logging

current.phase

fixedValue

rcStatus="Closed"

Closure

isKnownError

fixedValue

true

true

rcStatus

fixedValue

rcStatus~="Closed"

Open

rcStatus

fixedValue

rcStatus="Closed"

Closed

Migrating from legacy Process Designer known error records

If you upgraded your system from an older Process Designer version, you need to migrate your old Process Designer knownerror records to new Process Designer knownerror records by using the Legacy PD known error to new PD known error migration setting. The migration process includes the following procedures:

  1. Change the old Known Error record to Problem record, and then create a new Known Error record with a category of "known error."
  2. Link the new Known Error record to the Problem record.
  3. Copy or do not copy the original relations to the new Known Error record, based on the option you select in the Post Script tab of this migration setting, as described in the following table.

    Option for relation processing

    Description

    Skip Copying Relations to New Known Error Records

    This option does not copy original relations to new known error records.

    Copy Relations to New Known Error Records

    This option copies original relations to new known error records.

Service Level Management data migration

As of Service Manager 9.40, the Service Level Management (SLM) module is reimplemented on Process Designer (PD). If you upgraded from an earlier version of Service Manager, you need to migrate your legacy SLM data so that your SLM module can work correctly on Process Designer-based workflows.

The purpose of SLM data migration is to set a category and set a phase for agreement records based on the following rules:

  • The Category of an agreement record is populated with the category of one of the targets if all the targets of the agreement have the same category (that is, the Service Level Category field in the target record).
  • The Category of an agreement record is populated with a value of Service Level Agreement if the targets of the agreement have different categories or have an empty category.
  • The Phase of an agreement record is populated with “agreed” if the expiration date is later than the current date.
  • The Phase of an agreement record is populated with “expired” if the expiration date is earlier than the current date.

For SLM data migration, the Legacy SLA to new Agreement migration setting is provided. See the following tables for its details.

Default settings

Source Table  
Source Table sla
Target Table sla
Filter Condition true

Field Mappings

Source Field Target Field
agreement.id agreement.id
agreements agreements
category  
contacts contacts
current.phase  
customer customer
description description
display.category display.category
expiration expiration
external.support.groups external.support.groups

Value Mappings

Target Value Mapping Field Mapping Type Condition Target Value
category jsCallback   $value=lib.MigrateSLA.migrateSLA(sourceTable['agreement.id'])
current.phase fixedValue expiration>tod() agreed
current.phase fixedValue expiration<tod() expired
display.category jsCallback   $value=lib.MigrateSLA.migrateSLA(sourceTable['agreement.id'])

Related Records data migration

Process Designer-based related records retrieves information that is displayed in the related records columns directly from the screlation table. The table contains a large number of screlation records and the field values are generated based on legacy sccrelconfig settings. Therefore, you must perform data migration in order for the related records section to be displayed correctly.

An out-of-box script ("DataMigrationForRelatedRecords") is available to perform this data migration. To run the script, follow these steps:

  1. Open the Script Library and search for the "DataMigrationForRelatedRecords" file.
  2. Open the file and uncomment the following line:

    //migrateScrelations

  3. Execute the script. The data migration is performed automatically.

Note By default, only active screlation records are migrated (for time-saving purposes). Therefore, if you view inactive (closed ) records in the related records section, the wrong field value may be displayed.

To migrate all the screlation records, uncomment the following line, and then execute the script:

//var REFRESH_All_SCRELATION_RECORDS = "true";

If you have a large number (millions) of screlation records, the script may take hours to update all the records. Therefore, you must ensure that the Windows client session timeout setting is large enough for the script to complete.

Service Catalog data migration

Considering that Service Catalog does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode (especially for migrating a large volume of closed records).

The out-of-box example data migration is based on the following two key fields:

  • status
  • current.phase

Note You can add additional fields if needed, but do not remove these two fields. 

Default settings:

Source Table

svcCatalog

Target Table

svcCatalog

Filter Condition

null(current.phase)

Field Mapping:

Target Field

Source Field

current.phase

 

status

 

Value Mapping:

Target Value Mapping Field

Mapping Type

Condition

Target Value

current.phase

fixedValue

active="t"

Published

current.phase

fixedValue

null(active) or active="t"

Retired

status

fixedValue

null(active) or active="t"

Retired

status

fixedValue

active="t"

Operational

Configuration Item data migration

Considering that Configuration Item does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode.

The out-of-box example data migration is based on the following key field:

  • current.phase

Note You can add additional fields if needed, but do not remove these two fields. 

Default settings:

Source Table

device

Target Table

device

Filter Condition

null(current.phase)

Field Mapping:

Target Field

Source Field

current.phase

 

Value Mapping:

Target Value Mapping Field

Mapping Type

Condition

Target Value

current.phase

fixedValue

istatus=null or (istatus~="Missing" and istatus~="Retired/Consumed" and istatus~="Return for Maintenance" and istatus~="Return to Supplier")

Active

current.phase

fixedValue

istatus="Missing" or istatus="Retired/Consumed" or istatus="Return for Maintenance" or istatus="Return to Supplier"

Inactive

Re-index the knowledge bases

After you remove the Problem_Library_disabled_by_PDHD and KnownError_Library_disabled_by_PDHD knowledgebases, you must run a full re-index of the knowledgebases if you use Knowledge Management in a production environment.