Hi,

If your query is resolved, would you mind marking my answer as correct and close this thread.

 

Regards,

Shloke

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

mholmes
Tera Expert

As a follow-up, my plans crashed and burned because apparently, when reverting files from the "Skipped Changes to Review" interface, it does not care about application scope, but when you try to apply the update set to another instance, it cares very much.

I ended up with many preview problems of the form "Cannot commit Update Set 'Madrid Upgrade: Revert to Base System' because: Update scope id '{sys_id}' is different than update set scope id 'global'. Resolve the problem before committing." (I have an additional side problem where a handful of these conflicts are in scopes that are not accessible to me...how they were modified in the first place is anyone's guess, but the upshot is that I can't actually create an update set in the appropriate scope.)

All of this makes me leery of anything to do with "reverting" and Update Sets, so rather than go back and reassign each of my changes to a new, scope-appropriate update set (which is not even possible in some cases), I think I'm going to have to just go through and revert these items manually in each instance as I originally planned. At least I can export the file names from the Update Sets and use an "is one of" filter to do it quickly.

mholmes
Tera Expert

I changed my mind and ended up moving all but a handful of updates to new update sets in the appropriate scopes (except for the handful that I was unable to move).

After I promoted my changes, I performed some spot-checks by exporting some of the "reverted" files as XML from each instance and comparing them. The "manually" reverted ones are identical to the ones I reverted via update sets. So, it looks like I am as set as I can be until the next update.

mholmes
Tera Expert

As a follow-up, the first time we patched our QA instance after our major upgrade, we ended up with a bunch of "Skipped Changes." The development instance did NOT respond to the patch in this way.

What is puzzling is that at least the first couple of "Skipped Changes" I've reviewed do not seem to include any ServiceNow changes. I'm not sure why these are showing up at all, let alone in one instance and not the other.

Hi @mholmes ,

 

I am working on the upgrade for a new client and reverting to OOB and finding the best way to revert the updates. I am going through the same emotions like you did. Why are all these skipped if there are no changes? why did it allow me to update in global scope but cannot let me commit the changes. 😄

 

Just wanted to say thank you for asking this question and sharing your thoughts/approaches.

 

Thanks,
Mandar