Mandatory manual migration tasks

Review the migrated validity records

After you migrate to Service Manager Hybrid, validity records are validated against the Process Designer category tables instead of the Classic category tables. Therefore, a manual review of the validity records is required.

A Process Designer migration report that resembles the following is included in the pdmigration.log file:

The following validity records are updated to perform validation against Process Designer-based category tables (such as category, subcategory, and producttype) instead of legacy category tables. Backups of the original validity records (identified by the suffix "_disabled") have been created.
Unique ID:BP;Field Name:category;Sequence:1
Unique ID:BP;Field Name:category;Sequence:3
Unique ID:BP;Field Name:incident.category;Sequence:3
Unique ID:BP;Field Name:product.type;Sequence:1
Unique ID:BP;Field Name:product.type;Sequence:2
Unique ID:BP;Field Name:product.type;Sequence:3
Unique ID:BP;Field Name:product.type;Sequence:5
Unique ID:BP;Field Name:product.type;Sequence:7
Unique ID:BP;Field Name:product.type;Sequence:10
Unique ID:BP;Field Name:product.type;Sequence:13
Unique ID:BP;Field Name:subcategory;Sequence:1
Unique ID:BP;Field Name:subcategory;Sequence:2
Unique ID:BP;Field Name:subcategory;Sequence:3
Unique ID:BP;Field Name:subcategory;Sequence:5
Unique ID:BP;Field Name:subcategory;Sequence:11
Unique ID:BP;Field Name:subcategory;Sequence:12


The number of updated validity records depends on your system configuration. If you have not customized any validity records, you can ignore this step.

Review the category-based alerts migration

Stage 1, 2, and 3 alerts and deadline alerts

The Applications Upgrade Utility migrates the Classic Stage 1, Stage 2, Stage 3, and Deadline alerts and Deadline Alert Group configurations from Classic categories to the workflow phases of the automatically-generated Incident workflow.

The migrated alerts are named according to their source. For example, "Incident Alert Stage 1 for complaint" indicates that the alert is converted from stage 1 configuration of the complaint category. The following types of alert are created:

• Incident alert stage 1 for <category name>. This alert updates the incident alert status to "alert stage 1" if the category has a stage 1 interval or expression specified.
• Incident alert stage 2 for <category name>. This alert updates the incident alert status to "alert stage 2."
• Incident alert stage 3 for <category name>. This alert updates incident alert status to "alert stage 3."
• Incident Deadline for <category name>. This alert updates the incident alert status to "DEADLINE ALERT."

The migrated alerts are located in the alerts tab of each workflow phase.

Gap and limitations

The migrated alerts implement the main functionality of the Classic alerts; however, there are some gaps and limitations.

• In Classic category-based alert expressions, "$file" represents the incident. The Applications Upgrade Utility automatically modifies "$file" to "$L.file" for compatibility with the migrated alerts. If you use other variables in your Classic system, you must manually modify the expression in the migrated alerts.

• The timing for the generation of stage 2 and 3 alerts is different. In the Classic Incident module, the schedule for stage 2 is generated after the schedule for stage 1 is executed and the incident alert status is updated to stage 1. Likewise, the schedule for stage 3 is generated after the schedule for stage 2 is executed and the incident alert status is updated to stage 2. In Hybrid mode, however, all schedule records for stage 1, stage 2, stage 3, and deadline alerts are generated or re-generated at the same time, when the incident record is updated.

  Therefore, if you are using an expression that uses the content of the current record ($file) as either the condition or the calculation for the alert time in stage 2, stage 3, or deadline alerts, issues may occur because the content of the current record can differ when the schedule is generated.

• The migrated alerts are moved to the alerts list of the "In Progress" phase of the migrated Incident workflow. If you add new phases, you need to also add these alerts to new phases so that the alerts can work for incident in the new phases.

