Claire_Conant
ServiceNow Employee
Options
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago - edited 2 hours ago
Knowing you need to upgrade is only part of the picture; the preparation that matters depends on which kind of upgrade you're doing. Full release-family upgrades, patches within your current release, and non-production dry runs surface different risks, and the steps that prevent problems after the fact differ accordingly.
|
Your situation
|
Go to
|
What to focus on
|
|
Moving to a new release family
|
Path 1
|
Dry run, reporting framework changes, regression checks
|
|
Applying a patch within your current release
|
Path 2
|
Change request conflicts, patch content review, dashboard spot-checks
|
|
Running a non-production dry run before upgrading production
|
Path 3
|
Clone setup, data completeness, timing accuracy
|
Path 1: Moving to a new release family
This is the upgrade type where prep tends to matter most. Major release upgrades can change reporting frameworks, security models, and platform behaviors that affect existing configurations. Catching these before the upgrade runs means fewer surprises to chase afterward.
Preparation checklist
✅ Run Instance Scan. This step identifies customizations that may conflict with your target release. Check the results for anything flagged as incompatible or deprecated. To do this, go to Instance Scan > Suite Results.
✅ Review your current dashboard and reporting state. Note which dashboards use older frameworks and which are already on the current reporting experience. Major upgrades can auto-enable newer reporting frameworks and migrate dashboards; knowing your baseline helps you spot unexpected changes afterward.
✅ Review the release notes and upgrade checklist for your target release. Each release has a planning checklist and a page that lists behavior changes by feature area. Both are worth scanning for anything that touches areas you've customized. To find them: Search for your target release name + "upgrade planning checklist" or "upgrade information" on ServiceNow product documentation.
✅ Test on a non-production instance first. See Path 3 for the setup details that make a dry run meaningful.
- Resources for how to manage and schedule instance upgrades—Schedule through the Instances Dashboard or Upgrade Wizard.
- How to plan patching and upgrade timing—Timing considerations to avoid conflicts and delays.
Path 2: Applying a patch within your current release
Patches within the same release family are lighter than a full family upgrade, but they're not risk-free. You might experience dashboard-related regressions after a patch (not just after major upgrades). And automated change request conflicts can block or duplicate your patch if you have both manual and program-scheduled changes open on the same instance.
Before applying the patch
✅ Does an automated patching change request already exist for your instance? Only one upgrade change is allowed per instance at a time. If an automated patching or end-of-life change is open, you can't create a manual one for the same scope. You can find open changes by going to the Instances Dashboard in Now Support.
✅ Review the patch content for your target version before the patch lands. Check the available patches and hotfixes page for release notes specific to your target patch.
✅ Spot-check your highest-visibility dashboards after patching to make sure that a patch didn't trigger dashboard changes, like reactivating older dashboards or disabling newer ones.
- ServiceNow Patching Program FAQs—Schedule, cadence, and rescheduling options.
- Managing ServiceNow security patching and end-of-life upgrades—How patching and EOL changes work and how to manage them.
- How to plan patching and upgrade timing—Timing considerations for patches.
Path 3: Making your non-production dry run count
A dry run is only as useful as the environment it runs on. Dry runs can produce inaccurate timing and regression data when the non-production instance doesn't match production closely enough. Getting the setup right takes a few extra steps, but it's the difference between a dry run that tells you something useful and one that gives you false confidence.
✅ Clone production with no excluded tables. The default clone excludes attachments, audit logs, and the exclusion list. For an accurate dry run, include all of them. These are often the largest tables on an instance, and schema changes to them account for a significant portion of upgrade time.
✅ Select Full for task table data during the clone. A partial task table skews both timing and skipped records counts.
✅ Run the dry run promptly after cloning. A non-production instance that has been running for weeks with different plugin installations or configuration changes produces results that can't be meaningfully compared to production.
✅ Use sys_upgrade_history_log as your skipped records baseline. This is the most reliable count; other upgrade summary tools use different calculation methods and often show different numbers. Group by the Disposition field for the most reliable count.
Where to go from here
Working through the right path beforehand is what turns an upgrade from something you brace for into something you schedule. Each scenario above points you to the checks that tend to matter for that kind of change, so your prep time goes where it actually moves the needle. If your setup adds complexity, like multi-instance, domain separation, or self-hosting, the same logic holds: identify which path you're on, then layer your environment's specifics on top of it.
