Get started with update sets

  • Release version: Zurich
  • Updated July 31, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Get started with update sets

    Update sets in ServiceNow enable you to capture and move customizations between instances, helping you manage application versions, deploy patches, and export changes. They are essential for maintaining consistent configurations across development, testing, and production environments. However, update sets are not designed for installing applications; instead, use the application repository or the ServiceNow Store for that purpose.

    Show full answer Show less

    When to Use Update Sets

    • Storing changes: Capture modifications to base systems or installed applications.
    • Application versioning: Manually create update sets to store particular application versions.
    • Deployment: Deploy patches or changes to installed applications across instances.
    • Limitations: Avoid using update sets for application installation; use the application repository or ServiceNow Store instead.

    Planning the Update Process

    • Ensure both source and target instances run the same ServiceNow version to avoid compatibility issues.
    • Keep update sets focused on small to medium-sized tasks for easier review and reduced conflict risk.
    • Verify that base system records have matching sysid fields by provisioning and cloning instances properly.
    • Maintain a consistent migration path (e.g., development to test, then to production) and avoid migrating the same update set from multiple sources.
    • Schedule committing update sets during off-business hours to minimize temporary performance impacts.
    • Use clear, consistent naming conventions for update sets, including problem ticket numbers and sequence numbers when applicable to ensure correct application order.
    • Understand the types of records and customizations tracked by update sets and which changes can be backed out after application.

    Best Practices for Working with Update Sets

    • Never delete update sets, as this can cause overwritten changes.
    • Exclude the systemid field from ldapserverconfig records to prevent misconfiguration on target instances.
    • Do not back out the Default update set to avoid system damage.
    • Avoid manually altering the Update Set field in customer update records; if changes are made in the wrong set, move them correctly by editing and saving records in the desired update set.
    • Only mark update sets as complete when ready to migrate; create new update sets for additional changes instead of reopening completed ones.
    • Use the Merge Update Sets module to combine update sets safely instead of manual merging.
    • If issues arise after committing an update set to a test instance, create fixes in a new update set and commit in proper sequence to maintain consistency.
    • Always preview update sets before committing to catch potential problems early.
    • Set completed update sets on production instances to "Ignore" to prevent reapplication during cloning.
    • Keep a checklist of manual changes and data loads needed after update set application.
    • Apply incremental changes rather than large batches to ensure accuracy and easier troubleshooting.
    • Note that update sets cannot migrate a single update across multiple domains (e.g., global and TOP domains) in the ServiceNow AI Platform.

    Next Steps

    To begin using update sets, create and select an update set as the current set before making customizations. Follow the planning and best practice guidelines to ensure smooth migration and deployment of your instance changes.

    Because update sets make changes to an instance, review this information to avoid errors and performance issues. Learn how to plan the update process and avoid common mistakes.

    When to use update sets

    Deployment option Good for Future considerations
    Update Sets Storing changes to a base system or installed application.

    Storing and applying a particular version of an application.

    Producing a file for export.

    		 You can manually create update sets to store a particular application version.

    Use update sets to deploy patches or changes to installed applications.

    Note:
    Don’t use update sets to install applications. Instead, use the application repository or the ServiceNow Store to install applications.
    Application Repository Installing and updating applications on all company instances.

    Automatically managing application update sets.

    Restricting access to applications to the same company.

    Deploying completed applications to end users.

    Consider uploading an application to the ServiceNow Store to share it with other users.

    Allows installation of and update to the latest application version only.

    Use update sets to store prior application versions.

    Note:
    If used with team development, publish applications only from a parent instance.

    Plan the update process

    Before working with update sets, create a standard process for moving customizations from instance to instance using this check list:
    1. Check that both instances are on the same version. Customizations may not work if they rely on code that has changed between versions.
    2. Determine the changes to make in a single update set. Complete your update sets as you finish small to medium-sized tasks. As update sets get larger, it becomes harder to review them, takes longer to identify changes within them, increases the risk of conflicts with other update sets, and takes more time to preview and commit them. This is especially true if the update sets contain schema changes or revisions to large workflows or if the set has to be backed out.
    3. Confirm that all base system records have matching sys_id fields. Some base system records are created on an instance after provisioning and don’t match between different instances, leading to problems with update sets. The best way to avoid this issue is to:
      • Provision production and non-production instances.
      • Clone the production instance onto the non-production instance.
    4. Identify a common path for update sets to move from instance to instance and maintain that model. Never migrate the same update set from multiple sources. Move update sets from dev to test and then from test to production.
    5. Plan for when to commit the update sets to production. Avoid committing an update set to a production instance during business hours. The instance may perform more slowly while the update set applies. Rest assured, this slower performance is temporary.
    6. Make sure update set names are clear. Create a naming convention to coordinate changes from multiple developers and to reference when committing the changes to another instance.
      • If update sets are being generated as fixes for problems, consider including the problem ticket in the name (for example, PR10005 - Duplicate Email Issues Fix).
      • If you need more than one update set to address a problem, include a sequence number in the naming convention. Doing so helps ensure that update sets are applied in the order that they were created (for example, PR10005 - Duplicate Email Issues Fix and PR10005.2 - Duplicate Email Issues Fix).
    7. Understand the following about update sets:
      • What records are generated.
      • Which customizations are tracked.
      • Which dictionary changes are valid.
      • Which customizations can be backed out (reversed) after applied.
    8. Before making any customizations, double-check that the correct update set is selected.

    Working with update sets

    Review this information to avoid errors and performance issues.
    • Don’t delete update sets. If an update set is deleted, any updated records may be overwritten in the next update.
    • Don’t include the system_id field from the ldap_server_config record in an update set. An update set from a working configuration points to the wrong system_id node for the target instance and doesn’t work.
    • Don’t back out the Default update set. This action damages the system.
    • Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:
      1. Switch to the desired update set.
      2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
      3. Save the record.
      4. Back out the change just performed, and then save the record again.

        This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set.

    • Don’t mark an update set as Complete until it’s ready to migrate. After an update set is complete, don’t change it back to In progress. Instead, create another update set for the rest of the changes, and make sure to commit them together in the order that they were created. Naming conventions may help in this case (for example, Performance Enhancements and Performance Enhancements 2).
    • Don’t manually merge updates into an update set. Use the Merge Update Sets module. This tool compares duplicate files between update sets and selects the newest version.
    • If a committed update set has a problem in the test instance, build the fix in another update set in the development instance. Commit this set to the test instance, and then make sure both sets are migrated to the production instance and committed in the order they were made.
    • Always preview an update set before committing it.
    • Set completed update set on the production instance to Ignore. This state ensures the update set isn’t reapplied when cloning the instance.
    • Keep a to-do list of manual changes and data loads that must be completed after an update set is applied.
    • Don’t make too many changes at one time. Verify that the correct changes have been made incrementally.
    • You can’t change a single update to update across multiple domains (that is, global and TOP domains). This function isn’t supported in the ServiceNow AI Platform.

    To create an update set see Create and select an update set as the current set.