1. Effectively communicate the change across the organization
2. Read the release notes and plan your upgrade
3. Make a Backup
4. Clone your sub production instances before upgrading them
Before you plan to upgrade your sub-production instances, like development or test instance, you must clone your production instance onto sub production instances. Cloning the production instance helps you avoid inconsistencies across all instances. You are also less likely to encounter any issues or surprises while upgrading your production instance. If you have access to a cloned instance, you can consider upgrading that instance first.
5. Schedule the upgrade with the HI team
Before upgrading, verify if the cloned instance captured all important configurations and the sub-production instance is as close to production as possible.
Once you have the upgrade plan ready and all the test cases or ATF tests created, you can schedule an upgrade to the sub-production instance with the HI team.
6. Check the upgrade monitor
The Upgrade Monitor helps you check the progress of your upgrade. Once the upgrade is completed, you can check your upgrade start time, finish time and duration of the upgrade in the Upgrade Monitor module. You can even find the number of skipped items. Once you identify your update sets, you can go ahead with functional testing.
7. Review skipped items
If users modified any out of the box items during the upgrade, the system will skip the change on that particular item and mark it under Skipped Items. It will not upgrade the item to the new version and the customization will remain as it is. After reviewing the item, you can either retain the customization, revert to the base configuration, or merge the customization with the base configuration. You can view the list of skipped items, by clicking on ‘view all skipped items’ in the upgrade monitor.
Based on the priority of the item, the system automatically provides the priority, ranging from P1-P5.
- P1: (Highest priority): xml content. E.g. UI Page, Macro.
- P2: script or script_plain. E.g. UI Actions, Script includes, ACL, Notification, Client Script.
- P3: html content.
- P4: sys_ui_form_section, sys_ui_related_list, or sys_choice_set. E.g. Related lists, Variable set, Order guide, Record producers, UI policies, Catalog items.
- P5 (lowest priority): other. E.g Widgets, menu items, UI View, List layout, Form Layout.
When you open a skipped item, you can click on Resolve Conflict to compare the code. Once you compare the code, and there are only minor changes and the change can be merged with the OOB code, you can go ahead and merge the code and click on Save Merge.
After clicking on Resolve Conflict the below screen will be displayed. What you see on the left side is the base system (i.e. OOB code, new code) and the right side is customized code. Based on changes required, you can click on the arrow in the middle to merge the code, and once completed you can click on save merge or revert to the base system.
Note: If you revert to the base system, this item will not be skipped in the next upgrade.
8. Create Test Cases using Automated Test Framework
It’s always recommended to have test scripts or test cases created before you perform the upgrade. Creating a test plan before upgrading, ideally during development, helps you streamline processes and reduce test times. Use the new Automated Test Framework feature to avoid manually testing and checking the test scripts.
You can create automated tests and test suits for each module with the flow we follow in the current version.
Creating tests with the Automated Test Framework (ATF) saves time and effort. ATF also allows you to run tests multiple times, something that is not possible with manual testing. Finally with ATF, you can identify the gaps in logic or workflow to a certain extent with the upgrade.
9. Plan to upgrade production when usage is low
Once you have upgraded your lower instances and captured all changes to skipped items in update sets, you can schedule an upgrade to the production instance with the HI team. It is always advised to plan the production upgrade when instance usage is very low (outside business hours). This way if any unexpected issues occur, you can quickly fix them before people start actively using the instance.
Generally, upgrading the production instance is a seamless process. Most of the time, supporting nodes are available in ServiceNow to support ongoing platform activities. If there are critical processes running on ServiceNow, they will run uninterrupted and as expected unless they are customized during the upgrade. However, this doesn’t mean the upgrade can be performed at any time.
10. Post upgrade measures
Cloning the development and test instances after upgrading production is a very important step that is often overlooked. Once production is upgraded, you might encounter some issues you haven’t faced in lower instances. Keeping all the instances in sync post-upgrade helps you resolve any issues that occur post upgrade.
Finally, if ATF is setup, after cloning, it is recommended to run ATF in the test instance to check for issues. Issues that are not identified in ATF testing or regression testing are generally fixed as and when end users report them.
Want to learn more about successful upgrades? Check out some of our in depth articles below, or reach out to us today!
- K-12 Services Company Maximizes Value From ServiceNow Upgrade With INRY
- Global Software Company Upgrades And Takes Full Advantage Of ServiceNow Discovery
Are you planning to upgrade your ServiceNow Instance? Get in touch with one of our ServiceNow consultants for a personalized consultation to plan your upgrade journey!