Upgrade monitor skipped records after patch update

[pauladams]

Hello,

We have recently updated our development instance with patch Istanbul patch 10 C. I've looked at the upgrade monitor and have few questions for you experts:

1) After the upgrade, we have been testing the functionality we had before the patch and everything is working as expected. Do I still need to review the skipped updates and take action on them?

2) What does the priority of the skipped record indicate? Majority of the skipped records are Priority 5, few are 2, and a very few are 3 and 4. Does priority 5 mean take it easy and just ignore?

3) Do we need to repeat this exercise of reviewing the skipped records in all the environments as our Dev, UAT, Staging and Production instances are identical and it is likely to skip the same records in all the environments or can I capture the reviews in an update set and promote to the other instances?

4) If the reviews can be captured in an update set and can be moved to other environments, do I need to move the update set prior to the upgrade of the target instance?

5) Finally, what happens if I just leave them without reviewing?

Thanks

Pa

[Nia McCash]

Hi Paul, 

1. Yes, I highly suggest that you still review the skipped updates to see if any thing has been updated by ServiceNow, for example Business Rule code to use new API calls or more efficient code. You'll want to take advantage of such updates.
2. The Priority definition can be found in the documentation.
3. I typically ensure that Dev,UAT, and production have the same configs.  I review the skipped changes on dev, push the merged changes to UAT and production via update sets.  I also keep track of the reverted updates and manually revert those on UAT and production.
4. You will typically want to move the update set after upgrade of the target instance.
5. If you've tested and all of your required functionality are still satisfied, then I suppose there may not be a big issue but you may be missing out on new features and improvements from ServiceNow.  I find that keeping up with the updates makes each update easier.  For example, if I update the code in a Business Rule now to take advantage of new code introduced (even if I'm not using that particular piece of code), upgrades to future versions will be easier as there will be less of a difference to compare and consider.

[pauladams]

Thank you Niamcash. Very helpful.

If the review of the skipped records is captured in an update set and if I move that update set to a target instance, will not be required to review the skipped records again on the target instance? And the recommended way is to move the update set after the target instance is also upgraded?

Thanks for the link to the doc. However, I am not very sure I understand what the below mean. Can you please shed some light on these?

• 1 (highest priority): xml content
• 2: script or script_plain
• 3: html content
• 4: sys_ui_form_section, sys_ui_related_list, or sys_choice_set
• 5 (lowest priority): other

Thanks

Pa

[Nia McCash]

Yes, any records that you merge or modify can be moved to the target instance via upgrade set.  And you would move the update set after the target instance has been upgraded. 

But I believe any records reverted to base would need to be reverted on the target instance manually if you want them to be updated on next upgrade.

To be honest, I'm not sure what the rationale is behind the prioritization levels.  In my experience, much (but perhaps not all) of priority 5 items are records like Form Layouts, Application Menus, and System Properties,  which are likely customized for many instances and many instances most likely want to keep those customizations. 

I don't ignore priority 5 items in my review but I do find that I can scan through them quickly, and generally deal with them in groups by type (eg. I can NOT worry about skipped updates for 'Form Layout' type unless there's a particular form that catches my attention for whatever reason).

[Andras Kisgyorg]

Hi Niamcash,

In point (3) you say " I also keep track of the reverted updates and manually revert those on UAT and production."

Why it needs to be done manually, (reverting to Baseline version you mean?) is the version you revert to not captured similar way in sys_update_xml and thus in Update Set? 

Cheers,

Andras