• The alert reset and recalculation conditions in objects are changed in Hybrid mode. Therefore your original alerts may not work. For example, the out-of-box alert reset condition in the Classic probsummary object is category in $L.file="incident" and not (null(1 in external.process.reference in $L.file)). If you use this condition, alerts only work for incidents that are assigned to the incident category. In the migrated probsummary object, the condition is evaluate(nullsub(parse(str(alertsReset in $L.wfPhase), 2), false)) or not (same(current.phase in $L.file, current.phase in $L.file.save)), and the alert reset condition of the "In Progress" phase is set to "true." Therefore, all alerts configured in the phase will work for all incidents rather than only for incidents that are assigned to the incident category.

  In this case, you can modify the schedule condition and the alert condition in the existing alert definition of the Incident Management module by appending the original reset condition that is configured in the Classic object.

Reassignment threshold

The reassignment interval and expression and the reassignment count threshold in the Classic categories are not migrated automatically.

If you still need reassignment threshold functionality, you can add the relevant fields to the new Process Designer-based category file and form, and then copy the configuration to the new Process Designer categories. The following table lists the fields that you will need to add.

Field name in dbdict	Data type	Label in form/description
count	number	Reassign Count Threshold
reassign	date/time	Reassignment Interval
reass.expression	expression	Reassignment Expression

Review Change Management processes

Renamed processes

The following two Classic processes in DocEngine are renamed by the Applications Upgrade Utility. The old Classic names are now used for Codeless processes.

Process name in Classic mode	Process name in Hybrid mode
cm.open	cm.open.classic
cm.open.save	cm.open.save.classic

Therefore, if you have made any customizations to the processes, a conflict with the new name will be reported in the upgrade results (for example, if you customized “cm.open”, this process will be renamed to “cm.open.classic” and will conflict with the out-of-box “cm.open.classic”.) Additionally, if you have made any customizations that call the Classic processes, you must update these to call the new process names.

Review "Close Phase"

In the migrated Change Management workflow, the "Close Phase" functionality is moved to transitions between phases. In Classic versions of Service Manager, the "close" display option closes intermediate phases and closes the change or change task in the last phase. In the migrated Change Management workflow, the "close" display option closes only changes or change tasks in the last phase in the workflow.

The following condition is added to the original condition of the "cm.view.display_close" display option:

($G.pd.change.enabled=false or index(current.phase in $L.file, phases in $L.category)=lng(denull(phases in $L.category)) or category in $L.file="Unplanned Change" and current.phase in $L.file="Discovery Assessment") and

If you have tailored this display option, or if you have configured other display options to perform the "close" action, you must make equivalent modifications to ensure that the close action only works for last phase.

In Hybrid versions of Service Manager, display options are not called during the "close" phase. Therefore, the "cm.view.display_close" display option code is migrated to the "cm.save.wrapper" process, as illustrated by the following image. If you have tailored this display option, you must make equivalent changes to the process.

In out-of-box Hybrid versions of Service Manager, the transition between phases is named "Close Phase". However, you can modify the label to suit your needs by using the localization functionality in the Workflow Editor.

Modify $L.env to $G .cm3r.environment/$G.cm3t.environment

In the Classic Change module, $L.env is a "cm3profile" record, whereas in Hybrid Change it is a "tableAccess" record. Therefore, references to $L.env are updated to refer to $G.cm3r.environment/$G.cm3t.environment, in case a "cm3profile" record is required (the $G.cm3r.environment/$G.cm3t.environment global environment variable contains the same content as the Classic version of the $L.env record).

In out-of-box Hybrid versions of Service Manager, all the related display screens, display options, and processes in the Change Management module are updated. For example, in "cm.view.display_reopen", evaluate(reopen in $L.env) is updated to (filename($L.file)="cm3r" and evaluate(reopen in $G.cm3r.environment) or filename($L.file)="cm3t" and evaluate(reopen in $G.cm3t.environment)).

However, you must make equivalent updates for any tailoring you have made that uses $L.env as a "cm3rprofile" record.

Revert to status-based SLM for Change Tasks

