Skipped updates appear to have no conflicts

[mansfis]

Apologies if this is in the wrong space, I'm still very inexperienced!

I'm looking at upgrading our live instance to Geneva, and I'm looking at resolving the Skipped Updates on our test system. Searching through them some appear to have no conflicts - is this correct, or am I missing a conflict I can't see? If this is correct, why would the update be skipped (it is not skipped error)?

Thanks in advance.

[peterraeves]

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.

I have no clue when records are "Skipped Error". That's what I'm trying to figure out right now. as most of the skipped errors are just System Properties.

[David Harding]

I am having the same issue.   Lots of updates marked as skipped, but when looking at them, there are no local customisations, no conflicts and the update history shows no mention of changes by a local user.

Why are these updates being flagged and skipped?

What is the best way to deal with all of these updates?   I've read the wiki page here http://wiki.servicenow.com/index.php?title=Upgrades_Best_Practices#gsc.tab=0   but it seems to be a very time consuming process to review them, especially when there are so many skipped updates that were not local customisations.

Did you establish a way to handle these updates, Sean?

[mansfis]

Hi David,

In the end, I did manually check each one, which amounted to around 430 skipped updates. It was time consuming but following Peter's advice on reverting those changes which had no differences, I managed to complete it in around 6 hours.

The instance I upgraded happens to have quite a few messy customisations I've inherited, so my general rule was to retain customisations as the customisations are important to maintain business processes. If you have a similar number, or even more as our instance is only 3 years old and has a relatively small incident throughput, this could take you a rather long time if you don't have an obvious rule like "retain all customisations unless there are no changes" as I did. As I understand it, the only risk to not doing it is the potential miss of new functionality, so if you aren't looking for lots of new features, you may decide to leave all customisations as is.

[David Harding]

Thanks Sean.

I think what is confusing me is the number of apparent customisations that have 'updated by' as system or ServiceNow developer IDs.   These appear to be linked to various plugins.   Does activating a plugin on an instance register as a customisation that will be skipped in these updates?