Washington DC upgrade query

[JohnnySnow]

Hi Team,

We have recently upgraded our dev instance from Vancouver to W-DC, and there are few skipped logs with the disposition of Skipped Error. I have reviewed this article(KB0786212) and I'm setting the logs to Reviewed. However, I observed that few of the logs are not getting captured in the update set (neither in my custom update set nor in the default update set) but the details are saved properly.

Does any one know what the reason is? has some one faced similar issues?

[Robbie]

Hi @JohnnySnow,

Actions (Reviewed, Reviewed and Merged, Not Retained etc - I can't recall the full long winded wording of the actions) from the skipped logs are not captured in an update set by default. 

Up until a recent update from ServiceNow and the below link they needed to be managed per instance manually.

However, check the SN Support article which explains how to this.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0862487

@JohnnySnow- To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.

Thanks, Robbie

[JohnnySnow]

Thanks for the reply, I'll check and let you know how it went!

[Mark Roethof]

@Robbie Just trying to understand your reply. What do you exactly mean with "You'll need to do a little tinkering"?

Since a few releases, how Skipped records are handled is being captured in Update Sets and does not need to be done over and over on every single instance which is a good improvement on the Upgrade process. Though maybe we don't mean the same.

[Robbie]

Hi @Mark Roethof and thanks - It's a fair point that does need some clarification. Thanks. I'll make sure my response is clearer to follow.

For simplicity and people reviewing this in the future - its best to point out the newly provided steps to manage this: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0862487

(Steps also printed below in case links are broken which sadly tends to happen)

As you know, up until this update to the upgrade process, this was quite painstaking.

By 'tinkering' - I meant that over the many years I've come up with and seen a few solutions from manual recordings in spreadsheets (not ideal) to building reports and scripts - all of which were custom, unsupported and none ideal. There was no easy way.

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.

Thanks, Robbie

How to use multiple update sets to capture the decisions made for skipped upgrade records that span several scopes

Description
After reviewing the Skipped Changes list from an upgrade on a sub-production instance, you determine that you want to revert, retain, or merge a number of the records in the list.
The Skipped Changes list will likely contain records in several application scopes including global.
To avoid duplicating the effort on every instance that you upgrade, you can use one Update Set per scope to record your decisions and move them to another instance that has not been upgraded yet.

Release or Environment
All supported versions

Resolution
To capture the disposition of the scoped records after an upgrade, for the global scope and for each non-global scope, the process is to
1. change to that scope,
2. create a separate update set for that scope, 
3. reconcile the Skipped records in that scope,
4. commit the update set, and
5. export to XML to save the update set for that scope in a folder.
You'll have an update set for the globally scoped records and an update set for each scope that you will populate by capturing the disposition of the records that you reconcile for a particular scope.
Then to record the dispositions on a sub-production instance instance that is a copy of prod and is not yet upgraded, one by one starting with global, you'll
* change to each scope
* retrieve the update set for that scope, and 
* import the update set for that scope, preview it, and commit it
* upgrade the instance and ensure that the skipped records do not appear.

You will not need to reconcile the records again on that instance. On your production instance, repeat steps A through D.

Additional Information
For the records that you revert, the record will be captured in the update set with replace_on_upgrade=true, and after you complete that update set, and then load and commit the update set to a sub-prod or prod BEFORE the upgrade, then you will have REVERTED the record on test or prod to the out-of-box version BEFORE the upgrade, and then when you upgrade, the record won't show in the skipped records at all in test or prod -- it's already reverted.