Best way to review skipped updates in Upgrade Monitor prior to platform upgrade?

Ant1
Giga Guru

We are looking to upgrade our production instance from Geneva to Helsinki, but prior to doing so, we have been looking through the Upgrade Monitor and noticed that we have a significant number of Skipped Updates that need to be reviewed.   As you open each skipped update, there is the option to Resolve Conflicts or Revert to Base System.   When selecting Resolve Conflicts, you are shown something similar to a before and after from which you can act.   Our issue occurs when we encounter something which seemingly looks straightforward, and when resolving the conflicts and either merging the changes or reverting them we come across issues that don't even seem to be related.   For example, we ran through a few of the updates, none of which mentioned changing any ACLs or roles in any way, and afterward, we found that our admin roles lost some of its abilities to do things like delete items in the list view or even modify Homepages.   Upon submitting our issue with hi.service-now.com we were told that we had inadvertently made changes to something that could possibly have some code which also affects things not necessarily obvious in those updates we were going through.   It's a little concerning knowing that we could be affecting other important things on the platform without even realizing it.   There are also some updates, which when reviewing, we have no clue what they do.   Are we just supposed to ignore these and just mark them as reviewed?   Are we even supposed to be addressing any of these skipped updates prior to upgrading to Helsinki or any other future version?   In any of the Knowledge sessions I've been to regarding upgrades I don't know that I've ever seen the Upgrade Monitor process ever mentioned.   If possible, we're looking for some kind of "official" word on what the best practice is for addressing all of the skipped updates prior to doing an upgrade.

Thanks!!

1 ACCEPTED SOLUTION

robpickering
ServiceNow Employee
ServiceNow Employee

Great information here on the Wiki:


Upgrades Best Practices - ServiceNow Wiki



Good article with some additional information may be found here:


Upgrading ServiceNow? — ServiceNow Elite



From my personal experience...skipped updates are going to be a fact of life once you start down the path of customizing.   If those customizations are not handled in a "Best Practice Fashion", then you will end up modifying "out of box" capabilities, that at upgrade will be skipped.



This will be exacerbated if you don't review the skipped updates each time you upgrade and resolve them, as you'll end up with potentially multiple layers of skipped updates.



The best solution is a rigorous SDLC process for your ServiceNow instance where you document Update Sets, Stories, Sprints, and Releases with notes explaining the reasons why things were changed.   As the platform matures, those updates may be able to be removed so you can take out-of-box behaviors again.    



However, also keep in mind that some updates being skipped are "okay".   If you've customized a form and then that form is later updated by ServiceNow, and the update is skipped, that's fine.   Business Rules, maybe not so much...



In my time as a customer, we only had 1 time over 3 years (and 4 versions of ServiceNow, plus various patches) where I had to go back and revert an update we had made to out-of-box.  



My process was to look at the updates, then refer to my Release Notes / Sprints / Stories / Update Sets to understand why the update was made and if it could be reverted (we may have added functionality that the base platform now provided, or we like the base platform functionality better).   I never had an upgrade fail due to these updates...



-Rob


View solution in original post

2 REPLIES 2

robpickering
ServiceNow Employee
ServiceNow Employee

Great information here on the Wiki:


Upgrades Best Practices - ServiceNow Wiki



Good article with some additional information may be found here:


Upgrading ServiceNow? — ServiceNow Elite



From my personal experience...skipped updates are going to be a fact of life once you start down the path of customizing.   If those customizations are not handled in a "Best Practice Fashion", then you will end up modifying "out of box" capabilities, that at upgrade will be skipped.



This will be exacerbated if you don't review the skipped updates each time you upgrade and resolve them, as you'll end up with potentially multiple layers of skipped updates.



The best solution is a rigorous SDLC process for your ServiceNow instance where you document Update Sets, Stories, Sprints, and Releases with notes explaining the reasons why things were changed.   As the platform matures, those updates may be able to be removed so you can take out-of-box behaviors again.    



However, also keep in mind that some updates being skipped are "okay".   If you've customized a form and then that form is later updated by ServiceNow, and the update is skipped, that's fine.   Business Rules, maybe not so much...



In my time as a customer, we only had 1 time over 3 years (and 4 versions of ServiceNow, plus various patches) where I had to go back and revert an update we had made to out-of-box.  



My process was to look at the updates, then refer to my Release Notes / Sprints / Stories / Update Sets to understand why the update was made and if it could be reverted (we may have added functionality that the base platform now provided, or we like the base platform functionality better).   I never had an upgrade fail due to these updates...



-Rob


Rob thank you for providing your experience in how you handled the updates prior to the upgrade process.   We are definitely going to be more diligent about reviewing the updates more thoroughly from this point on.   During our initial implementation of ServiceNow, the SN partner we were using had to customize several many things for us, and I imagine some of the out of box features were included in these modifications, so we will have to be very careful.