ServiceNow releases a new version of their platform semi-annually. This means that even when your organization gets up and running on the current version very quickly, there will be a newer version available a few months later. It’s not a question of “if” your organization should upgrade, but “when” or even “how often” your organization should upgrade. According to ServiceNow, you should plan on upgrading at least once a year. It may seem daunting to upgrade your software, so I’ve put together a few best practices for ensuring a smooth process.
The first thing you’ll want to do is review the release notes as well as product and release documentation to make sure you know what exactly will be changing. It’s a vital first step to understand the required upgrade and migration tasks, and will help you understand how these changes may affect internal processes. If you haven’t upgraded in a while, take a look at the release notes for all releases between your current release and your target release to make sure you don’t miss anything.
Once you have an understanding of what’s new, start planning out the project. The Upgrade planning checklist provided by ServiceNow outlines the upgrade process to ensure you stay on track and don’t miss a critical step.
It may make sense to apply project management principles to the upgrade process, including:
A project management tool can be really helpful to track and communicate your progress. Remember, if you have the ServiceNow IT Business Management module, you’ll already have access to the ServiceNow Project Portfolio Management suite.
It’s important to communicate with your users throughout the upgrade even if you think the upgrade will go unnoticed by them.
Prior to the upgrade, tell them what to expect and why they can look forward to the upgrade. Depending on their role, maybe they’ll be able to take advantage of new capabilities, or maybe they’ll experience faster service in a certain area. Whether the changes will affect them directly or indirectly, awareness will be key.
During the upgrade, let them know about any expected downtime or other disruptions to their day-to-day operations, and when they can expect to resume business as usual. Provide workarounds for any essential tasks, and consider staffing extra IT support during this time.
Also, consider what training needs there may be based upon what is changing. Users may need to be trained quickly and thoroughly on the upgraded system so they can resume their normal productivity.
Having two environments (your production instance and an exact copy of your production instance in a non-production environment) will help you avoid upgrading in place. By cloning your production instance and performing your upgrade on the clone, you can simulate an upgrade without disrupting your production environment and day-to-day operations.
Use the ServiceNow Upgrade Monitor (installed in New York by default) to help you upgrade an individual instance and monitor the progress of an upgrade including resolving conflicts between the upgrade and customizations.
Upgrade and validate your non-production environment. Perform necessary testing to confirm the instance still works and performs adequately. Include your actual end-users in this testing to ensure critical features are migrated with the upgrade.
One of the benefits of ServiceNow is that it is highly customizable. However, your customizations are not overwritten when you do an upgrade; they’re “skipped.” That means you’ll have to review each of the skips and decide whether to revert, merge, or continue with those changes. ServiceNow has made this a pretty easy process, but how long it takes to complete this step can range from minutes to days depending on how many changes were made to the system. Note that skips are related to customizations of out-of-the-box code, and not newly created records as part of a customization.
You can streamline future upgrades by understanding the true cost of customizations. Consider the cost of the initial implementation as well as the cost of ongoing maintenance, including testing and validation during upgrades. Typically, customizations take longer to implement and involve more in-depth testing. We recommend using upgrade-ready configurations before customizations in order to keep costs down and streamline future upgrades.
User acceptance testing (UAT) is a vital step in the upgrade process. UAT minimizes the risk of discovering flaws after go-live that can throw the entire project into question. Remember, people using the same tool don’t always use it in the same manner or for the same reasons. Rather than trying to guess or assume you have everything covered, let your users confirm it for you.
Ensure a reasonable sample of users test the new system for a few hours. If possible, give users the ability to test the system early in the upgrade to give your team ample time to find and fix problems.
Keep in mind that you can use an Automated Test Framework (ATF) to build out automated test cases. It’s not a substitute for human-based UAT, but can help save some time with identifying issues before moving to UAT.
Performing a retrospective gives everyone time to reflect on the completed upgrade project and learn from what worked well and what could’ve gone smoother, so that you can improve during the next upgrade. Encourage the team to take notes throughout the upgrade so nothing is forgotten, set aside time for the team to share their notes. Schedule this retrospective for about a week after the project wraps up, so it’s still relatively fresh in everyone’s mind, but enough time has passed for the dust to settle and outcomes to emerge.
As with everything else we do at Crossfuze, we take a continuous improvement approach to upgrades. Having helped nearly 2,000 organizations launch and mature their ServiceNow instance, we’ve seen time and again the things that make ServiceNow projects successful. If we can help you with your ServiceNow upgrade, contact us today at LetsChat@crossfuze.com.