Upgrade and migration tasks by application or feature

If you are upgrading, to the current release, from a release prior to Jakarta with the cloud plugins (com.snc.azure, com.snc.aws, and orchestration.vmware) activated on your instance and you decide to activate the Cloud Management plugin (com.snc.cloud.mgmt), then the cloud plugins activated prior to Jakarta may not work correctly. Do not use the cloud plugins (com.snc.azure, com.snc.aws, and orchestration.vmware) because they are deprecated. You must migrate all configurations, discovery schedules, and catalog items to the post-Jakarta Cloud Management plugin (com.snc.cloud.mgmt).

When you upgrade from previous releases, you may encounter an issue during Edge Encryption proxy server upgrades because the proxy has not yet been upgraded to handle newly introduced request and response codes.

Error:
2018-05-25 09:48:44,758 WARN  Unexpected response code 555 from the ServiceNow instance "10.11.87.4:16001". Will try again in 5 seconds.
2018-05-25 09:48:44,784 ERROR Update stats received error code : 555 : ServiceNow instance is currently being upgraded
2018-05-25 09:48:49,862 WARN  Unexpected response code 555 from the ServiceNow instance "10.11.87.4:16001". Will try again in 5 seconds.

The solution is to restart the proxy and then retry the proxy upgrade.

The upgrade process moves your instance to a new ServiceNow release version. Upgrading and patching your instance requires planning, testing, and validation. To ensure a safe and effective upgrade, create upgrade plans and test your upgrade on non-production instances before upgrading your production instance.

The Guided Tour Designer was first introduced in the Jakarta release with support for guided tours on the standard platform UI. For new instances created in Jakarta and beyond, guided tours are active by default. For instances originating from pre-Jakarta, guided tours are inactive by default. See Activate guided tours to enable the feature on your instance.

Legacy triggers are available only to upgraded instances. New activations of the MetricBase application do not include legacy triggers.

If you are upgrading from a pre-Jakarta release and want to enable randomized watermarks in email notifications for upgraded instances, activate the Random Watermark Support plugin (com.glide.email.random_watermark). This plugin includes system properties for managing a watermark transition period, during which the system recognizes both randomized watermarks and non-randomized watermarks in emails created before upgrading. For details, see Notifications upgrade information.

After upgrading to London, the default Event Management binding workflow which binds nodes to host CIs, is disabled for metric events. If you relied on this binding before the upgrade, then to allow host binding for metric events after upgrade, explicitly create a host binding event rule as described in Create an event rule to map metrics to host CIs.

Before upgrading, you should be aware of changes made to the underlyingService Catalog data model. These changes affect the way that you implement multiple service catalogs. For details, see Upgrade to multiple service catalogs. If you are upgrading from a version prior to the Fuji release, see Migrate cart layouts.

If you have completed an upgrade from Jakarta or Kingston to London, navigate to System Definition > Fix Scripts, run the Update integrations to multi domain fix script to allow certain integrations to have multiple configurations defined. For example, if you have multiple Splunk instances, you can create connections and queries that run Sighting Searches across multiple Splunk instances. After the fix script has run, return to System Definition > Fix Scripts and deactivate the fix script. It is important that the script not be allowed to run more than one time.

Platform feature – upgraded by default.

The List v3 plugin is no longer available for new deployments.

For releases prior to Kingston, during upgrade the Vulnerable Item table is reparented to improve performance. If you have large numbers of vulnerable items, the upgrade process may take additional time. No special handling is needed, however, you should stop any Vulnerability Response activities prior to upgrade and record your vulnerable item count. Once complete, verify that your pre- and post-upgrade vulnerable item counts match each other. For more information on the impact of reparenting, see the Upgrade impact of reparenting change in the Kingston release [KB0680550] article in the HI Knowledge Base. For information on the upgrade impact to existing instances, see the Vulnerability Response: FAQ for Kingston Upgrade [KB0680543] article in the HI Knowledge Base. This information does not apply if you upgrade from Kingston to this release. For Kingston release information, see Kingston Vulnerability Response release notes.

To reduce upgrade time, if you have Qualys or a third-party integration installed, delete all attachments on your integration data sources. You can find the attachments by navigating to System Import Sets > Administration > Data Sources and searching by integration. See Manage attachments for more information.

Existing CI Identifier Rules are disabled by default but not removed. They appear in Security Operations > CI Lookup Rules. To reenable, open a rule and enter values for Source and Source field, select the Active check box, and click Submit.

When upgrading from a version prior to Kingston, the Vulnerable Items by Remediation Target Status report does not appear in the Vulnerability Response Overview and must be added manually.