ServiceNow Update Sets: The Complete Guide to Migration Mastery

Update Sets are the de facto mechanism for moving customizations between ServiceNow instances. They're how you promote from dev to test to production, share work with teammates, and recover when something goes wrong. Yet they're also one of the most misunderstood features in the platform — responsible for countless broken references, missing dependencies, and deployment failures that could have been avoided.

This guide covers everything from basic captures to advanced remote migration patterns. Whether you're moving your first customization to production or managing a complex multi-instance migration, these patterns will save you hours of troubleshooting.

How ServiceNow Update Sets Work

An Update Set is essentially a named container that tracks changes made to your instance. ServiceNow automatically records any customization — whether made through the UI or script — as a change artifact within the active Update Set. When you capture an Update Set, you're exporting a batch of these change artifacts as an XML document that can be applied to another instance.

The critical thing to understand: Update Sets are not a snapshot of the target state — they're a log of changes made. When you apply an Update Set, ServiceNow replays those changes on the target instance. This distinction matters enormously for conflict resolution.

What Gets Captured vs. What Doesn't

Captured automatically:

• Table schema changes (new columns, modified properties)
• UI policies and actions
• Business Rules, Client Scripts, Script Includes
• ACLs, Dictionary entries
• Flow Designer flows (as of Rome)
• Homepages, dashboards, form designs

NOT captured — must handle manually:

• Data in tables (incident, sc_request, etc.)
• Schedules, cron jobs, import sets
• Users, groups, roles, and group memberships
• System properties (some — check individually)
• MID Server configurations
• LDAP integrations
• Performance metrics and statistics

This is where most developers get burned. They capture an Update Set, apply it to prod, and wonder why half their form layout is broken. The answer is almost always a missing dependency that wasn't in the Update Set.

The Update Set Lifecycle: A Practical Workflow

Step 1: Plan Before You Capture

Before you create your first Update Set, answer these questions:

1. What is the scope? A single feature, or multiple related changes?
2. What are the dependencies? Does this change extend another table, reference a script include, or depend on a new field?
3. Is this a new table or modifications to an existing one? Existing table changes are usually safe; new tables need data migration planning.
4. Are there any system properties involved? Some need to be manually recorded.

Rule of thumb: One logical feature per Update Set. Don't dump your entire dev backlog into a single Update Set labeled "misc changes." Smaller, focused Update Sets are easier to review, troubleshoot, and roll back.

Step 2: Name Your Update Sets Intelligently

Generic names like "My Changes" or "Update Set 12" tell you nothing. Use a naming convention:

{project}-{feature}-{ticket-id}-{date}

Examples:

• hcm-onboarding-v2-gus-1234-20260427
• itsm-escalation-rules-it-5678
• portal-fixes-feb-patch

Include the ticket/issue ID so you can trace back to the original work, and a version number for iterative changes. Date-stamping prevents confusion when you have multiple parallel efforts.

Step 3: Review Before Applying

Never apply an Update Set without reviewing it first. In ServiceNow, navigate to System Update Sets → View XML. Look for:

• Unexpected artifacts — Did something get captured that shouldn't be there? (e.g., a deleted record, or a change from a different feature)
• Missing dependencies — Are all referenced Script Includes included?
• Order of operations — Some changes must apply before others. Table schema changes must precede data changes.

The XML preview also lets you catch sensitive data (test credentials, hardcoded URLs) before they reach production.

Remote Update Sets: Cross-Instance Migrations

Remote Update Sets solve the "dev and prod are on different instances" problem. Instead of manually exporting and importing XML, ServiceNow pushes Update Sets over a direct connection.

Setup: Connecting Two Instances

On the target instance (where you want to receive the Update Set):

