[{"data":1,"prerenderedAt":352},["ShallowReactive",2],{"page-\u002Fblog\u002Fservicenow-upgrade-skipped-changes-checklist":3},{"id":4,"title":5,"author":6,"authorUrl":7,"body":8,"date":327,"dateUpdated":327,"description":328,"dqid":327,"excerpt":329,"extension":330,"faq":331,"headline":344,"meta":345,"navigation":346,"path":347,"seo":348,"socialImage":349,"stem":350,"__hash__":351},"content\u002Fblog\u002Fservicenow-upgrade-skipped-changes-checklist.md","ServiceNow Upgrade Checklist: How to Review Skipped Changes Safely","SN-Tricks","https:\u002F\u002Fsn-tricks.com\u002Fabout",{"type":9,"value":10,"toc":307},"minimark",[11,15,23,26,31,34,37,53,56,60,63,66,86,89,93,96,103,107,110,131,134,138,141,161,164,167,171,174,179,182,186,189,193,196,199,203,206,209,238,241,245,248,251,255,258,261,287,291,294,297,301,304],[12,13,14],"p",{},"A ServiceNow family upgrade is not complete when the upgrade engine finishes. The real work is proving that your business processes, integrations, security controls, and customizations still behave correctly.",[12,16,17,18,22],{},"The most important evidence often appears in ",[19,20,21],"strong",{},"Upgrade History",", especially the skipped changes list. A skipped record means ServiceNow detected a customer modification and preserved it instead of automatically replacing it with the new out-of-box version. That protection prevents data loss, but it also leaves your instance without some vendor changes until you review the record.",[12,24,25],{},"Use this checklist to turn skipped changes into deliberate decisions rather than last-minute production surprises.",[27,28,30],"h2",{"id":29},"_1-start-with-a-fresh-production-clone","1. Start with a Fresh Production Clone",[12,32,33],{},"Upgrade testing is useful only when the sub-production instance resembles production. Clone production into a dedicated test or upgrade environment before beginning your technical review.",[12,35,36],{},"Before the clone:",[38,39,40,44,47,50],"ul",{},[41,42,43],"li",{},"Preserve any test-only configuration that must survive.",[41,45,46],{},"Confirm integrations, email, and scheduled jobs will be disabled or redirected.",[41,48,49],{},"Identify sensitive production data that requires masking.",[41,51,52],{},"Record the production build, plugins, store application versions, and activated features.",[12,54,55],{},"After the clone, validate that the instance has the expected users, groups, update sets, custom tables, and integration configuration. A stale clone can produce a reassuring but inaccurate test result.",[27,57,59],{"id":58},"_2-inventory-customizations-before-the-upgrade","2. Inventory Customizations Before the Upgrade",[12,61,62],{},"Do not wait for skipped changes to tell you what has been customized. Build an inventory of business rules, script includes, client scripts, UI policies, ACLs, notifications, workflows, flows, integrations, and modified dictionary records.",[12,64,65],{},"For each important customization, capture:",[38,67,68,71,74,77,80,83],{},[41,69,70],{},"Business purpose",[41,72,73],{},"Technical owner",[41,75,76],{},"Business owner",[41,78,79],{},"Tables or processes affected",[41,81,82],{},"Test case",[41,84,85],{},"Whether a supported extension point now exists",[12,87,88],{},"This inventory makes review faster because the team can distinguish intentional business behavior from an abandoned experiment.",[27,90,92],{"id":91},"_3-upgrade-sub-production-and-capture-the-baseline","3. Upgrade Sub-Production and Capture the Baseline",[12,94,95],{},"Run the upgrade in sub-production first. Record its start and finish time, duration, warnings, errors, and counts of upgraded and skipped records. These numbers become a baseline for the production change plan.",[12,97,98,99,102],{},"Review ",[19,100,101],{},"System Diagnostics > Upgrade History"," and open the completed upgrade record. Export or assign the skipped changes list so that every item has an owner and resolution status. Avoid resolving records directly in production without first validating the decision in the upgraded clone.",[27,104,106],{"id":105},"_4-triage-skipped-changes-by-risk","4. Triage Skipped Changes by Risk",[12,108,109],{},"Not every skipped record deserves equal attention. Prioritize records that can affect availability, access, or transaction volume:",[111,112,113,116,119,122,125,128],"ol",{},[41,114,115],{},"ACLs, authentication, and security-related scripts",[41,117,118],{},"Business rules and script includes on high-volume tables",[41,120,121],{},"Incident, request, change, and catalog workflows",[41,123,124],{},"Inbound and outbound integrations",[41,126,127],{},"Notifications and scheduled jobs",[41,129,130],{},"User interface changes",[12,132,133],{},"Also flag records with no known owner. An undocumented customization on a critical table is a risk even when its code looks simple.",[27,135,137],{"id":136},"_5-compare-all-three-versions","5. Compare All Three Versions",[12,139,140],{},"A good skipped-change review considers three versions:",[38,142,143,149,155],{},[41,144,145,148],{},[19,146,147],{},"Customer version:"," the customized record currently active",[41,150,151,154],{},[19,152,153],{},"Previous baseline:"," the out-of-box version before the upgrade",[41,156,157,160],{},[19,158,159],{},"New baseline:"," the version delivered by the target release",[12,162,163],{},"The difference between the customer version and previous baseline reveals what your team changed. The difference between the previous and new baselines reveals what ServiceNow changed. This separation is essential: comparing only the customer version with the new baseline mixes both sets of changes and makes intent harder to identify.",[12,165,166],{},"Use the upgrade comparison tools to inspect the fields and script differences. For scripts, look beyond added lines. Check changed conditions, execution order, APIs, null handling, roles, and queries.",[27,168,170],{"id":169},"_6-choose-retain-revert-or-merge","6. Choose Retain, Revert, or Merge",[12,172,173],{},"Every skipped change should end with one documented decision.",[175,176,178],"h3",{"id":177},"retain-the-customization","Retain the customization",[12,180,181],{},"Retain it when the business requirement still exists and the new baseline does not address it. Confirm that the code uses supported APIs and still works in the target release.",[175,183,185],{"id":184},"revert-to-the-new-baseline","Revert to the new baseline",[12,187,188],{},"Revert when the customization is obsolete, duplicates new platform behavior, or was never intended for production. Test the affected process after reverting.",[175,190,192],{"id":191},"merge-both-versions","Merge both versions",[12,194,195],{},"Merge when you need the business customization and ServiceNow's new fixes or features. Rebuild the smallest possible customization on top of the new baseline rather than copying the entire old script forward.",[12,197,198],{},"For every outcome, record the rationale, reviewer, date, test evidence, and deployment method.",[27,200,202],{"id":201},"_7-test-business-outcomes-not-just-forms","7. Test Business Outcomes, Not Just Forms",[12,204,205],{},"A form that loads without errors does not prove an upgrade succeeded. Test complete user journeys and their downstream effects.",[12,207,208],{},"Your regression suite should cover:",[38,210,211,214,217,220,223,226,229,232,235],{},[41,212,213],{},"Creating, assigning, resolving, and reopening incidents",[41,215,216],{},"Submitting catalog items and completing approvals",[41,218,219],{},"Standard, normal, and emergency change paths",[41,221,222],{},"SLAs, notifications, and escalations",[41,224,225],{},"Employee or customer portal journeys",[41,227,228],{},"Virtual Agent topics and handoffs",[41,230,231],{},"Discovery, event processing, and CMDB updates",[41,233,234],{},"REST, SOAP, email, MID Server, and IntegrationHub transactions",[41,236,237],{},"Role-based access for agents, fulfiller groups, and requesters",[12,239,240],{},"Include negative tests. Verify that unauthorized users cannot read or modify protected data and that failed integrations create visible, actionable errors.",[27,242,244],{"id":243},"_8-measure-performance-before-and-after","8. Measure Performance Before and After",[12,246,247],{},"Compare objective results between the pre-upgrade and upgraded environments. Review slow transactions, node logs, scheduled job duration, flow execution time, integration latency, and query behavior on heavily used tables.",[12,249,250],{},"Pay special attention to custom scripts that query inside loops, run synchronously, or execute on every update. An upgrade may expose an existing inefficiency because platform behavior or data volume has changed.",[27,252,254],{"id":253},"_9-rehearse-the-production-upgrade","9. Rehearse the Production Upgrade",[12,256,257],{},"After remediation and user acceptance testing, repeat the process on a newly refreshed clone if time allows. A rehearsal confirms the final sequence, validates update sets or application deployments, and produces a realistic outage estimate.",[12,259,260],{},"Your production runbook should include:",[38,262,263,266,269,272,275,278,281,284],{},[41,264,265],{},"Named owners and decision points",[41,267,268],{},"Pre-upgrade backups and verification",[41,270,271],{},"Integration pause and resume steps",[41,273,274],{},"Ordered remediation packages",[41,276,277],{},"Smoke tests for critical services",[41,279,280],{},"Monitoring queries and dashboards",[41,282,283],{},"Rollback or escalation criteria",[41,285,286],{},"Communication checkpoints",[27,288,290],{"id":289},"_10-monitor-after-go-live","10. Monitor After Go-Live",[12,292,293],{},"For the first 24 to 72 hours, monitor failed transactions, integration queues, flow executions, email delivery, scheduled jobs, authentication, and support volume. Compare results with the baseline captured during rehearsal.",[12,295,296],{},"Do not close the upgrade solely because users can log in. Close it when critical tests pass, skipped changes are accounted for, operational metrics are stable, and unresolved issues have owners.",[27,298,300],{"id":299},"final-thoughts","Final Thoughts",[12,302,303],{},"ServiceNow upgrades become predictable when every customization has an owner, every skipped change has a decision, and every decision has test evidence. The goal is not to preserve all custom code or blindly accept every new baseline. It is to keep required business behavior while adopting platform fixes and reducing future maintenance.",[12,305,306],{},"Treat the upgraded clone as a rehearsal, not a sandbox. That discipline turns upgrade weekend from guesswork into a controlled release.",{"title":308,"searchDepth":309,"depth":309,"links":310},"",2,[311,312,313,314,315,316,322,323,324,325,326],{"id":29,"depth":309,"text":30},{"id":58,"depth":309,"text":59},{"id":91,"depth":309,"text":92},{"id":105,"depth":309,"text":106},{"id":136,"depth":309,"text":137},{"id":169,"depth":309,"text":170,"children":317},[318,320,321],{"id":177,"depth":319,"text":178},3,{"id":184,"depth":319,"text":185},{"id":191,"depth":319,"text":192},{"id":201,"depth":309,"text":202},{"id":243,"depth":309,"text":244},{"id":253,"depth":309,"text":254},{"id":289,"depth":309,"text":290},{"id":299,"depth":309,"text":300},"2026-07-27","Use this practical ServiceNow upgrade checklist to review skipped changes, test customizations, validate integrations, and reduce production upgrade risk.",null,"md",[332,335,338,341],{"question":333,"answer":334},"What is a skipped change in a ServiceNow upgrade?","A skipped change is an out-of-box record that ServiceNow did not overwrite during an upgrade because the record had been customized. The existing customization remains active until an administrator reviews the difference and chooses how to resolve it.",{"question":336,"answer":337},"Should I revert every skipped change to the ServiceNow baseline?","No. Reverting everything can remove valid business logic, while retaining everything can hide platform improvements. Review the customized, previous baseline, and new baseline versions, then document whether to retain, revert, or merge each record.",{"question":339,"answer":340},"When should ServiceNow upgrade testing begin?","Begin with planning and inventory before the first sub-production upgrade. After cloning production into a test environment, upgrade that clone early enough to allow technical remediation, integration testing, user acceptance testing, and at least one rehearsal.",{"question":342,"answer":343},"How do I reduce skipped changes in future ServiceNow upgrades?","Prefer configuration, extension points, scoped applications, Flow Designer, and supported APIs over direct edits to out-of-box records. Record the purpose and owner of every necessary customization so future reviewers can make faster decisions.","A Practical ServiceNow Upgrade Checklist for Skipped Changes and Testing",{},true,"\u002Fblog\u002Fservicenow-upgrade-skipped-changes-checklist",{"title":5,"description":328},"\u002Fimages\u002Fblog\u002Fservicenow-upgrade-skipped-changes.jpg","blog\u002Fservicenow-upgrade-skipped-changes-checklist","iWpsohMgXyx2zZogy41Av-3lgCPDfBWEizs2fnwNbsg",1786921299114]