Quick and Easy Upgrades, Part 1

Twice a year, usually in the spring and the fall, ServiceNow releases a new version. In the past, it's not been uncommon for companies to skip versions. For example, they might only upgrade in the spring and skip the fall upgrade. Until recently, ServiceNow supported instances up to two versions behind the current version. This is known as N-2. Where N is the current version, and 2 is the number of versions behind the current version that is support.

Last summer ServiceNow switched to an N-1 support model. What does this mean? Well, if a company skips versions as they tend (or tended) to do, then you could very easily fall behind the N-1 support model. My organization adopted an N-1 policy for ServiceNow well before it was instituted as a Support Model for the company. We made an agreement with leadership that we would never be more than one version behind the current release and, ideally, we would stay on the current release.

Which is all fine and dandy, but how do you accomplish that? Past upgrades have been time-consuming, problem-prone, and difficult to get properly tested. ServiceNow has made some updates over the past year or so which make upgrades go more smoothly. My organization has also implemented several processes that have been impressive time-savers.

What we've done

We have a few simple rules when it comes to ServiceNow upgrades. By following these guidelines, our upgrades go more quickly with fewer reported post-upgrade problems.

Do not turn on new functionality. 

This is a biggy. I know, everyone wants the shiny new stuff. Or they use the shiny new stuff to encourage people to complete testing so they can upgrade. But activating new plugins and functionality comes with a whole host of issues. We've found a lot of success in separating new functionality from our upgrades.

Identify your Stakeholders & define their responsibilities when it comes to testing. 

I'll admit, we aren't the best at this. With every upgrade, it's improving. Sometimes it's a struggle to identify your stakeholders and testers. Once you've identified these people in your organization, you can keep an on-going list of those individuals. We use this list to create testing tasks for each section for each upgrade. We've already spun up testing tasks for every area for our next (Orlando) upgrade. We did this before our New York upgrade was even fully complete. When we begin a new upgrade cycle, we check in with these same individuals and verify that they are still the correct contacts/testers for these areas.

This is likely one of the harder things to accomplish and will vary widely from organization to organization. Not only do you have to identify the individuals who are doing the testing, you also have to come to an agreement with your organization as to what that entails. We put nearly all the onus for testing individual areas back on the stakeholders for those areas. We do this simply because we do not participate in the day to day activities of these different areas. Our testing will never be as in-depth as their testing can be.

Prepare easy-to-use templates that can be reused for each upgrade. 

Have an email you need to send out to the company before the upgrade? Do you create a Knowledge Base article or Release Notes? Prep templates for these items ahead of time and save them for future use. We have these items stored in a document repository. When it's time for an upgrade, we can pull the documents, make some minor changes that reflect the new upgrade, and our communications are ready to go.

Make your defect reporting process clear. 

Your testers should know exactly how to put in a defect for any issues they find. With our latest upgrade, we created a dashboard which includes all outstanding testing task, all open defects, all open incidents against the upgrade, and a tab that takes them directly to the form to report a Defect. From here, we prioritized these defects during the upgrade cycle.

Communicate early and communicate often. 

Our stakeholders already know a tentative date for the Orlando and Paris upgrades with ServiceNow for our company. These versions are not even been officially released yet, but we've given them a tentative scheduled date. This allows our Testers to know in advance what will be expected of them. In addition, once we start our testing cycle for the new release, we have weekly meetings with all of our process owners. These meetings allow us to review any concerns or talk through any defects. Additionally, the really helps to create buy-in from your stakeholders. By giving them input and an opportunity to contribute, they feel more invested in the process.

Make your upgrade about your upgrade. 

In the past, we've attempted to stick with our regular release schedule while performing the upgrade. We completed the upgrade, applied our upgrade release, and then implemented our regular weekly release. For us, a regular weekly release can be anywhere from 20-50 stories worth of work. Yikes! This was causing a lot of mistaken issues on the day after the upgrade. If something was broken, it must be related to the upgrade!

However, more often than not, we found it was related to the weekly release. But it was hard for our users to tell the difference between these two items. So keep them separated - either skip your normal release cycle, or move it back a bit to make it easier to distinguish between issues caused by the upgrade and those caused by your regular release.

Separate your normal development work from the Upgrade Process. 

While this is one of the higher priority things that we do that make quick upgrades successful, I realize that it comes with a price tag. For that reason, it's listed last. When we begin this process, we set aside two non-production instances outside of our normal development path, in order to have a Development and Test instance specifically for upgrades. This allows development to continue as normal, while also allowing prioritization of upgrade defects. One thing to keep in mind - if you do separate your instances like this, anything applied in production also need to be applied to your 'next release' development and test instances.

Stay tuned for Part 2, where we explore some of the things ServiceNow provides to make your upgrades a little bit easier.