Twice a year, ServiceNow releases a new version of the Now platform. Every new version/release comes with new features, enhancements, bug fixes, and a lot more. It is highly recommended by ServiceNow to stay on the latest release or N-1 in some cases.
As with any software upgrades, there are challenges and nuances that you need to consider and the ServiceNow upgrade is no different. ANB has helped many clients successfully upgrade their ServiceNow instance. In this blog, we have listed our ServiceNow upgrade approach that can help you successfully upgrade your instance. Let’s look at how you can upgrade your ServiceNow instance seamlessly.
- Define an upgrade plan: ServiceNow instance upgrade should be treated as a formal project. Consider the following activities to develop an upgrade plan:
- Define the project team: Typically you would consider the following resources:
- Project Manager: To define and execute the project plan
- Business Analyst/Developer: To review ServiceNow release notes for any new functionality, impact to existing functionality, etc. We will cover this in more detail in step 2.
- Developer(s): To perform any development work related to ServiceNow for bug fixes etc.
- Tester(s): To test ServiceNow instance for any bugs/defects
- Develop ServiceNow upgrade project plan: The project manager should define the upgrade plan that is comprised of a list of activities, timeline, resources needed
- Define upgrade path: Define which instances will upgrade and in what sequence (e.g. Dev first, then Test, and then Prod).
- Define support plan: At a certain stage, you will have Sub-Prod instances on the latest release (after step 3) and Prod on different releases, so during that time in case of any Prod issues where are you going to develop the fixes and move to Prod? That’s where additional instance such as Sandbox comes in handy. In that period, you could use Sandbox on the current release (same as Prod) and perform any development there in case of Prod issues.
- Communicate appropriate stakeholders about the upgrade process and plan
- Define the project team: Typically you would consider the following resources:
- Understand the new release: ServiceNow provides very detailed and specific documentation for the upgrades. Based on your current instance release and target instance release, you can find out specific release notes for your use case from the ServiceNow website. For example, if you are planning to upgrade from Paris to Quebec the release notes are different than upgrading from Orlando to Quebec. In this step, typically Business Analyst/Developer (Who has a good understanding of the ServiceNow product and your ServiceNow environment) should read the release notes and feature changes by-product and document the following:
- Any enhancements or custom-built functionality in your instance but is now available OOB
- Any changes to the features you are currently using
- Any changes or impact on integrations
- Any new features that may be needed by your organization in the future. Note any new features should be planned for the future (after the upgrade is done) unless there is a pressing need. Upgrades should focus on upgrading the current instances with the same functionality. This will keep the team focused, fewer defects, easier troubleshooting, and faster upgrade.
- Review the above findings and recommendations/next steps for each with your Product owner.
- Prepare and Upgrade Dev: In this step, Dev instance (This may depend upon your upgrade path i.e. the instance where you will perform development for upgrade) is prepared for the upgrade:
- Backup: Take a backup of your update sets or any other configuration or data that you need that has not yet moved to Prod. Make sure to inform all development teams (internal or external – in case you have engaged external vendors for ServiceNow development)
- Clone Dev: As per your upgrade path, you will clone Prod to Dev instance
- Upgrade Dev instance(s):
- Schedule and Upgrade Dev: On the ServiceNow Hi instance, Schedule the upgrade of your sub-prod (Dev) instance.
- Check Upgrade Monitor and Process Skipped Record List: Leverage ServiceNow Upgrade Monitor to check the upgrade of your instance and validate that the upgrade of your Dev instance is complete. Also, check for any skipped items in the upgrade monitor and process them accordingly. This step is required to resolve the differences between the upgraded and customized versions of the record by processing the skipped record list.
- Perform Configuration: Perform any configuration (if needed), based on your findings and recommendations. For example in some cases, New release might bring in changes to current functionality (e.g. UI changes, etc) that you don’t want to roll out yet, so in this step, you would disable them and capture them in an update set.
- Smoke Testing: Conduct smoke testing on your Dev instance to ensure everything works as expected.
- Prepare and Upgrade Test: In this step, the Test instance (Instance where functional, integration and, UAT testing will be performed) is prepared for the upgrade:
- Clone Test: Clone Prod instance to the Test instance
- Upgrade Test instance(s):
- Schedule and Upgrade Test: Leveraging ServiceNow Hi instance, Schedule the upgrade of your Test instance.
- Check Upgrade Monitor and Process Skipped Record List: Follow the same steps as performed for the Dev instance above. (in step 3)
- Apply Update Sets/Configuration: Move any update sets/configurations that were developed for the upgrade (in step 3) to the Test instance.
- Testing: Testing is one of the most important steps in this entire upgrade process. In this activity, identified testers will perform functional, integration, and UAT testing depending upon your test plan. Any identified defects must be resolved or accounted for in this step. Our recommendation is to use ServiceNow Automated Test Framework (ATF) in your overall ServiceNow Test strategy. By leveraging ATF, you can create automated test cases and suites to test ServiceNow functionality that can help speed up the testing process significantly.
- Upgrade Production Instance: Once the testing is complete and all defects have been resolved, you can start planning to upgrade Prod. In this step you will perform the following to upgrade Prod:
- Schedule the Upgrade: Leveraging ServiceNow Hi instance, Schedule the upgrade of your Prod instance. Ensure you follow the change management process to properly record a change request and also keep into consideration any change freeze or change window. It is recommended to schedule the upgrade when the system is not widely used.
- Communicate: Send out communication to the appropriate stakeholders (including members of the ServiceNow team, Service desk, other IT teams, etc.) about the timing of the upgrade. The communication should also include any changes that the user may see from UI or functionality perspective after the upgrade.
- Support Coverage: Ensure you have appropriate support team members available during and after upgrade (especially Day 1 post-upgrade) to help resolve any issues.
- Upgrade Prod instance: Use Upgrade Monitor to check the progress of the upgrade of your instance and validate that the upgrade of the Prod instance is complete.
- Apply Update Sets/Configuration: In this step move any update sets/configurations that were developed for the upgrade (in step 3) to the Prod instance.
- Verification: Perform any post-prod upgrade verification steps as per your test plan. Note testing in Prod is not recommended however, at a high level you should perform verification steps in Prod (Such as all Apps and modules are available, Form UI and Portal page are displayed as expected, etc.)
- Post Upgrade Activities: Post-production activities are often neglected but should be treated with the same importance as other upgrade activities. Let’s have a look at post-upgrade activities
- Communicate: Once the production instance upgrade is done, communicate appropriately in your organization. You should inform not just IT teams but also end-user(s) depending upon the upgrade-related changes. If the user(s) will see any new functionality/changes/known issues you should describe that in the communication.
- Post Upgrade Issues: In case there are issues after the Prod upgrade, you should follow your incident management process and create incident(s) appropriately. You should also relate these incident(s) with your change request for any Post-implementation review (PIR) and future impact analysis.
- Clone sub-Prod instances: It is a good practice to keep your instances in sync, so you should clone your Prod to sub-prod instances after the Prod upgrade is complete.
Last but not least ServiceNow upgrade is no easy job and requires good planning, effort, and coordination, So don’t forget to celebrate this achievement.
Are you looking to upgrade your ServiceNow instance and need assistance? Get in touch with one of our ServiceNow upgrade specialists for more info: firstname.lastname@example.org
Note: While publishing this blog ServiceNow’s latest release is Quebec but the above-mentioned approach can be leveraged with other releases as well.