"Revert to Base System" Changes Captured in Update Set, Do These "Count" as "Reverted" When Promoted to Production?

[mholmes]

My understanding is that if I address a "Skipped Change" by selecting "Revert to Base System," the record in question will no longer be considered "Customized" and will not be skipped in a future update.

Question 1: Is this correct?

Question 2: I have noticed that when I "revert" a change, this is captured in an Update Set. If I promote this Update Set to my production instance, will it be considered "Reverted" in the same way as if I reverted it "in place" in Production?

Question 3: How does the upgrade process determine if something needs to be "Skipped" or not? I found a community post that explains "An upgrade will skip every record that was ever customized/changed. If you change any field it will be flagged "Customer updated" and will be skipped. The merging does not happen in a smart way, it just checks whether the record was flagged. So imagine that you have changed a string field from "foo" to "bar" and back to "foo". The value would be the same as OOTB, but the record has been updated, so will be skipped. Therefore, you should revert instead of just changing the value back." However, I can't find anything that looks like an indicator of "Customer updated," including when I exported the record as XML. The only "interesting" thing I could see on the record was that the "sys_updated_by" field was changed to "maint."

Essentially, I'm trying to figure out if it's a good idea to push these "reversion" changes to production in update sets, or if it would be better to perform the reversions again in production directly. (I suppose I could do this semi-efficiently by filtering based on file names if necessary.) I've inherited a large number of "false positive" records that were changed and then changed back without being "reverted," and they complicate my upgrades, so I would like to put them to rest once and for all.

[mholmes]

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]

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.

[ohhgr]

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