Upgrade > Upgrade the applications from a version earlier than 9.60 > Applications major upgrade overview

Applications major upgrade overview

The following sections describe how to upgrade your Service Manager applications to 9.61 by using the Service Manager 9.61 Upgrade Utility.

Before you begin an upgrade

Before you begin an upgrade, ensure that you:

  • Read through the upgrade documentation to familiarize yourself with the upgrade process and all of the upgrade requirements.
  • Are an experienced system administrator who is familiar with Service Manager.

If you do not have the administrative experience necessary to manage the upgrade, you may need assistance from your local applications developers and database administrators. You can also contact Service Manager Customer Support for help with troubleshooting upgrade errors. For additional information and support, contact your software sales representative.

Applications upgrade

You can upgrade your existing Service Manager applications to version 9.61 applications using the Upgrade Utility and resolving the differences between the two versions.

What are applications?

Applications are the Service Manager modules and their related configuration files. For example, Incident Management and Change Management are Service Manager applications.

New features that require an applications upgrade

Some new features provided by the release of Service Manager9.61 require an applications upgrade. The following new features provided by the release of Service Manager9.61 require an applications upgrade:

  • Enhanced Service Desk, Incident Management, Problem Management, Change Management, Request Fulfillment Management, Service Catalog Management (provided since Service Manager 9.50), and Service Level Management based on Process Designer (provided since Service Manager 9.40)
  • Process Designer framework
  • Smart Analytics (provided since Service Manager 9.40)
  • Smart Analytics Smart Ticket tuning toolkit (provided since Service Manager 9.60)
  • Smart Analytics search accuracy improvement (provided since Service Manager 9.60)

  • Mobile Applications
  • Service Request Catalog (SRC)
  • Case exchange
  • Smart email
  • Service Portal (provided since Service Manager 9.50)

  • Simplified interaction (provided since Service Manager 9.41)

  • Logical Name (provided since Service Manager 9.41)

  • Smart Search (provided since Service Manager 9.41)

  • Service Manager Collaboration (provided since Service Manager 9.41)

  • Accessibility for the embedded Service Manager Calendar
  • Service Manager Reports (provided since Service Manager 9.40)
  • Service Manager Survey (provided since Service Manager 9.40)
  • Entity Relationship Diagram (ERD and Data integrity check) (provided since Service Manager 9.40)
  • The Primary Key and Not Null constraints (provided since Service Manager 9.32)

Applications upgrade lifecycle

You can use three environments to complete the upgrade process: your current production environment, a new development environment, and a new test environment. You will duplicate your production environment to create the development and test environments. Run the out-of-box upgrade and create the custom upgrade on the development environment, and then run and test the custom upgrade on the test environment before you apply it to your production environment. The figure below provides an overview of the steps in the upgrade process.

The following flow chart illustrates the lifecycle of a typical upgrade of Service Manager applications.

Upgrade phases and sub-phases

The following table describes the phases and sub-phases in the entire applications upgrade lifecycle. These sub-phases are logged in the upgrade log files during the upgrade. When an error occurs, the log files can help you find out during which phase and sub-phase the error occurs.

Phase Sub-phases
Planning and preparation
  • Load Transfer
Running an out-of-box upgrade
  • Pre Upgrade Action Check
  • Pre Upgrade Action Update
  • Pre Upgrade Action Purge
  • Pre Upgrade Action
  • Load Upgrade File
  • Upgrade Dbdicts
  • Load Upgrading Data
  • Upgrade Data
  • Post Upgrade Action
  • Post Upgrade Action Prior to SM940
  • Post Upgrade Action Prior to SM950
  • Post Upgrade Action Prior to SM960
  • Post Upgrade Action Auto Merge
  • Post Upgrade Action Purge
  • Post Upgrade Action Update
  • Post Upgrade Action Notification
  • Post Upgrade Action Restore
Creating a custom upgrade
  • Pre Create Action Check
  • Build Signatures
  • Build Distribution
  • Export Data
  • Transfer Data
Applying the custom upgrade
  • Pre Upgrade Action Check
  • Pre Upgrade Action Update
  • Pre Upgrade Action Purge
  • Pre Upgrade Action
  • Load Upgrade File
  • Upgrade Dbdicts
  • Load Upgrading Data
  • Upgrade Data
  • Post Upgrade Action
  • Post Upgrade Action Prior to SM940
  • Post Upgrade Action Prior to SM950
  • Post Upgrade Action Prior to SM960
  • Post Upgrade Action Purge
  • Post Upgrade Action Update
  • Post Upgrade Action Notification
  • Post Upgrade Action Restore

How does customization affect the upgrade process?

The following explains how customization affects the upgrade process.

Conflicts

