Missing Upgrade Skipped List

[ben_tes]

Our Prod instance was automatically upgraded and now has a skip list of ~300 items. 

I've cloned this to our test system but now I cannot get to the Skipped List? 

[Erik Stolberg · Accepted solution]

The table "sys_upgrade_history_log" is on the Exclude Tables list under Clone Definition (i.e. it won't copy over during a clone). You will need to export those 300 items and import into your test instance. I'm not 100% sure this will work, however:

Note: The system tracks changes to records in an update set so you can apply these changes to another instance later. However, the system does not migrate the upgrade details records from one instance to the next. These records apply to a specific upgrade of a specific instance. If you want to preserve the Comments, Resolutions, or other information from the skipped list, export it from this instance.

https://docs.servicenow.com/bundle/kingston-platform-administration/page/administer/platform-upgrade...

[ben_tes]

Perfect, thank you. Obviously didn't read this thoroughly enough!

[Les1]

We're doing our first upgrade.

I'm a little confused about how to handle skipped record list after the first sub-prod instance (we've done DEV, now moving to TEST).

in Test we'll get a Skipped Records list. We already went thru this list in DEV. From the doc it seems to imply a quick method of applying the decisions made in DEV to the next instances in Upgrade. 

so just to clarify: When i look at the default update set in DEV i dont see anything that looks to be capturing a skipped record resolution (retain, merge etc).   So in TEST does one simply ignore the Skipped Records processing(as was done in DEV), and just apply the update sets as they would have captured if a record had a Merge or Revert action applied?   

sry for my confusion and thank you in advance!

[SanjivMeher]

I wouldn't bother about the skipped records.

Once I upgrade Dev,  I should do a testing of all the functionalities, identify bugs and fix any bugs and capture them in an update set. Then upgrade test environment and apply those update set fixes and take sign off from all the module owners.