Overview
Over the, almost, ten years I have been in this ecosystem I have realised that many customers think that upgrading an instance is as simple as scheduling it and leaving the ServiceNow automated process do the rest. Although that is the first part of it, there is a second part many customers forget about.
When there is a ServiceNow SME around, this will recommend having a look at the skipped changes left behind during the process, but customers sometimes do not have the right staff, skills or knowledge to do this or even to know that this must be done.
Here is a basic guide to inform those customers about this fact so that they can take the relevant actions: resolving them by themselves or hiring the right person to do so.
What are these Skipped Changes you are talking about Daniel?
ServiceNow apply changes on Application File that have not been customised, since an Out-of-the-Box record can be overwritten by another Out-of-the-Box record causing no harm. Nonetheless, what if an Application File has been customised? How do ServiceNow know how the customer wants to proceed? Options are:
- Preserve the customisation and discard the upgraded version
- Discard the customisation and apply the upgraded version
- Merge both records into a single one to get the advantages the upgrade gives in terms of security, performance, etc... at the same time the customisation stays
| Important: "Application File" is an existing table in ServiceNow that refers to any record that changes the behaviour of the platform, such as: Script Includes, Client Scripts, UI Policies, ACLs,... |
In order to let ServiceNow know what to do, somebody needs to take a decision on each of the "Skipped Changes". This may be a tedious process, especially since a customer has never gone through it.
Where can I find these Skipped Changes?
Once the upgrade has been completed, you can go to the "Upgrade History" under "System Diagnostics" and filter out any System Upgrade whose "From" version is "n/a"
Then we can see the actual upgrades that took place on the instance. All we have to do now is select the upgrade we are interested about, which is the latest. You can order by "Upgrade started" or pay attention to the "From" and "To" fields.
By opening the record you will have access to an important field that summarises how did the upgrade go. That field is "Changes skipped", which in my personal development instance says 8, but in a real-life instance would show dozens if not hundreds depending on the customisation degree.
The first related list is "Skipped Changes to Review", and that is the place where you can find those records mentioned by the "Changes skipped" field:
The field "Priority" lets you know how critical it is to take an action on it, and the "Resolution" tells you whether an action has been taken on them yet or not.
| Important: these Skipped changes could cause security and performance issues, but they could also cause existing features to stop working. Take an action on them as soon as possible! |
How do I take actions on them?
These "Upgrade Details" records that upper under the "Skipped Changes to Review" tab contain a series of fields that let you know what is being reviewed, but they also display two actions as it can be seen in the screen shot below.
- Resolve Conflicts
- This will open a new window showing the "Base System" (Out of the Box version contained in the upgrade) on the left vs the "Customised" version your instance has on the right so that it can be compared. Any difference will be highlighted at the row level as shown below. Differences can be overwritten at a field level, so that you can apply certain changes or all of them. If differences occur in a script field, this can be opened and differences can be applied at a script line level too
- Revert to Base System
- This will revert the customisations and therefore apply the new version coming in the upgrade
| Important: These changes must be applied in Development, then in Test and then in Production. For this whole process to happen smoothly it is recommended to clone your instances frequently, or there will be differences between the conflicts you see in each instance. |
Conclusion
Upgrading an instance requires some effort. The higher the customisation degree, the higher the effort required to upgrade. Keep your customisations to the minimum number to upgrade faster and cheaper.
Also, an important part of the process is to plan the work required to upgrade to the next version ahead by upgrading the development instance and having a look at how many "Skipped Changes" are raised and their complexity. This will allow your company foresee the amount of work required.
Finally, remember to use ATF tests to expedite the testing of your instance after upgrading and taking an action of the "Skipped Changes" that will alleviate the workload on your developers and fulfillers.
If this blog article was useful to you, please click on “Helpful”.
Other blog articles created by me:
- Granting the "Impersonator" role to customers in a domain-separated environment
- "Adaptive authentication" or how to restrict access to users based on a specific criteria
- Automating SMS texts and phone calls with Notify
- Translating tickets out of the box using the Microsoft’s Azure translation services
- Avoiding time-consuming transactions being automatically cancelled
- How to give your scripts a beatiful aspect in KB articles
- What is the Data Certification Plugin and how can it be leveraged?
- Validating Service Catalog variables following the best practice
2 Comments
