Here are some suggestions to help you upgrade or patch your ServiceNow instance. Whether you are new to upgrades and patching, or want to know more about it, this article will help you get updated to the newest ServiceNow version.
ServiceNow Upgrades in Comparison to other vendors
ServiceNow's upgrade process is awesome.
I have prior experience upgrading other ITSM applications and it was a difficult and stressful experience. Some of my worst experiences in programming were during system upgrades of systems other than ServiceNow! Please note that I haven't used those other systems since 2011, they may have improved. Still, I still remember those weekends of hell, hours on the support line, and the general anxiousness and trepidation of having to upgrade. It was not fun, no way.
Not to worry however, ServiceNow is much, much easier in comparison. If you are on ServiceNow, you can upgrade without fear! Especially if you are prepared and ready for the upgrade.
Prepare for Upgrade
Learn about upgrades and upgrade preparation
Learn about upgrade best practices ServiceNow Wiki - Upgrade Best Practices
Determine your Current Release Version ServiceNow Wiki - Determine Current Release Version
Here is a good article about preparing for Geneva that can apply to other upgrades as well: Preparing for ServiceNow Geneva
Build an Upgrade Team
When I used to update HP Service Manager at clients, most often I would upgrade the system alone. Some of the most stressful situations in my career were failed upgrades and backouts. It was often because I was by myself and had little support to resolve the issue.
If you have the opportunity to bring a team together to assist on the upgrade this can greatly help. Try to build an upgrade team that helps each other and each person provides value. People who only criticize issues, panic, and provide no assistance should not attend the upgrade.
Establish Production Verification Test
If you have testers, make sure their verification testing is documented beforehand and done in the test instance. If not, they will be tempted to test things they have never tested before in production. If they are doing that it is too late, they can only test in "Test". Make sure they know this beforehand.
Read about the latest Patches and Upgrades
You can read release notes for all the latest patches and upgrades here. ServiceNow Wiki - Versions
It is also a good idea to browse the ServiceNow Community to see user's opinions on the upgrade or patch you are interested in.
Note that for patches, ServiceNow is moving towards quarterly patching. Being aware of upcoming patches will be more important in the near future.
Clone Back
You should always clone Production over Dev, Test, QA, Sandbox instances before you patch or upgrade. That way you have accurate and most current data and code to test against during Testing.
You can Request a Clone in the Left Navigator of ServiceNow under System Clone > Request Clone
More information about System Clone: ServiceNow Wiki - System Clone
Remember in-flight update sets will be cloned over. Back those up to xml before cloning.
Manage Upgrades
After all ServiceNow instances are cloned over (except Production of course), you are ready to organize an upgrade to a Development/Test Instance for testing.
How to request a upgrade/patch
- Login into ServiceNow HI support
- Click the "Manage Upgrades" box
- Select the instance to upgrade and click schedule. Pick a Dev/Test instance so you can test the upgrade/patch before going to production.
If you don't see the version, you might need to click the "Need a version not listed?" link. When you click this, you can "Request a version entitlement" and ask for a new version. ServiceNow will approve/reject the entitlement and if approved, you can go back to the Manage Upgrades box and request the version you want. Sometimes versions are not available yet as ServiceNow only wants to deploy to a few customers at once, or other reasons they might have.
I suggest upgrading in this order:
- Upgrade Sandbox Instance(if available). Test Upgrade in Sandbox Instance
- Upgrade Test Instance (if available). Test upgrade in Test Instance.
- Upgrade QA Instance (if available). Test upgrade in QA Instance.
- Upgrade Dev Instance (if available). Test upgrade in Dev Instance.
- Upgrade Production
Another option is to wait to upgrade one of the instances for two weeks after going to Production. That way you have an older version of ServiceNow in case you want to test a defect that you think the upgrade may have caused.
Confirm an Upgrade
After you schedule your upgrade. You can check the upgrade status using upgrade status and see when it completed.
Review Upgrade History
Once the upgrade is completed, review the upgrade history and revert certain customization to OOB as needed. Sometimes you only made a slight change to some code, and you no longer need it. Other times the ServiceNow code is more powerful or newer, and you may decide to use that code instead.
Here is a wiki article about reviewing upgrade history. ServiceNow Wiki - Upgrade History
In most cases, you never need to adjust this.
Testing
After the instance is upgraded and you went through the upgrade history, you can begin testing.
- Create Test Plans for each ServiceNow application you use
- Have selected users and testers test the upgraded/patched feature using the test plans you created.
- Test new or updated features as part of the upgrade
- Test Inbound and Outbound Email
- Test User Authentication (Logging in/out)
- Test Full ServiceNow and CMS Sites for any potential UI issues
- Important. Notify users that a upgrade is coming. You can do this via email, corporate social network sites, or with Overview help or a header message. It is important that you do this. They may ignore your message, but you made an attempt and make sure to document that attempt to notify them.
Fix Issues
If an issue found is the result of a customization you created, you should attempt to fix it, recording your fix in an Upgrade Set. If there is an issue that you think ServiceNow might have a fix for or didn't notice, create an incident at ServiceNow HI support. They have been really helpful with upgrade issues I have had, often providing quick workarounds or are aware of the issue and will fix the issue on the next release.
Schedule and Upgrade Production
Once you have completed your testing and fixes, you are ready to go to Production.
Never Rollback
I suggest adopting a policy of never backing out or rolling back an upgrade or reverting to a backup. If though ServiceNow can do this (maybe), it should never be done. If you have to rollback, it is huge mistake and huge decision. Don't rollback unless it is only absolutely necessary. Don't rollback for a minor reason.
It is important to have worst case scenarios and solutions available. However once an upgrade starts, it is difficult if not impossible to stop. I am not even sure if rolling back is even possible anymore. I have heard of people rolling back earlier upgrades like Aspen, but that did not go well for people who made that decision.
Going into an upgrade with a never rollback philosophy will insure you prepared enough before the upgrade and are willing to fix issues that occur as well.
Schedule during normal awake hours
Schedule the upgrade during hours you are normally awake. Scheduling things at 2am on Saturday is not a great idea. You will be tired, if you need assistance the best support will be offline, and so will other employees who could assist. I have seen some great mistakes made at 2am, and sometimes even at work!
When they say you must upgrade at 2am, "discuss" that 6pm is a much better idea. Say it is "ServiceNow's Best Practices". You will be happy you did.
Follow the Previous Upgrade Process
When you upgraded dev, test, qa, follow that process and repeat with Production. Do not deviate from what you did previously on those upgrades.
TROUBLE DURING THE UPGRADE
Even with a lot of preparation and planning, an upgrade can go wrong. The important thing is not to panic. Do not start making changes in production as quick fixes. Carefully think of solutions to the issue.
Geneva Node Upgrade Error Example
Node upgrade error - ServiceNow Geneva
Recently during a ServiceNow Geneva upgrade I attended, one of the production nodes failed to upgrade to Geneva. The upgrade monitor stopped working properly (See Picture) and ServiceNow was not working correctly. This was because 2 of the nodes were Geneva and 1 of the nodes was Fuji yet due to an error in the upgrade process.
We can't fix node issues, so ServiceNow HI support was contacted. They were very helpful and fixed the node issue, initiated upgrade on the database to Geneva version, and after completion, fully restored service.
It was stressful and took a while to fix, but it was important we did our preparation and upgrade testing beforehand. That insured it wasn't our fault because we knew it was on ServiceNow side.
Wait, Wait, Celebrate
People like to celebrate immediately after the upgrade completes. I like to wait a week later, get though any issues found, and celebrate! Have a party, then back into it, continuing to do amazing things with ServiceNow.
Mike