1. Navigate to System Update Sets → Remote Instances
2. Create a new connection:
   • Name: A friendly label (e.g., "Dev Instance")
   • URL: The source instance URL (e.g., https://dev.instance.service-now.com)
   • Username/Password: Credentials for a service account on the source instance
   • Test Connection — Always test before saving

Security note: Use a dedicated service account with minimal roles. It only needs to be a member of the xml_import group on the target and xml_export group on the source.

On the source instance:

1. Navigate to System Update Sets → Remote Instances
2. The target instance should appear in the Remote Instances list
3. Mark it as Available for Remote Update Sets

Back on the target instance, you can now retrieve Update Sets directly from the source.

The Retrieve Process

Once connected:

1. On the target instance, go to System Update Sets → Retrieved Update Sets
2. Click Retrieve Remote Update Sets
3. Select the source instance and the specific Update Set to retrieve
4. ServiceNow pulls the XML and creates a local record in sys_update_xml

This approach has a major advantage over file-based transfers: the Update Set history is preserved, including metadata about who made each change and when.

Handling Conflicts: When Updates Collide

Conflicts happen when the same artifact has been modified on both the source and target instance. ServiceNow provides three conflict resolution strategies:

Strategy 1: Auto-Conflict Resolution

Navigate to System Update Sets → Preferences and set the default conflict behavior:

• Current Update Only — Only apply the incoming change; ignore conflicts
• Remote Update Only — Overwrite whatever is on target with incoming
• Do Not Apply — Skip conflicting artifacts entirely

For most cases, "Remote Update Only" is appropriate when you control the target instance. "Do Not Apply" is safer for sensitive production environments where you want to manually review every conflict.

Strategy 2: Manual Conflict Resolution

For anything complex, do it manually:

1. Open the Update Set on the target instance
2. Find the artifact with a conflict
3. View the side-by-side comparison (ServiceNow shows the incoming XML vs. the current target XML)
4. Choose which version to keep, or edit the artifact manually

Strategy 3: The "Overlap" Pattern for Parallel Development

When two developers work on the same table simultaneously:

1. Developer A captures and applies changes to prod first
2. Developer B's Update Set now conflicts with what's on prod
3. Instead of overwriting, Developer B captures a new Update Set that contains only the differences between their dev and the current prod state

The easiest way to do this: after Developer A applies, have Developer B re-apply their changes on a fresh dev instance synced to the new prod state, then capture a new Update Set from that clean state.

Common Update Set Problems and Fixes

Problem: Ghost Records After Application

Symptoms: Applied an Update Set, but records that should have been created didn't appear, or old records that should have been deleted are still there.

Cause: Update Sets capture changes, not target state. If a record existed on the source before you started but doesn't exist on target, the Update Set won't create it.

Fix: Before applying, document the expected state of the target. Use a comparison tool or manual audit to identify delta records that need manual creation.

Problem: Broken References After Migration

Symptoms: Form layouts are jumbled, related lists are empty, or lookups point to wrong or deleted records.

Cause: The Update Set captured an artifact with references (sys_id, name, etc.) that don't exist on the target. This commonly happens with group memberships, user assignments, and form designs that reference columns added as part of the same Update Set.

Fix: Apply schema changes separately from data changes, and apply them in the correct order — schema first, then references. For form layouts specifically, export and review the XML to catch stale sys_ids before applying.

Problem: Script Include Conflicts

Symptoms: Flows or business rules fail to load with "Script source file not found" or similar errors.

Cause: Two Update Sets modified the same Script Include. Whoever applied last overwrites the previous changes — but both sets claim the same file.

Fix: Never split modifications to the same Script Include across multiple Update Sets. When merging parallel work, consolidate Script Include changes into a single atomic Update Set.

Advanced Pattern: Capturing Only What You Changed

By default, ServiceNow captures every modification to every artifact during the Update Set window. But sometimes you want fine-grained control.

Using the "Selective Update Set" Pattern

1. Create a new empty Update Set
2. For each change you want to capture, temporarily make it while this Update Set is active
3. After each change, immediately commit it to a child Update Set (nested under the parent)
4. When done, you have a parent Update Set that groups related child Update Sets

This lets you review child Update Sets individually before applying them, and selectively apply only the ones relevant to a given deployment.

Capture Scripts via Background Script

For scripted changes that the UI might not capture cleanly, use a background script to explicitly add artifacts to an Update Set:

// Run this while your target Update Set is active
var updateSetId = 'YOUR_UPDATE_SET_SYS_ID';
var artifactTable = 'sys_script_include';
var artifactSysId = 'SCRIPT_INCLUDE_SYS_ID';

var gr = new GlideRecord('sys_update_xml');
gr.addQuery('name', artifactSysId);
gr.addQuery('update_set', updateSetId);
gr.query();

// If not already in the set, force-add it
if (!gr.next()) {
    var artifact = new GlideRecord(artifactTable);
    if (artifact.get(artifactSysId)) {
        var ugr = new GlideRecord('sys_update_xml');
        ugr.initialize();
        ugr.setValue('name', artifactSysId);
        ugr.setValue('table', artifactTable);
        ugr.setValue('update_set', updateSetId);
        ugr.setValue('type', 'T');
        ugr.insert();
        gs.info('Added ' + artifact.getValue('name') + ' to Update Set');
    }
}

Update Sets andScoped Applications

Scoped applications (apps with a specific namespace) behave differently with Update Sets:

• Scoped app changes do NOT auto-capture in standard Update Sets
• To capture scoped app changes, use the Application Files module: right-click a file → "Add to Update Set"
• Alternatively, use Application Repository for Git-style versioning (recommended for serious development)

If you're building a scoped app, prefer the Application Repository approach over Update Sets for team collaboration. Update Sets work for scoped apps but are clunky for true version control workflows.

Automation: Automating Update Set Exports

For CI/CD pipelines or regular sync jobs between instances, automate exports via REST:

// On source instance — generate Update Set XML
var updateSetSysId = 'YOUR_UPDATE_SET_SYS_ID';
var r = new snc.AdobeSignUtil().generateUpdateSetXML(updateSetSysId);
// Then retrieve via REST API on target instance

Or use the Flow Designer to trigger automatic exports when a branch is merged, or on a schedule.

For regular prod-to-dev refreshes, consider a clone instead of Update Sets — clones give you a complete copy of prod data in dev, whereas Update Sets only capture customizations.

Quick Checklist Before Applying to Production

• Update Set reviewed in XML view — no unexpected artifacts
• All dependencies identified and included
• System properties documented and ready to apply separately
• Conflict resolution strategy decided for each anticipated conflict
• Target instance backed up or in a non-critical environment first
• Schedule a maintenance window if the Update Set touches high-traffic tables
• Rollback plan documented — know how to revert if something breaks

FAQ

Q: Can I apply an Update Set from a newer ServiceNow version to an older instance? Generally no — Update Sets don't support cross-version migration when the source has features not available on the target. Attempting to apply incompatible updates will result in errors or silent failures. Always migrate from older to newer versions.

Q: Should I use Update Sets or Application Repository for my scoped app? Application Repository. Update Sets are for tracking individual customizations. For scoped apps with true versioning needs, Git-based Application Repository is the right tool.

Q: What happens to in-flight records when I apply an Update Set? Update Sets apply changes transactionally within the Update Set. In-flight records (records being actively edited during application) are not affected. However, any schema changes in the Update Set take effect immediately upon application, which can cause unexpected behavior for users currently on affected forms.

Q: Can I undo an Update Set after applying it? Yes — but only if you captured it. ServiceNow stores the "before" state in sys_update_xml records. To revert, open the Update Set on the target and select Revert Entire Update Set. This reverses all changes in the set. Note that data created by the Update Set is not automatically cleaned up.

Q: How do I include existing records in an Update Set? Records (data rows) are not included by default. To include existing records, export them as XML from the source table and import to the target separately — or use the Data Shipper plugin for bulk data transfers between instances.

Conclusion

Update Sets are powerful but unforgiving. The gap between "it worked in dev" and "it works in prod" is almost always a missing dependency, an unhandled conflict, or a wrong application order. The practices in this guide — focused Update Sets, XML review before application, explicit dependency tracking, and a clear conflict resolution strategy — will dramatically reduce your deployment failures.

If there's one habit to adopt today: always open the XML view before applying any Update Set to production. You'll catch 80% of potential issues in under five minutes.

Want more ServiceNow deployment patterns? Check out the SN-Tricks Scripts Library for ready-to-use deployment scripts and utilities.