Updating a sub-production instance in ServiceNow
Introduction
Upgrades are a vital activity in ServiceNow. These are carried out once or twice a year and usually after every new version release (New York, Orlando, Paris, etc). ServiceNow provides plenty of documentation detailing the steps to be followed in this process:
· Instance upgrade best practices
· ServiceNow Upgrade Planning checklist
Part of this process is focused on testing the updates and checking for possible issues before upgrading the production instance. So, in this article we will focus on the technical approach of making this change in a sub-production instance. This is one of those steps and although has similarities to upgrading a production instance, it should be more straightforward and more oriented into the technical aspect of the task at hand.
The following lines describe the process of upgrading a ServiceNow cloud sub-production instance.
Planning
As part of the overall upgrade process, planning is essential for any kind of instance upgrade, whether we are talking of development, sub or production. With every new version release, new notes are published in the Product documentation. In these notes it is possible to see the changes from one version to another. If you are facing an upgrade from a version much older than the version you are aiming for, it is more likely to require significant changes to validate.
It is important to check the version of each instance involved in the upgrade since they may not be the same.
As an example, here are the links of the release notes from Madrid to Orlando:
· Combined Release Notes for Madrid to Orlando
· Personalized PRB release notes for upgrades to Orlando
For the testing scope, the instance managers may tell you their customisations and integration plugins as a starting point. We are still required to confirm and validate if these changes on the instance are working properly. Furthermore, we can go to System Definition > Plugins and filter the results to Installed to see the relevant plugins and modules installed in the instance. There may be some changes not mapped by the system administrators.
Another source of information about changes is with Reports. We can create a report of the changes made to the instance by other users. You will need to go to Reports > View/Run and select My changes. We can change the filter to Updated by is not system and set the Group by to Application. With the report, changes can be mapped and new actions for testing after the upgrade can be done.
For the test plan, you must work with the users and determine the expected results and what needs to be validated, establishing the current and expected future state for each app, customisation and integration: if the plugin is not working now, do we expect for it to work after the upgrade?
After the upgrade
After having scheduled the upgrade on the Now Support portal, the upgrade process should go through leaving behind the Skipped Changes:
When going through the Skipped Changes, due to customisation of the UI on a form or because of a major change in an application, consider any mapped actions that could overwrite what was skipped during the upgrade.
Although the upgrade was done, plugins should be checked and updated if necessary. With custom applications, a full review of its functionality should be checked to see if the scripts need to be updated.
Finally, keep in mind that sometimes the plugins require you to review technical documentation of other manufacturers. For changes on other applications and solutions, work alongside the people in charge of those solutions.
Conclusion
ServiceNow makes it easy to upgrade your instance; however, upgrades should be properly planned and mapped from the outset to enable fewer customisations, skipped changes and essentially less work to do. Effective planning can also ensure the actions after the upgrade are visible to the System Administrator. Although there are technical aspects to cover, the number of these are dependent on the level of customisations made to the instance so each case should be analysed separately.
