Best Practices to manage skipped updates effectively during upgrades

[dipak_thakor]

Introduction:

When you upgrade your ServiceNow instance (or install an application update), the platform compares your current configuration/customization with the new base system version. Any object (business rule, script include, form layout, field, etc.) that you have customized and that the base system is also trying to change becomes a skipped update (or “skipped change”) because the system will not automatically overwrite your customized version.

• The system keeps track of customizations via the table Customer Updates [sys_update_xml], listing objects you’ve changed.

• During upgrade, if the base system has modified an object that you also modified (or you modified an object the base changed), then the upgrade process will skip applying the base change, and will generate a “skipped update” entry (Disposition = Skipped) for you to review.

• These skipped records show up in the Upgrade History (All → Upgrade Center → Upgrade History), under the “Skipped Changes to Review” related list.

Best Practices:

Here are recommended practices to manage skipped updates effectively:

• Minimise customizations: The more you customize OOB objects, the more likely you’ll incur skipped changes during upgrades. Use config over custom code where possible.

• Establish upgrade governance: Maintain inventory of customizations, track why each exists, score whether still needed. That helps reduce drift and risk.

• Review skipped changes promptly: After every major upgrade (or patch cycle), review the skipped list while it’s fresh and the upgrade team is active. Don’t wait until after many releases.

• Use the Merge tool intelligently: When you review a skipped record, use the diff/merge UI to see base changes vs customization and consciously decide. Merge tool can be accessed via System Diagnostics > Upgrade History>Release/Patch name, open a skipped record and click "Resolve Conflicts"

• Propagate decisions downstream: If you set “Reviewed and Retained” or “Merged” in Dev, ensure update sets or configuration are moved to Test/Prod so you don’t re-review same records again.

• Prioritise P1 / high-impact skips: Focus first on skipped updates with high priority (critical bug fixes, security patches) before less critical ones.

• Monitor skipped record volume: If you see tens of thousands of skipped records regularly, consider a refactoring or “go-back-to-baseline” approach rather than trying to manually reconcile all.

• Document decisions: For audit and future context, add comments to each skipped record review explaining why you retained/customised/reverted.