Upgrade challenges
ServiceNow upgrade is a standard operation, being a part of instance maintenance. The upgrade time depends on the complexity of an instance and features in a new version.
To minimize the risk and reduce the impact on the instance operation, an upgrade can be defined as a project, because it’s a set of steps and factors to consider. It’s important to be aware of the challenges occurring during the upgrade process.
The challenges faced during an upgrade are:
- It’s hard to cover all cases within all features in test scenarios,
- It’s important to control all bugs which are reported as “caused by upgrade” and identify them properly,
- It’s good to know about all tables which should be excluded from cloning and plugins turned only on development or test environments,
- It’s necessary to make data backups,
- It’s important to choose the date and time of an upgrade that is convenient for both sides (customer and vendor) to reduce the risk,
- It’s good to prepare schedule with time buffers to ensure more time, e.g. to fix unexpected bugs found by testers.
Even if it’s not possible to eliminate all the risks, a standardized approach always helps streamline your upgrade.
Preparation to a ServiceNow upgrade
Every team responsible for the ServiceNow Platform upgrade should review the new version’s release notes on the ServiceNow’s website. Release notes contain information about the added and enriched features by ServiceNow, and allow you to familiarize with the ServiceNow elements affected by the upgrade most.
After the analysis, it’s worth to think about:
- How many resources are available?
- How many instances should be upgraded?
- What is the complexity of the instance to upgrade (e.g. number of roles, scripts, integrations)?
Based on the answers, we are able to prepare a detailed schedule of an upgrade.
Production instance upgrade
The production instance upgrade should be planned after business hours. It allows to reduce the impact on the key instance features and to check if they work properly, if any inconsistencies won’t generate critical or high priority incidents in the nearest future.
The upgrade project should start with the clones. The cloning should be done from production instance to development and test instances. The alignment of environments allows more accurate checking what can happen after the production instance is upgraded thanks to the exact copy of production instance.
Before preparing clones, it’s recommended to verify which plugins are turned on the development and test instances, and what data should be excluded. At the same time it’s important to save all crucial copies. We should remember about verification of how clones were executed and if all works as expected.
After making clones, testers are able to prepare test scenarios or rebuild existing ones if necessary. The test scenarios can be used in the future, for the next ServiceNow upgrade(s) and regression test(s). Instead of manual test scenarios, a good approach is to use ATF (Automated Test Framework) by ServiceNow. It is a paid plugin offering a number of capabilities to automate tests on the instance.
Development vs. test instance upgrade
After the preparation of manual or automated test scenarios, the development instance can be upgraded to a chosen ServiceNow version. After verifying which records were skipped and analyzing the content of these records after the upgrade, we can decide what’s the next step.
There are 2 ways to choose from:
- Upgrade of the test instance, followed by the upload of all iterations of implemented fixes. All tests should be done on the test instance then.
- Execution on the development instance and waiting with test instance upgrade till the end of the project. Where all tests are done on the development instance and test instance is the environment to compare existing features before and after upgrade.
The first option is a common one. The second one may seem controversial, but provides a clean environment (the test instance) to compare if bugs reported by testers or customers are caused by the upgrade.
Testers can check the instance according to the test scenarios prepared, and report bugs to the upgrade team. Simultaneously, customer’s team also can test the entire instance to find any inconsistencies. After the tests, developers are ready to analyze all bugs, identify their cause (upgrade or not) and prepare proper fixes. Their inclusion in a single Update Set allows us to easily transfer them between environments, without conflicts.
The fixes prepared by developers should be checked on the development or test instance (following the chosen approach) by the testers again. Any additional fixes should be prepared within proper Update Set and marked with a version number. The preparation of fixes and testing them requires repeating until the last bug in the upgraded instance is fixed.
Upgrade chronology
A team or person responsible for the upgrade should track upgrade status in Upgrade Monitor. Once the upgrade process is finished, logs and skipped records should be verified and only then Update Sets with fixes should be uploaded. The key instance features (e.g. incident form, roles and users, request form) should be reviewed to make sure that everything works properly and won’t generate serious issues.
Final step in upgrade process
Following the approach chosen, after achieving the instance stabilization, we can either close the project or upgrade the test instance and upload all fixes. It’s recommended to make clones after the successful implementation of all upgrade steps, and once again align all the environments.
Our Maintenance & Development team will be more than happy to support you in your upgrade endeavors.
Discuss your ServiceNow upgrade
