The Zurich release has arrived! Interested in new features and functionalities? Click here for more

upgrade

velkuruhari
Tera Contributor

Hi All,

 

Good Evening/morning 

 

I have been upgraded my lower instance which is DEV environment to Yokohama Patch1 version. Post upgrade I am facing few issues. In Upgrade history skipped changes to review tab priority 2 changes are there.

 

velkuruhari_1-1743431581610.png

What should I do if this warning comes. should i go with review and retained or should i move to revert to base system. I don't have experience earlier regarding upgrade

 

Please do the needful.

 

Thanks & regards

Pavithra

 

 

 

1 ACCEPTED SOLUTION

Shivalika
Mega Sage

Hello @velkuruhari 

 

The correct person to answer this question will be the person who modifed this script include. OOB Script includes shouldn't be modified, should have created a new one. 

 

Now, since it was modified it's obviously skipped in the upgrade and recommendation is telling to retain the original version which is obvious. 

 

Kindly mark my answer as helpful and accept solution if it helped you in anyway. This will help me be recognized for the efforts and also move this questions from unsolved to solved bucket. 

 

Regards,

 

Shivalika 

 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

 

My youtube - https://youtube.com/playlist?list=PLsHuNzTdkE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

View solution in original post

3 REPLIES 3

Robbie
Kilo Patron
Kilo Patron

Hi @velkuruhari,

 

To put your mind at rest and provide context, "Skipped changes" are part and parcel of the upgrade process in ServiceNow.

Essentially, If a business rule or script for example has been customized or altered from the base system, a 'Skipped change' record is created. 

You essentially have 3 main options here.

1) Revert to the baseline version if appropriate. Select

2) Retain and ignore the customized code as it has currently been implemented

3) Merge - This is where you will merge the 2 versions together where you'll keep you're customized code where appropriate but also align to baseline code/functionality.

 

Only you/your team can make this decision based on your business requirements and instance implementation.

Wherever possible, ServiceNow best practice is to align to baseline code, however it is not uncommon to have customized code and in this instance you can retain and ignore skipped record. However, it would be a good idea to document or record why.

 

To process and make this decision - clock on the 'Resolve conflict' to review and analyze the difference between the baseline code and the update on your instance.

 

To help others (and for me to gain recognition for my efforts), please mark this response correct by clicking on Accept as Solution and/or Kudos.




Thanks, Robbie

Shivalika
Mega Sage

Hello @velkuruhari 

 

The correct person to answer this question will be the person who modifed this script include. OOB Script includes shouldn't be modified, should have created a new one. 

 

Now, since it was modified it's obviously skipped in the upgrade and recommendation is telling to retain the original version which is obvious. 

 

Kindly mark my answer as helpful and accept solution if it helped you in anyway. This will help me be recognized for the efforts and also move this questions from unsolved to solved bucket. 

 

Regards,

 

Shivalika 

 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

 

My youtube - https://youtube.com/playlist?list=PLsHuNzTdkE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

Brian Lancaster
Tera Sage

I always find it best to click resolve conflicts. There have been many times where a record was skipped because they system had it marked as something we customized event thought no changes were made. So when you click on Resolved conflicts it will compare it to the base system and the current version. If no changes were made you can revert to base without issue so you don't see this message again.

 

If changes were made then you need to work with the person who made them to determine if you want to go back to the base system or keep what you have.