When to Use Update Sets

• Good for: Storing and applying specific versions of applications, deploying patches or changes, and exporting configurations.
• Not suitable for: Installing applications (use the application repository or ServiceNow Store instead).
• Considerations: For team development, publish applications only from a parent instance. Update sets store prior application versions, while the application repository manages the latest versions automatically.

Planning the Update Process

To avoid errors and performance issues, establish a standard process for moving update sets:

• Ensure source and target instances are on the same ServiceNow version to maintain compatibility.
• Limit changes to a single update set for small to medium tasks to simplify review, reduce conflicts, and speed up previews and commits.
• Confirm that base system records share matching sysid fields by cloning production instances for non-production environments.
• Define a clear migration path (e.g., development → test → production) and avoid migrating the same update set from multiple sources.
• Schedule update set commits to production during off-business hours to prevent temporary performance degradation.
• Use clear naming conventions that include references to problem tickets and sequence numbers to coordinate multiple developers and ensure correct application order.
• Understand which customizations are tracked, which dictionary changes are valid, and which can be reversed after application.
• Always verify the correct update set is selected before making changes.

Best Practices for Working with Update Sets

• Never delete update sets to avoid overwriting updated records in future migrations.
• Avoid including the systemid from ldapserverconfig records in update sets, as these IDs differ across instances.
• Do not back out or modify the Default update set to prevent system damage.
• Do not manually change the update set assignment on records; instead, switch to the correct update set, make a trivial change to the record, save it, then back out that change and save again to ensure proper tracking.
• Mark update sets as Complete only when fully ready for migration, and avoid reverting their status back to In Progress. Use additional update sets for ongoing changes and commit them in creation order.
• Use the Merge Update Sets tool to combine update sets instead of manual merging, which compares files and selects the newest versions.
• If issues arise after committing an update set in testing, resolve problems in a new update set, migrate both sets to production, and commit them sequentially.
• Always preview update sets before committing to verify changes.
• Set completed update sets on production instances to Ignore to prevent reapplication during instance cloning.
• Maintain a manual to-do list of post-update set tasks such as manual changes or data loads.
• Make incremental changes and verify each step to reduce risk and complexity.
• Note that updates cannot span multiple domains (e.g., global and TOP) within a single update set.

Next Steps

To begin using update sets, create and select the desired update set as current before making customizations. Follow the outlined best practices and planning steps to ensure smooth migrations and maintain instance stability.