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).

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

• status
• category
• current.phase

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.

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”.

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.

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

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

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.