Best practices for migrating Update Sets between instances

[akash_birada]

Hi All,

We regularly migrate Update Sets between Development, Test, and Production environments.

I would like to understand the best practices for:

• Preventing missing dependencies
• Validating update sets before migration
• Handling conflicts during commits
• Maintaining version control

Any guidance from experienced administrators would be helpful.

Thanks.

[vaishali231]

Hey @akash_birada 

When working with Update Sets across Development, Test, and Production, following a structured deployment process helps minimize migration issues.

1. Preventing Missing Dependencies

Keep related changes together in the same Update Set.

Avoid using the Default Update Set for development.

Before promoting, review the Customer Updates (sys_update_xml) records to ensure all expected changes are included.

Make sure dependent components (Script Includes, Business Rules, Client Scripts, UI Policies, Dictionary entries, ACLs, etc.) are also captured.

If the feature spans multiple Update Sets, document and migrate them in the correct sequence.

2. Validating Before Migration

Always Preview the Update Set before committing.

Review any preview problems such as:

Missing dependencies

Skipped records

Collisions

Errors

Commit first in a Test/UAT instance and perform functional validation before promoting to Production.

Verify end-to-end functionality, including flows, notifications, integrations, and security.

3. Handling Conflicts During Commit

Never ignore preview collisions.

Compare the incoming and target versions to determine whether to keep the existing record or apply the incoming change.

If multiple developers are working on the same configuration, coordinate deployments to reduce conflicts.

For complex collisions, resolve them manually and retest before committing.

4. Version Control

Keep in mind that Update Sets are a deployment mechanism, not a version control system.

For better version management:

Use meaningful Update Set names.

Keep Update Sets small and feature-specific.

Close completed Update Sets instead of reusing them.

Maintain release notes for each deployment.

For scoped applications, consider integrating with Git Source Control to manage history, branching, and code reviews while continuing to use Update Sets for instance promotion.

Additional recommendations:

1. Never develop directly in Production.
2. Promote Update Sets in dependency order.
3. Perform peer reviews before migration.
4. Test thoroughly in lower environments before Production deployment.

Following these practices helps reduce missing dependencies, identify issues early through Preview, minimize commit conflicts, and maintain a cleaner deployment process.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[Ankur Bawiskar]

@akash_birada 

Things to handle it safely and smoothly

-> use batching

-> ensure you list down the update sets and the sequences in deployment sheet along with any manual activity like property update etc

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[yashkamde]

Hello @akash_birada ,

Follow this best practices :

• Keep one update set per use case/story.
• Always run Preview before committing never skip it, even for small changes.
• On collisions, compare source vs. target versions before overwriting. Avoid merging update sets; use Batching instead.
• Use clear naming (app + ticket ID + description) and meaningful descriptions.

Also Refer this :

ServiceNow Update Set Leading Practices Part 1 

ServiceNow Update Set Leading Practices Part 2 

If my response helped mark as helpful and accept the solution.

[SohamTipnis]

Hi @akash_birada,

I can tell you how I use them for migrating update sets.

So I basically, most importantly, check the application scope of the instance; if your primary instance is dev, then dev it is. After that, before changing the state to complete, I carefully look at the changes that are made and the things that shouldn't be captured. Only after validating the update set do I save and submit the state to complete. 

Here are the steps I follow:

1. Export the record in XML.
2. Before that, make a folder based on your projects for each story; I create a separate folder. Here I give the name of the folder the same as the story name so that it helps me find it easily whenever I am in a bind.
3. After that I use the Update Source of Test Instance, where I import the XML. While doing that, I start my processing through the beginning, like going to the folder and then selecting that specific file and uploading it.
4. This helps me make sure my update sets are stored safely on my device as well. As you may be aware now, nowadays instances are getting hibernated or going offline, so it is always a best practice to have data stored other than in any ServiceNow instances.
5. As I make a folder for each story, it gives me easy storage for more versions of sprints, which can be more than 1, like e.g., STRY_NO_V1, v2, v3, etc.

This is my approach for my daily work on the update set; may this help you.😀

If you find this article useful, please mark it as helpful and correct. ‌‌‌‌‌‌‌‌‌‌‌😊

Regards,
Soham Tipnis
ServiceNow Developer ||  Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10