Object changes: The Upgrade Utility compares the objects in your database with their out-of-box versions and the corresponding objects provided from the upgrade package. The Upgrade Utility compares objects by their signatures. Each data record in Service Manager has a unique signature, which changes once that data record is updated. When processing object changes, the Upgrade Utility behaves as described in the following tables.

Changed object
Object in DB has been tailored? OOB version of object matches upgrade package? Out-of-box upgrade Custom upgrade
Yes No

The Upgrade Utility tries to merge the object from the upgrade package with your tailored object. If the merge is successful, the Upgrade Utility marks the new merged object as "Auto Merged." If the merge fails, the Upgrade Utility marks the object as "Renamed." In both cases, the Upgrade Utility prefixes the object from the upgrade package with "NEW961," and then copies the object to your database and prefixes that object as "PRE<version_number>". For example, an object from applications version 9.31.0022 PDCP4 would be prefixed with "PRE9.31.0022_PDCP4".

The Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object in its revision.
Yes Yes

The Upgrade Utility keeps your local version, even if your version has been tailored and marks your local version as “Kept Customer”.

The Upgrade Utility marks your local version object as “Already Current.”
No No

The Upgrade Utility overwrites the object in your database with the object from the upgrade package, and marks the object as “Upgraded.”

The Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object in its revision.
No Yes The Upgrade Utility marks the object as "Already Current" regardless of whether this is the first upgrade or a custom upgrade.
Added object
Object is added in ... Behavior Note
DB The Upgrade Utility always keeps your local version and does nothing else. The object in your database does not have a corresponding object from the upgrade package.
Upgrade package The Upgrade Utility adds the object to your database and marks the object as "Added" regardless of whether this the first upgrade or a custom upgrade. The object from the upgrade package does not have a corresponding object from your database.

Dbdict changes: The Upgrade Utility automatically adds new dbdict and merges new fields to existing dbdicts. The Upgrade Utility does not delete any existing field. For field and key changes, check "Field mapping changes" and "Key changes."

Field mapping changes: Normally the Upgrade Utility applies field mapping changes automatically, but there may be some exceptions. For example, when a length change is required, the Upgrade Utility automatically expands the length mapping. However, if the field mapping is a LOB-type change, the Upgrade Utility will not the change the type mapping. For detailed exceptions, check SQL Field Compare results before the upgrade and the except.log file after the upgrade.

Key changes: Normally the Upgrade Utility applies key changes automatically, but there may be some exceptions. For example, the Upgrade Utility automatically adds a new key and updates the existing key of the pre-upgrade out-of-box version. However, if a Unique key has been tailored, the Upgrade Utility will not apply the key change. For detailed exceptions, check the SQL Unique Key Compare Results before the upgrade and the except.log file after the upgrade.

Customization during upgrade

If any tailoring changes are made to your production system, for example, by applying an applications "hot fix," after you have initiated the upgrade process, it is highly recommended that you apply those same changes to the development system that is being used for conflict resolution before you create the final custom upgrade package. Or, these tailoring changes may be lost after the custom upgrade has been applied to production, and any conflict resolution that needs to be done in a production environment may slow down the production upgrade.

Upgrade Utility contents

The following table lists the files that are included in the Service Manager Upgrade Utility.

List of Upgrade Utility files
File Contents

AppUpgVersion.txt

Contains Upgrade Utility version and build number information to help you identify which applications upgrade version you have available. For example:

A version of "SM930-9.61.00xx v9.6100xx Upgrade Build 00xx" indicates the following:

  • The Upgrade Utility upgrades Service Manager 9.30 and later releases to Service Manager9.61.
  • The Upgrade Utility version number is 9.61.00xx.
  • The Upgrade Utility build number for this version is 00xx.

preupg.bin

Files that allow you to access the various features of the Upgrade Utility.

transfer.bin (in the package\<version> folder)

Files that allow for the execution of the upgrade.

sqlupgrade.unl

Files that allow you to run SQL compare, a feature of the Upgrade Utility.

Note preupg.bin includes the files in sqlupgrade.unl. To run SQL Compare, you do not need to load sqlupgrade.unl again after you load preupg.bin.

upgrade.inf (in the package\<version> folder)

Signature information for the upgrade objects.

upgrade.str (in the package\<version> folder)

Database dictionaries to be upgraded.

upgrade.ver

Version stamp for this upgrade.

*.dta (in the package\<version>\data folder)

The data files for each table that needs to be upgraded. For example, upgradeactivityactions.dta and upgradeactivitytype.dta.

upgrade.mak (in the package\<version> folder)

Signature definitions for the upgrade objects.

upgdbdct.dta

Temporary dbdicts needed for the SQL Compare process.

DeltaMigrationTool.unl

Files that allow you to run Delta Migration Tool.
.zip (in the 3waymerge\oob folder)

Each zip file includes the XML representation of the objects that have been signatured in the pre-upgrade out-of-box version for the Three-Way Merge tool.