Service Level Management (SLM) for Change Tasks in Codeless versions of Service Manager is based on phases, whereas in Classic versions it is based on statuses. Therefore, you must revert to status-based SLM for Change Tasks in order for your existing SLAs to work with the migrated workflows.

To do this, follow these steps:

1. In the System Navigator, click Service Level Management > Administration > Configure Application.
2. In the Table Name drop-down list, select cm3t.
3. In the Process Target Information section, click to clear the Use Phases option, and then configure the Process Target State Progression and Standard Alerts fields as required.

Review the "form edit" condition in workflow phases

The “form edit” condition in Process Designer-based workflows determines whether a form is editable when a user views a record. In Service Manager Classic, this control condition may be located different places. When the Applications Upgrade Utility creates the migrated workflows for Hybrid mode, the condition settings are migrated from the default location of the condition in Service Manager Classic:

• Service Desk: The condition is copied from the state input condition
• Change: The condition is copied from the legacy change phase

If you have configured the condition in any other location, it will not be automatically migrated. In this situation, you must manually combine the Classic condition settings into the “form edit” condition.

Merge the status lists

The Applications Upgrade Utility implements the Process Designer search form and the Process Designer status list. Therefore, you must merge the Classic status list into the Process Designer-based status list.

The following table describes the table in each module that you must update, along with information about the Globallist, the Globalvariables, and where the data comes from.

We recommend that you modify the data in the ModuleStatus database according to your needs. For example, you must update the ModuleStatus list for the Incident module to add or remove statuses according to your requirements.

Module	Global list name	Process Designer statuses global list variable	Details
Incident	Incident Local Statuses	$G.imStatuses	Retrieve from file ModuleStatus with Limiting SQL module="probsummary"
Service Desk	Interaction Local Statuses	$G.sdStatuses	Retrieve from file ModuleStatus with Limiting SQL module="incidents"
Problem	Problem Local Statuses	$G.pbmStatuses	Retrieve from file ModuleStatus with Limiting SQL module=" rootcause"
Problem	Problem Task Local Statuses	$G.pbmTaskStatuses	Retrieve from file ModuleStatus with Limiting SQL module=" rootcausetask"

Update the eventin service

If you use the eventin service to create Incidents, and if the RAD applications of your Event Register for creating the Incidents is set to "axces.apm," you must check whether the "add" action in the document engine's state records action blocks externally-created Incidents.

To do this, first identify which process maps to the "add" action in the Classic Open State. The following illustration uses the im.first process as an example from an out-of-box system.

In out-of-box systems earlier than Service Manager 9.41, only the "problem" and "EXTERNAL" operators have permission to add Incident records from the backend.

Make sure that the User IDs of your eventin services are configured as demonstrated in the following image.

Alternatively, make sure the User IDs of your eventin services are not blocked. To do this, you can change your code to allow all backend operations, as illustrated by the following image.

If you use the following applications in your event register, the relevant eventin services are now allowed to trigger the Process Designer rule sets.

RAD applications	File	Out-of-box event registers
axces.apm	probsummary	pmu: problem update pmr: problem reopen pmo: problem open pmm: problem mibile checkout/in pmc: problem close ... (total 19 eventregisters)
axces.apm.epmosmu	probsummary	epmosmu: e problem open smu
axces.sm	incidents	esmin: e service management smin: service management
axces.cm3	cm3r cm3t	cm3rin cm3tin ... (total 14 eventregisters)

Replace the environmental variables

In Service Manager Classic, the $L.env variable stores the profile record. However, in Service Manager Codeless, the $L.env variable stores the tableAccess record. Therefore, all code in the Change Management module that uses the $L.env variable (mostly, this relates to Display Options) must be updated to use the $G.cm3r.environment or $G.cm3t.environment variables.

For example, the display condition of the cm.view.display_approve display option must be updated as follows:

Original:

evaluate(approvals in $L.env)

After update:

evaluate(approvals in $G.cm3r.environment) or evaluate(approvals in $G.cm3t.environment)