The best approach to have smooth and fast upgrades in ServiceNow is to have someone experienced in your team handling them.
The second-best approach is to follow Chris Schuh’s advice in his nullEDGE session.
I’ve been taking for granted a lot of things he shared because, for a long time, I had great admins in my team who took care of everything.
Key takeaways
If you need strong arguments to justify planning and doing more frequent upgrades, you should view the entire presentation.
I’ll focus on a few topics that really resonated with me.
Cloning
Get comfortable with the cloning process so that you don’t add unnecessary stress when you face an upgrade.
Practice until it feels second nature, to the point you can do it with your eyes closed, and you don’t even blink if you need to apply a rollback.
Sandbox environment
Having a sandbox environment is key to avoiding long blackout periods in your development and test instances.
You can clone from production whenever you need and test upgrades without affecting other developments.
Not mentioned in the video, but my favourite use of the sandbox is for the hypercare period after the go-live:
Keep a clone of the production instance as it was before the upgrade, on the previous version.
It’s perfect for checking whether an incident is related to the upgrade or it’s an old bug.
Automated testing
Automated Test Framework (ATF) is often overlooked or treated as a nice‑to‑have because its benefits aren’t immediate.
Still, executing more tests with better accuracy and relying less on manual clicks during UAT and upgrades gives a peace of mind that’s hard to describe in words.
Back in 2014, when ATF and IntegrationHub were not even in the roadmap, and we were still building integration layers with SOAP (yes, I’m that old!), I created a SOAP UI suite to check all our integrations with a single click. I did it so I could safely refactor everything the day before Christmas… but that’s a story for another day.
The point is that this small effort paid off again and again, because we could execute the suite before every upgrade and confirm that nothing broke.
Documentation
When talking about ATF, Chris mentioned something that made me nod and smile:
Few people document full tests and then store that and refer back to them later, because they’re usually dumped to Confluence and SharePoint.
Painfully true!
And also one of the reasons why I quit my job to build Documate.
If the documentation lives in another system, it will be forgotten or become stale.
If it lives in ServiceNow, it adds context and becomes part of the process.
Communication
It’s impossible to stress enough how important communication is.
The 2-week upgrade is only possible if you start talking to all affected stakeholders at least 6-8 weeks before the execution.
OCM is about selling the benefits. Explaining why it matters, highlight new features and deprecated ones to avoid last-minute surprises and blockers.
We often focus on the technical side of things when the main challenge is managing humans and their expectations.
Tools for store apps
Upgrades are no longer a “once every six months” event really. With store apps, we get upgrades outside of the main release cycle.
Chris mentioned two tools I haven’t personally tested, but that look promising:
References
- Chris Schuh: LinkedIn
- nullEDGE website
- nullEDGE YouTube channel
- My LinkedIn posts #nullEDGEAdvent (any feedback is welcomed!)
- Intro to my nullEDGE advent calendar adventure
