In this article, you will learn techniques to upgrade faster or minimise development downtime when upgrading your ServiceNow instance. These techniques can be applied to any version upgrade.

“We have to pause all ServiceNow development activities while we upgrade the platform”

ServiceNOw DEVELOPERS

It’s the conversation no developer wants to have and no customer wants to hear.

ServiceNow platform needs to be upgraded at least once a year to maintain currency and support. Upgrade time is often paired with a “tools down” approach, focusing on getting the upgrade installed, customisations merged and pushed through all environments without worrying about ongoing development clashing with upgrade activities. Pausing development work during this time is a common practice to reduce risk and get the upgrade across the line so development can resume. It is always difficult to tell customers that we need to pause development for as many as 2-8 weeks, depending on the complexity and level of environmental customisation.

Minimising development downtime

So what can we (us ServiceNow developers) do to make this conversation less awkward, and how can we enable platform owners to minimise development downtime?

You’ve essentially got two approaches:

1. Continue development during the upgrade
2. Reduce time to upgrade to minimise downtime

Continuing development during the upgrade

You will unlikely be able to maintain your usual development cadence during the upgrade, as some resources will be redirected to this effort. Still, you may be able to continue some forms of development. While this is not without risk, several practices can be implemented to continue development on the platform during an upgrade while mitigating risk.

Implement a change freeze

Continue development activities, but don’t push any changes into an environment that has not been upgraded especially production! This can be enforced on a process level by implementing a change freeze on each environment until it has been upgraded and customisations merged. This will eliminate the chance of any potential conflicts between development and upgrade merges. All “done” development during the upgrade would then get pushed to production with the upgrade.

Request an additional instance

Branch your development pipeline by requesting a temporary upgrade instance and continuing as usual in your development environment. Contact your ServiceNow account manager to explore your options.

Leave OOB configuration alone

Continue developing but disallow changing any OOB configuration. This will eliminate the chance that development activities will clash with merging after the upgrade has been run.

Reduce time to upgrade

The fastest way to upgrade is just to let it happen! While there are always tales of accidental upgrades that went fine without testing, this isn’t the recommended approach. You need to analyse your customisations, deciding which to keep, which to merge into new code (often bug fixes and new features) and which to return to OOB. The NowCreate methodology does a great job of outlining a leading-practice approach to upgrading the platform using this approach.

In my experience, however, most customers want to upgrade quickly so development can resume at full cadence. Often, customers won’t even have the resources to upgrade and develop simultaneously.

Adopt new features after

Upgrading isn’t just about merging customisations into changed configurations. Upgrades bring new features and opportunities to retire custom functionality built to address previous platform capability gaps. Retired custom capability must then be communicated to the end-user experience, which requires communication with the business through Organisational Change Management (OCM). The decision-making process, training, and stakeholder engagement can slow upgrades, increasing platform development downtime. This activity may be skipped to focus on getting production upgraded as fast as possible. Some new features can be disabled until the business has time to communicate these to end users.

Build an Upgrade Plan in the Upgrade Center

In recent years, we have seen a shift toward packaging more capabilities as ServiceNow Store Apps, which have a monthly update cadence. While not all apps are updated monthly, new features can be rolled out between major releases. Still, new features released via the store are dependent on new releases and often coincide with major releases (see my blog Why staying current means more than just upgrading to the latest release).

While the ServiceNow family upgrade is deployed as one big package, to get the new features from the store, you’ll need to update each app individually after the major upgrade is deployed. You’ll also need to merge your changes too. This can make the upgrade process take even longer!

While you can adopt the ‘adopt new features after’ mentality for store apps, you may as well get these new features if it is easy. You’ll want to update all of these to get the full benefit of the upgrade. Use Upgrade Plan in the Upgrade Center to streamline the plugin installation process for your upgrade.

Minimise Manual Testing

You’ll also want to test to ensure upgrading and merging haven’t broken anything. The risk of not testing is too significant for more organisations that operate ServiceNow as a business-critical tool, and merging conflicts is vital for long-term platform maintenance. It is unacceptable to have an upgrade go wrong and need to roll back with data loss. Coordinating UAT can also be like herding cats. If only there were an easy way to build and run an automated regression suite to eliminate the need for most manual testing.

Automated Test Framework

Before upgrading, create regression tests in ServiceNow’s Automated Test Framework (ATF) that reflect your platform’s current state. Focus your tests on business-critical pathways, such as major incidents, changes, and your most ordered or essential catalogue items. Ensure these tests all pass and rerun them after your upgrade/merge to immediately identify changes (and feed that into OCM) and bugs for immediate remediation. Leverage cloud runner and headless testing to execute these overnight, reducing the amount of manual testing required.

Automate Test Creation

Test recording tools can be used to create regression tests quickly for the upgrade.

Test Generator

You can use the OOB Test generation capability to automate the creation of tests. While this can be useful, it won’t be targeted towards your business-critical pathways, and most tests probably won’t pass, which may cause more work to figure out than the efficiencies gained.

Regress

My homemade tool Regress will record ATF tests as you progress records in the tool. Enable recording and run through your business-critical scenarios, and ATF test steps will be generated as you go that map the current state of the platform. Play these tests back to ensure they pass, and you’ll have a comprehensive regression test bed in no time!

AutomatePro

If you are serious about test automation, looking into more enterprise commercial solutions such as AutomatePro may be worthwhile. With its AutoTest capability, this product can help to automate your whole testing process, both writing and execution. Other DevOps capabilities are shipped with the product to streamline upgrades. While I’ve not used it, I’ve heard many good things about it. Read more on the ServiceNow Store page.

In conclusion

In navigating the upgrade process to Washington DC in ServiceNow, it’s essential to recognize that while complete elimination of development downtime risk may not be feasible, there are strategies to mitigate it effectively. Rushing through upgrades might seem like a solution, yet it introduces its own set of potential complications. Hastily executed upgrades could lead to overlooked testing, jeopardizing the stability and functionality of the platform.

Successful upgrade management extends beyond the upgrade window; it encompasses strategic decisions made before and after the upgrade. Proactive measures such as evaluating new features against existing customizations and addressing technical debt are crucial for long-term platform sustainability.

By adhering to industry-leading practices and leveraging ServiceNow’s CreateNow methodology, organizations can better prepare themselves for upgrades. Maintaining up-to-date business-critical test scenarios and making informed decisions around customization are fundamental steps in this process. Resources such as ServiceNow’s Upgrade Best Practices provide valuable insights to guide businesses through these endeavours.

Ultimately, there isn’t a one-size-fits-all approach to upgrade management. Instead, businesses must assess their appetite for risk and tailor their strategies accordingly. Whether it involves pausing development for a rapid upgrade or adopting a more methodical approach, the goal remains the same: minimizing development downtime while ensuring the integrity and reliability of the ServiceNow instance. Both approaches are complementary and can be adapted to suit each organisation’s unique needs.

TLDR

• Upgrading ServiceNow instance is essential for maintaining currency and support.
• “Tools down” approach commonly used during upgrades.
• Two choices to minimize development downtime during upgrades: continue development or reduce upgrade time.
• Practices for continuing development during upgrades include change freeze, requesting additional instance, leaving OOB configuration unchanged.
• Practices for reducing upgrade time include cloning environments, adopting new features after, building an Upgrade Plan in the Upgrade Center.
• Minimize manual testing using Automated Test Framework (ATF) and other automated testing tools.
• Successful upgrade management requires proactive measures and adherence to industry-leading practices.
• No one-size-fits-all approach to upgrade management; tailor strategies based on organizational needs.