Pre‑Upgrade Analysis: Identifying Deprecated APIs and Feature Usage

KaitoF
Kilo Explorer

yesterday

 

I am preparing for a version upgrade and would like to understand the recommended ways to identify deprecated features or APIs within our instance. Currently, the instance is essentially a black box, and I do not have full visibility into its internal structure or implementations.

Specifically, I want to:

  • Detect deprecated Glide APIs

  • Identify scripts that use outdated functions

  • Determine whether certain features are being used within the instance

  • Understand best practices for pre‑upgrade impact analysis

Which tools or methods are recommended (e.g., Upgrade Center, Script Analyzer), and how should they be used effectively?

 

Thanks!
 
0 Helpfuls
  • 17 Views
1 REPLY 1

bonjarney
Kilo Contributor

an hour ago

There's no single button for this — it's a 4-tool approach. Here's the stack I'd use, in order:

1. Instance Scan (primary tool)
This is your main weapon. Instance Scan → Scan Suites has OOTB definitions that flag deprecated API usage, performance issues, and upgrade risks. Key suites to run:

  • Best Practice — catches deprecated GlideRecord patterns, client-side GlideRecord usage (deprecated since ~Jakarta), direct DOM manipulation, synchronous GlideAjax calls
  • Upgrade Readiness — flags features/APIs being removed or changed in your target version
  • Performance — finds scripts that will get worse under the new version's engine

You can also write custom scan definitions if you know specific APIs you're worried about. Each definition is just a Script Include that returns findings — so if you have a list of deprecated methods, you can scan for them programmatically.

2. Upgrade Center
System Diagnostics → Upgrade Center. This gives you:

  • Skipped records (your customizations that conflicted with the upgrade)
  • Preview results before you commit
  • Customer update list (every record you've modified from baseline)

The customer updates list is gold. It tells you exactly where your instance diverges from OOTB. Every one of those records is an upgrade risk.

3. Scripts - Background for targeted detection
For specific deprecated APIs, run a targeted scan:

var gr = new GlideRecord('sys_script');
gr.addQuery('script', 'CONTAINS', 'getXMLAnswer');  // deprecated synchronous GlideAjax
gr.query();
while (gr.next()) {
    gs.info('Found in: ' + gr.name + ' (' + gr.sys_id + ')');
}
 

Repeat for your target deprecated methods. Common ones:

  • getXMLAnswer → replace with getXMLWait or async getXML
  • Client-side GlideRecord → replace with GlideAjax
  • current.update() in Business Rules (causes recursion in newer versions)
  • g_form.getReference() without callback (synchronous, deprecated)
  • GlideAjax without getXMLAnswer callback pattern

Run this across sys_script, sys_script_include, sys_ui_script, sys_script_client, and sys_ui_action tables to get full coverage.

4. ServiceNow's Upgrade Checklist (external)
ServiceNow publishes version-specific upgrade guides at docs.servicenow.com under your target release. These list every deprecated API, removed feature, and behavioral change. Cross-reference your Instance Scan results against this list.

The process I'd follow:

  1. Run Instance Scan suites (automated, broad coverage)
  2. Pull customer updates list (shows your customization surface area)
  3. Run targeted scripts for known deprecated APIs against script tables
  4. Cross-reference findings against the version-specific upgrade guide
  5. Prioritize: deprecated APIs in active scripts > deprecated APIs in inactive/unused scripts

One thing people miss: check your Update Sets too. If you have old update sets with scripts that reference deprecated APIs, those will re-introduce the problem if someone promotes them post-upgrade.

0 Helpfuls