How can I revert customized OOTB script to Store version if this script was committed via update set on all instances

[Alex150]

Hello,

ServiceNow recommended set "Replace on upgrade" to true on Custom Updates table if OOTB script was changed It's a good way if it was done before an upgrade, but what should we do if an instance has already upgraded? I wonder if there is a different way to do it? 

What do you think? What is the best practices? 

[james_kail]

We used to not change the OOTB elements, but that makes doing skipped records review significantly more complicated and takes longer. For example, if you copy a script and add your changes, ServiceNow cannot do a comparison on the cloned version in the Skipped records review. You will manually have to keep track of each copy you made and then use external tools to compare what is different between your version and the incoming version. As a matter of fact, if all you do is update the active flag on the OOTB element, many time it will not even appear on the skipped records review and you will have no idea that an element was updated.

Please note: Not all elements can be changed directly as ServiceNow locks some of them down. But,  things likes scripts, business rules, etc... can be edited. By updating the ServiceNow version we can utilize the ServiceNow skipped record tools to review incoming changes to existing code. We can in a single click copy incoming code to the existing code, or revert back to OOTB is we want.  The skipped records comparison tool is very useful for use.

In the ServiceNow training site they have a module to walk you through doing skipped records review and I believe I saw in there that even ServiceNow reversed its statement on never touching OOTB elements. 

We have been updating OOTB components for about 6 years now (granted we try to limit what we update), but we only allocate 4 weeks to do the entire migration from one version to the next. We have just started our Quebec Upgrade last week and in we were able to process our 239 skipped records in 4 days because we were able to take advantage of the ServiceNow skipped records comparison features. If we had cloned all of these elements, we would still be doing the comparisons to see if there was ne code we wanted to incorporate. 

The decision to copy or not in up too you, but we have found we are much more productive not making copies of all the OOTB elements when possible.