The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Tim Raymond
ServiceNow Employee
ServiceNow Employee

tim.png

 

A collection of thoughts and content about upgrades.

 

 


Upgrades take time and disrupt operations as well as require testers who may not have time to test appropriately.

Customizations create a ton of skip logs.

The good news is that upgrading ServiceNow is less work than upgrading your ERP, and the bad news is, in my experience, there are fewer resources available to perform upgrades and testing for ServiceNow than the ERP.

Well, I can’t solve all these issues, but I can provide you some resources to assist in reducing delays in your upgrades. My goal is to assist you in getting to an upgrade schedule that isn’t “forced” as your current release becomes end of life (EOL). I tried to curate a meaningful list of resources that touch on what were the biggest issues we faced when I was a platform owner at an educational institution.


Personal Experience

We had the toughest time with getting testers to sign off. Fortunately, our IT leadership realized that would impede our progress and supported adopting a “you have until X date to complete testing” approach where no response was an implicit approval. We would fix issues that occurred post upgrade, but the accountability fell on the areas who perform testing. I realize that not all leadership will support this approach.


In flight development was always an issue. Since the upgrade process required cloning/upgrading dev and test on the way to the upgrade of prod, we needed a development freeze to be put in place. Anything that had not been promoted to prod by then would be captured in an exported update set to be restored after the clone/upgrade. In rare cases we would promote the work to prod unpublished so that we’d get it back in dev with the clone. That is definitely not a best practice, but there were times there was no alternative.


Check your ServiceNow order form. You may be entitled to four instances. If that is the case, and you aren't using all four currently, using a fourth instance could give you a place to park your dev work during the upgrade. It is also useful to clone from Prod just before the upgrade so you have a reference of what prod was like pre-upgrade if you need it.


Links to Resources

Best Practice up to San Diego and Upgrade Plans in Tokyo

35 Minute video. Talks about best practices with upgrades for San Diego and earlier (up to 11:20 mark of video), and from then on introduces the new Upgrade Plan capability released in Tokyo that will speed upgrades in Tokyo and beyond.

 

One issue are customizations and many times they were created years ago and subsequently ServiceNow delivered a comparable capability. To help get your instance back to “out of the box” (OOB/OOTB), Revert customized record to OOB and transfer via Update-set for Upgradeability. Also, on the topic of customizations, How to use an Update Set to capture reverted customizations made after an upgrade .


Chime In

What other upgrade tips and tricks do you have to make your upgrades easier and ensure you can stay ahead of a forced upgrade when your release goes end of life? Post it in the comments.