If you've ever kicked off a full ServiceNow upgrade and felt like you were starting completely from scratch, even though your team went through this exact exercise a year ago, you already know the real cost of upgrades. It isn't any single technical blocker. It's that nothing carries forward. That feeling is what pushed me to build a Platform Academy session around Guided Upgrade Console, ServiceNow's tool for planning, coordinating, and carrying forward decisions across full release upgrades. I walked through the four areas the Console is organized around, shared a customer scenario illustrating the impact of adopting it, and ran a live demo on an Australia-release instance covering the process from pre-upgrade tasks through post-upgrade verification. The full recording is available here.
When I asked the session audience about their current upgrade practices, the responses confirmed what I hear constantly in customer conversations: most teams patch regularly, but full upgrades happen far less often. A lot of the room said they cap full upgrades at once a year, even while patching consistently. I also asked something more pointed: what was the hardest part of your last full upgrade? Two answers dominated, and they were nearly tied, together accounting for the large majority of responses: discovering issues too late (skipped records, deprecated features, and conflicts that only surface once the upgrade window is open) and coordinating work across admins, developers, QA, and business owners.
In this post
The Road to the Agentic Layer
Guided Upgrade Console isn't new, but what it does, and what it's called, has changed with almost every release. Here's the quick version:
Version requirement: Naming has changed across releases, so check both terms depending on what you're running. In Yokohama, this capability is called "Upgrade Management." From Xanadu onward, it's been renamed "Upgrade Console". The agentic capabilities covered later in this post, application compatibility true-up and predicted skip records, ship as part of version 3.x, available only on the Australia release (Early Availability opened April 1, 2026; General Availability lands at Knowledge26). Xanadu and earlier give you Upgrade Console, just not yet that agentic layer.
Guided Upgrade Console is native to the ServiceNow AI Platform, meaning it doesn't require a separate install once an instance is on a qualifying release; it's also listed as a free scoped application in the ServiceNow Store, so if you don't see it natively yet on your release, that's the other place to check. It brings upgrade tools, tasks, and status signals into one interface, organized across its three stages, Pre-upgrade, Instance upgrade, and Post-upgrade, and visible to the whole team.
|
📋
Pre-upgrade
|
→
|
🚀
Instance
upgrade |
→
|
✅
Post-upgrade
|
The three stages that organize every task inside Guided Upgrade Console
The Console is organized around four areas built on top of those three stages: centralized readiness, pre-upgrade insights, a coordinated workspace, and a repeatable playbook. Here's how each one works.
Centralized Readiness
Why it matters: every context switch during an upgrade costs time spent reconstructing information you already had once, whether that's which tool has the current status or which thread has the latest decision. Centralized readiness exists to remove that reconstruction entirely.
What's shipping: one dashboard that every role can view, designed to contain what each person needs to see rather than exported into a separate spreadsheet per stakeholder:
- Platform admin: skip records and technical blockers.
- Developer: code conflict resolutions.
- QA lead: test execution status.
- Business owner: a plain-language summary rather than technical detail.
- Upgrade lead: the full roll-up across every role at once.
What this means for customers: nobody has to reconstruct someone else's status secondhand. Mechanically, this starts the moment the Console is opened. It leads with an overview screen surfacing the instance summary and readiness signals, a snapshot of where things stand before committing to anything. Starting a guided upgrade from there creates a dedicated Guided Upgrade tab that lays out sequential pre-upgrade tasks in order, so the team works through one ordered checklist inside the same interface instead of a to-do list spread across tools and owners.
Guided Upgrade Console overview screen with the instance readiness snapshot
Sharon, who hosted the session, asked me directly why this is worth the learning curve when teams are already under pressure and know the old way of doing things. My answer centered on context switching. The traditional upgrade process requires holding a mental map of which tool has the current status and which thread has the latest decision, and each switch costs time spent reconstructing information I already had once. Centralizing that into one control pane removes the need to reconstruct that context in each cycle.
Pre-Upgrade Insights
Why it matters: this is the direct answer to "discovering issues too late," the theme that tied for the top spot in our poll on hardest upgrade challenges.
What's shipping: the Console scans an instance's customizations and installed applications against what the target release will change, then prioritizes the results by severity and business impact, with inline guidance on resolution options attached to each item. All of this lives inside a single stage called Pre-upgrade, which walks the team through a seven-item checklist, in order:
- Review release notes
- Cloning
- Choose an upgrade plan
- Automate upgrade tasks
- Conduct pre-testing
- Preview application upgrades
- Review predicted skipped records
What this means for customers: conflicts get surfaced and assigned to an owner before the upgrade window opens, not during it. Two of those checklist items carry most of the mechanical depth worth walking through here.
The first several checklist items set up the cycle: reviewing the release notes for what's changing, cloning production down to sub-production to test against a realistic copy of the instance, choosing (creating or importing) an upgrade plan, configuring automated upgrade tasks, including ATF test generation, and conducting pre-testing against that cloned instance so the tests needed for post-upgrade verification are already queued up before the upgrade runs.
Preview application upgrades is next on the checklist, and it's what handles application compatibility true-up. The Console fetches an inventory of every application installed on the instance, store apps and custom scoped apps alike, and checks each one against what the target release supports, flagging for each app whether the installed version is already compatible or whether a newer compatible version needs to go in first. Sharon called this one out specifically during the session: getting that answer used to mean manually cross-referencing store listings and release notes app by app. The Console now runs the check automatically as its own checklist item, right inside Pre-upgrade.
The last item on the Pre-upgrade checklist, Review predicted skipped records, is where predicted skip records live. A skip record occurs when an incoming release would overwrite a record that's been customized: rather than silently applying the base system version and erasing the customization, the upgrade skips that record and logs it so a person can decide whether to keep the customization or accept the new baseline. That decision point traditionally surfaces only after the upgrade has already run. Guided Upgrade Console instead predicts these skip records right in this checklist item, comparing customized records against what the target release will change, so a skip record rule can be applied and an owner assigned to make the call in advance, rather than the conflict surfacing mid-window.
Predicted skip records list, ranked by severity and business impact, with an owner assigned to each item before the upgrade window opens.
Once that predicted list exists, the Console doesn't treat every record on it the same way, and all of what follows happens inside this one Review predicted skipped records checklist item, not as a separate stage of its own. Each predicted skip record carries a priority tier, and that tier decides how it gets resolved. That split is what makes this checklist item manageable at volume: automation clears the noise, and the diff/merge viewer gives a person the exact comparison they need for the calls genuinely worth their time.
How Predicted Skip Records Get Resolved
|
⚡
Auto Resolve
Priority P4 – P5
Skipped Record Rules clear these automatically, with no human involvement. In practice, this is often the bulk of the list. |
🔍
Manual Resolve
Priority P1 – P3
Opens in a diff/merge viewer, a color-coded, line-by-line comparison, so a person can decide whether to keep the customization, accept the base version, or merge the two. |
One real deployment example makes the scale of that split concrete: on a single patch, 132 of 136 skipped records were resolved automatically by Skipped Record Rules, leaving just 4 for manual review in the diff/merge viewer. That's the ratio this layer is built around: automation absorbing the high-volume, low-risk decisions so the team's attention goes to the handful that actually need it.
Review before you activate: out-of-the-box Skipped Record Rules have shipped active by default since Xanadu. That's convenient, but it cuts both ways: an active rule can auto-resolve a record that actually contains a base-system change worth a human look, not just your customization being safely overwritten. Review each OOB rule's target conditions and actions before your first automated run, not after.
Two things came up in Q&A that are worth flagging here because they'll matter to anyone relying on this pillar. First, an attendee asked why a customization they'd removed no longer surfaced as a skip record. The answer: once you create a skip record rule for a given record, that rule persists in the skip record rules table and continues to apply in future cycles. The Console is honoring your prior decision, not re-evaluating it. If you want to reassess a record, go to the Skip Record Rules Editor under Upgrade Center and deactivate or delete the rule; reviewing your existing rules before each cycle is worth building into your own playbook. Second, someone asked whether the Console would automatically surface Known Errors published through the Known Error Portal. Right now it doesn't; it surfaces predicted skip records and compatibility signals based on your instance's customization profile, but Known Error Portal integration isn't there yet. I took that feedback live and flagged it to the development team — more on where that conversation stands in the What's Next section below.
"Your next upgrade doesn't have to feel like your last one. It can be easier."
Coordinated Workspace
Why it matters: this is the direct answer to the second most common poll response, coordinating work across admins, developers, QA, and business owners.
What's shipping: upgrade tasks are assigned across all of those stakeholder roles with clear ownership attached to each one. As each person completes their assigned task, status rolls up automatically to the upgrade lead, and built-in comment threads keep decisions attached to the work itself instead of scattered across a separate email chain.
What this means for customers: scheduling the Console's own Instance upgrade stage, the stage that sits between Pre-upgrade and Post-upgrade. Unlike the checklists on either side of it, Instance upgrade holds a single task, Schedule upgrade. Once pre-upgrade decisions are recorded across the team, that one task is where the upgrade window gets scheduled.
How status rolls up: as each stakeholder completes their assigned task, status updates automatically to the upgrade lead's roll-up view, so there's no separate status meeting or exported spreadsheet required to know where the cycle stands.
Repeatable Playbook
Why it matters: the first three pillars only pay off long-term if the decisions they produce don't have to be remade from zero next cycle. Repeatable playbook is where that carry-forward actually happens.
What's shipping: mechanically, this lives in the Console's Post-upgrade stage, the checklist that runs once Instance upgrade's Schedule upgrade task completes:
- Review skipped records
- Store application upgrades
- Conduct post-testing
- Prepare next environment
What this means for customers: every decision made across the cycle, compatibility calls, skip record resolutions, test outcomes, becomes the starting point for the next one instead of getting rebuilt. Review skipped records here is a second, post-hoc pass, distinct from the Review predicted skipped records checklist item back in Pre-upgrade. Where that earlier item gets ahead of conflicts before the window opens, this Post-upgrade item confirms how those predictions actually played out once the upgrade ran, and surfaces anything that wasn't predicted in advance.
Conduct post-testing is where the ATF tests configured back in Pre-upgrade's Automate upgrade tasks item run and report inline, with pass/fail status shown per suite, and no separate ATF module to check. When a test fails, the Console can hand it to the ATF Troubleshooting Agent, the same capability I covered in the March 31 Agentic ATF session, to work the failure autonomously: root cause and a remediation recommendation in minutes instead of the hours it usually takes to dig through logs by hand.
ATF Troubleshooting Agent prerequisites: this requires a Creator Pro Plus subscription, the Generative AI Controller plugin, Now Assist for Creator installed from the Store, and Zurich release or later. It's the same license and plugin stack I walked through in the Agentic ATF session; if you've already set that up for ATF generally, it carries over here without anything additional to provision.
Store application upgrades records the compatibility decisions made back in Pre-upgrade's Preview application upgrades item against the applications that were actually installed once the upgrade ran, so that record stays tied to the real outcome, not just the pre-upgrade prediction.
Underneath these checklist items sits a specific mechanic worth knowing. When someone resolves a skip record, whether through Auto Resolve or in the diff/merge viewer, the platform's Add To Update Set On Resolution Change business rule automatically captures that resolution into whichever update set is currently active. That's how a decision made in sub-production propagates consistently when the plan moves to production. It only works if an update set is active before the resolution happens, which is worth confirming with your team before anyone starts working through the list.
The last checklist item, Prepare next environment, is the mechanic the whole Repeatable Playbook idea depends on. It's where the completed upgrade plan, capturing compatibility decisions, skip record resolutions, and test outcomes, gets exported and staged as the starting point for the next cycle, rather than the next cycle starting from a blank plan.
Post-upgrade stage checklist showing ATF pass/fail results per suite
What gets exported: the plan exported at Prepare next environment, the last item in the Post-upgrade checklist, includes compatibility decisions, skip record resolutions, and ATF test outcomes: the exact input the Console expects when it's imported into Pre-upgrade at the start of the next cycle.
The Repeatable Playbook Cycle
|
📋
Pre-upgrade
|
→
|
🚀
Instance
upgrade |
→
|
✅
Post-upgrade
|
|
↓
|
|
💾
Plan
Exported |
|
↶ Imported as the starting plan for Pre-upgrade (next cycle) ↺ Compatibility decisions, skip record resolutions, and ATF results carry forward instead of starting from a blank plan |
One challenge belongs here too, because it's specifically about carrying decisions across environments rather than across cycles. An attendee described skip records resolved in a lower environment carrying sys_ids that don't match the corresponding skip records in production, which complicates a clean promotion from sub-production to production. I don't have a clean answer for this yet — more on this, and how you can help, in What's Next below.
Key Takeaways
- A financial services organization I shared during the session had historically taken the better part of a calendar quarter per upgrade cycle. After adopting Guided Upgrade Console, they nearly cut that timeline in half, largely because high-priority conflicts surfaced weeks before the upgrade window opened rather than during it.
- Predicted skip records combined with the coordinated workspace turn skip record resolution into an assigned, trackable pre-upgrade task rather than a decision made under time pressure mid-window.
- The plan exported at the end of one cycle's post-upgrade verification is the same plan imported at the start of the next cycle's pre-upgrade tasks: compatibility decisions, skip record resolutions, and test outcomes carry forward instead of being rebuilt each time. Because the readiness dashboard is centralized, that carried-forward context is visible to the whole team from day one of the next cycle.
What's Next
A look at what's still unresolved or in motion on this pillar. Directional, subject to change.
Known Error Portal integration. Right now, Guided Upgrade Console surfaces predicted skip records and compatibility signals based on your instance's customization profile, but it doesn't automatically pull in Known Errors published through the Known Error Portal. An attendee raised this directly during the session, and I flagged it live to the development team. It's now part of the roadmap conversation, but there's no committed timeline yet.
Cross-environment skip record promotion. Skip records resolved in a lower environment can carry sys_ids that don't match the corresponding skip records in production, which complicates a clean promotion from sub-production to production. This is a genuinely open pattern, and I don't have a clean answer for it yet. If your team has run into this, share the details in the comments below or reach out directly. It's likely affecting more teams than surfaced it during the session.
Getting Started
When I asked the room what they'd do next, more than four in ten said they'd activate Upgrade Console before their next upgrade window. Roughly a quarter said they'd run a dry assessment first. About three in ten said they'd evaluate it later in the year, and a small minority said it wasn't a priority right now. Wherever you land on that spectrum, here's a concrete sequence to work from:
- Confirm what your instance calls it: Yokohama labels it "Upgrade Management"; Xanadu and later call it "Upgrade Console," found under System Diagnostics.
- Confirm your release for the agentic layer specifically: application compatibility true-up and predicted skip records require version 3.x on the Australia release (EA since April 1, 2026; GA at Knowledge26). Xanadu and earlier still give you Upgrade Console, just not that layer yet.
- Don't assume you need a separate install if you're already on a qualifying release: the Console is native to the ServiceNow AI Platform and shows up under System Diagnostics automatically. It's also listed as a free scoped application in the ServiceNow Store, so if it's not there yet, check the Store next.
- Run a dry assessment before committing team time to a full guided upgrade cycle, starting in sub-production. This is what roughly a quarter of the session's attendees said they'd do first, and it's the safest place to validate how the Skipped Record Rules behave on your own customizations before touching production.
- Assign role-based owners before the next window opens: platform admin, developer, QA lead, business owner, and upgrade lead, so the dashboard has someone accountable behind every filtered view.
- Review existing skip record rules in the Skip Record Rules Editor (under Upgrade Center) before the cycle starts, including the out-of-the-box rules, which have shipped active by default since Xanadu and can auto-resolve records that actually contain base-system changes worth a manual look. Rules persist across cycles until deactivated or deleted.
- Confirm an active update set is selected before your team starts resolving skip records. The Add To Update Set On Resolution Change business rule needs one active to capture each decision, and that capture is what lets the resolution propagate cleanly to production.
- At the end of the cycle, export the completed upgrade plan and use it as the starting input for the next cycle's pre-upgrade tasks, rather than building a new plan from a blank slate.
Resources
Watch the Full Session
The complete Platform Academy session, including the live Australia demo and the full Q&A, is available on YouTube.
Questions or feedback? Drop them in the comments below. I read every one.
