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's upgrade process is awesome.
I have prior experience upgrading other 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! I will always 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.
1. 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
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.
2. Specific Upgrade Prep
For the ServiceNow Geneva version, there are a couple suggestions I have to improve your upgrade.
Fix Existing Data Issues
Do a review of your current system and see if you have any issues today you can fix before the upgrade. Here are some articles you can use to check.
3. 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 mandatory patch levels. Being aware of upcoming patches will be more important in the near future.
4. 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.
5. SCHEDULE DEVELOPMENT Upgrade
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.
6. CONFIRM DEVELOPMENT Upgrade
After you schedule your upgrade. You can check the upgrade status using upgrade status and see when it completed.
Review Upgrade Monitor
Once the upgrade is completed, review the upgrade monitor 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.
After an upgrade, you want to go to the Upgrade Monitor (Left Nav Bar > Upgrade Monitor). Click the "Review Skipped Updates" button.
Review all the skipped updates and selectively choose which ones to revert to base. There may be no updates to revert. Less is more in this respect, as reverting to base code can have adverse effects on the instance.
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.
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.
7. Schedule and Upgrade Production
Once you have completed your testing and fixes, you are ready to go to Production.
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.
Usually the process is upgrade and then apply the update set. Sometimes there are manual steps as well.
Issues 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.
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.
8. 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 get back into it, continuing to do amazing things with ServiceNow.