In this blog post, you will learn how to write a bulletproof implementation plan and the activities that precede it to ensure a successful code migration into production using Update sets.

While ServiceNow recommends developers use the more modern platform capabilities to migrate code and configuration, such as application repository and GIT, for BAU (business as usual) activities, Update sets are still the most widely used approach to moving configuration and code. While the process for moving Update sets is pretty standard (Retrieve, Preview, Commit), there are some small tips and tricks you can use during and before your implementation to increase your chances of success. The implementation plan I use can be seen below:

Implementation Plan

1. Install pre-requisite plugins
2. Delete all Retrieved Update Sets in Loaded or Preview State
3. Retrieve all Update Sets from Test/Staging Instance
4. Ensure Update Set ‘CHGXZY’ has been previewed
5. Resolve any errors or conflicts as per Update Set Preview Problems (https://dev205791.service-now.com/sys_update_preview_problem_list.do?sysparm_query=remote_update.nameLIKECHGXZY&sysparm_view=)
6. Commit Update Set ‘CHGXYZ’
7. Set Update Set ‘CHGXYZ’ to “Ignored”

Assumptions

• All configurations are packaged into a single Update Set batch named after the change, e.g. CHGXYZ
• Update set has been completed in Test/Staging environment
• User has admin privileges

Notes

Deleting Retrieved Update Sets

Deleting all Retrieved Update Sets in Loaded or Preview state will delete any Update Sets that have already been pulled into production that are later added to Update Set batches. If already pulled into prod, they won’t be part of your batch and can get missed. That is why this step is important.

Set Update Set to Ignored

All Update Sets with a state of Complete are attempted to retrieve from the source environment, even if they have already been committed. You will notice this when you attempt an update set retrieval after a clone (it takes ages!). To make update retrieval more efficient, set committed update sets to be ignored in production once implemented. Only do this to your batch. For more details, read this blog post by Nia McCash on Why you should set your completed update sets to ‘Ignore’ on production

Prior Planning Prevents Poor Performance

Having a good, consistent implementation plan helps. However, prior planning can be as, if not more, important. The tasks you execute prior to the change window start will ultimately determine your success.

Entitle your instance

Even free applications must be entitled to your instance before installation. Nothing is worse than implementing a change and finding that a pre-requisite plugin is not entitled in production (and therefore cannot be installed) and not having access to the ServiceNow store with a customer account to entitle the instance. Make sure this has been done first so your change goes smoothly!

Testing

Various types of testing are required for an implementation to be successful. UAT (User Acceptance Testing) ensures the implemented change meets the business requirements. SIT testing ensures the code works as designed, and regression testing ensures existing functionality is not broken. You can test your deployment if you have the luxury of a staging environment. If the change is big and complex enough, you may consider cloning over UAT to do a dry run of your implementation plan.

Update Set Packaging

Have a defined approach for packaging update sets into release before your final package hits production. While ServiceNow provides some leading practices for update set management and environment management, there is no prescriptive guidance for update set packaging, as each customer and instance stack is unique. Defining one for your organisation ensures everyone is on the same page and packages configuration consistently and predictably to prevent work from being missed or committed by mistake. My implementation plan assumes all configuration is packaged into a single Update Set batch named after the change.

Reduce/Eliminate Errors

Ideally, your Update set will preview with no errors. Update sets with missing configurations can be added to your retrieved update set batch base from lower environments to fix these before they hit production. Good Update set Packaging procedures and frequent cloning will also go a long way toward preventing update set errors.

One error cannot be resolved – “Cannot commit Update Set :Update scope id is different than update set scope id”. While this error would be resolved lower in your environment stack, read how to prevent this error in my blog post Cannot commit Update Set :Update scope id is different than update set scope id”

While reducing and/or eliminating preview errors is the goal, it cannot be guaranteed (especially in multi-vendor and/or complex environments), so it is best to hope for the best and plan for the worst. Errors can be expected as long as there is a documented treatment plan.

Backout Plan

I can only count the number of times the Back out UI action on Update Sets has successfully backed out the change on a single hand. Alas, fixing forward is almost always the better approach, and it is good to have an “implementation plan” for your back-out plan to be followed when you are under stress to minimise errors. You can also test your backout plan if you have a staging environment.

Isn’t this just a standard change?

If you can make a standardised implementation plan evidenced by multiple successful changes, consider (if not already) proposing a standard change template for your ServiceNow implementation. This may depend on your organisation’s appetite for risk and the complexity of the ServiceNow environment.

TLDR

• Create a standardised, re-usable implementation plan
• Planning is just as important, if not more important than, your implementation plan
• Have a plan for when things go wrong
• Leverage Standard Change
• For everything else Update sets, read my blog Everything you need to know about Update sets