•Upgrade process moves your instance to a new ServiceNow version.
•The purpose of an upgrade project is to:
– Make sure everything in system is still working well after the upgrade
– Keep your instance up to date with new fixes and features from ServiceNow
– A chance to find what we need to improve/enhance the system for our customer in the future
Prepare for an Upgrade
Check release notes.
The release notes offer valuable information about new functionality, notable changes, and available fixes.
- They help you determine whether the upgrade contains functionality you need and fixes that resolve any issues affecting your instance.
- The release notes can also help you determine whether items you previously customized are being upgraded.
Review scope of work
To determine what to do (In Scope), what not to do (Out of scope)
Prepare test case.
Prepare test cases if client requests to perform UAT testing It’s a change for you to understand the Client system. It would be better if you have already worked in the system before
Backup data/update set.
- Backup for yourself / your team
- Might backup for other teams…
- Release functionalities/changes/fixes if we can
Send announcement to freeze development activities.
ServiceNow Upgrade (Dev Instance)
Clone from PROD
- Clone request MUST be created in source instance (PROD)
- Required role: clone_admin or admin (on both source and target instance)
Preserver Data and Exclude tables
ServiceNow Upgrade Dev Instance
Review Skipped Changes
Test and Fix
Store Update Sets
ServiceNow Upgrade (UAT Instance)
- Clone from PROD
- Upgrade Sub instance
- Migrate update sets from DEV
- UAT and sign-off (Client)
ServiceNow Upgrade (PROD Instance)
– Upgrade Production
– Migrate update sets from DEV
– PVT testing (if needed)
Upgrade Issues can hit
Problem: After cloning TEST environment from PROD. User couldn’t access to ServiceNow TEST environment via SSO
Current DXC consultants didn’t know the root cause and couldn’t test from our side because we are using ServiceNow account (login.do)
The rootcause is about the Clone overwrote all of the Users in TEST with Production Users – and in the process, changed the SSO source for everyone’s User profile to point towards the Production sys_id.
This was not a problem in the Development environment because DEV and Production use the same SSO source, TEST does not
With this issue already happened, we decided to run a script to change all Users SSO source in TEST to the correct sys_id
To avoid this issue happening in the future, follow ServiceNow recommendation, we created Preservers and Excludes for:
- customer_contact [Only if you have the Customer Service Management plugin installed]
BUT FIRST, ALWAYS CHECK RELEASE NOTES AND DONT FOGET TO MAINTAIN YOUR CERTIFICATION
Check out below courses with pass for sure questions to get yourself educated with ServiceNow Quebec version
Then take your wallet out and buy below pass for sure courses on Udemy