Migration to Platform Analytics - any way to list potential dashboard/report that won't migrate

amitksi
Tera Contributor

10 hours ago

When a Dashboard is opened in Core UI, it denote with a '?' which suggest that this dashboard contains unsupported widgets and cannot be migrated to the Next Experience UI.

 

From a list of over 3k dashboards & report, if one doesn't want to go through each one of them, and need to know on first hand whether dashboard/report is eligible to migrate to the Next Experience UI.

 

Is there a possible way to list down (generate a report) potential dashboard/report that won't migrate or will migrate in compatibility mode?

 

0 Helpfuls
  • 213 Views
1 REPLY 1

Naveen20
ServiceNow Employee

an hour ago

There are a few approaches you can take to programmatically assess migration eligibility without opening each dashboard manually.

Understanding the Migration Categories

Dashboards/widgets typically fall into three buckets during migration: fully supported (clean migration), compatibility mode (rendered in an iframe wrapper — functional but not native), and unsupported (the '?' you're seeing — won't migrate at all).

Approach 1: Query the Underlying Tables

The core idea is to join dashboard records with their widget/renderer configurations and flag the ones using unsupported types. The relevant tables are pa_dashboards (PA dashboards), sys_portal_page (homepage-style dashboards), sys_portal and sys_portal_preferences (the widget instances and their renderer types).

You could write a Background Script or Scheduled Job that iterates through dashboards, inspects the renderer/widget type of each child widget, and compares against the known supported list from ServiceNow's docs. Something like:

var gr = new GlideRecord('sys_portal_page');
gr.query();
while (gr.next()) {
    var portalGR = new GlideRecord('sys_portal');
    portalGR.addQuery('page', gr.getUniqueValue());
    portalGR.query();
    while (portalGR.next()) {
        var prefGR = new GlideRecord('sys_portal_preferences');
        prefGR.addQuery('portal_section', portalGR.getUniqueValue());
        prefGR.addQuery('name', 'renderer');
        prefGR.query();
        while (prefGR.next()) {
            var renderer = prefGR.getValue('value');
            // Compare renderer against known unsupported list
            // Log/store results per dashboard
        }
    }
}

You'd maintain a reference array of unsupported renderer types (e.g., custom Jelly renderers, certain legacy report widgets) and flag any dashboard containing them.

Approach 2: Check for Built-in Migration Assessment

Depending on your release (Washington DC and later), ServiceNow has been adding migration tooling. Check whether the Dashboard Migration plugin or utility is active on your instance — it may already surface eligibility status as a field or related list. Look for properties like glide.dashboards.migration.* or check the "Next Experience Migration" module under System Diagnostics or Platform Analytics.

Approach 3: Report on Renderer Distribution

A quicker, lighter approach — just build a report on sys_portal_preferences filtered to name = renderer, grouped by value. This gives you a distribution of all renderer types in use across all dashboards. Cross-reference that list against ServiceNow's published supported widget types documentation, and you'll immediately know which renderer values are problematic. Then filter dashboards containing those renderers.

Practical Recommendation

I'd suggest starting with Approach 3 to get a quick picture of the renderer landscape, then use Approach 1 to generate a detailed CSV/report mapping each dashboard to its migration status (clean / compatibility / unsupported). You could output this to a custom table or just export via a Scheduled Job writing to an attachment.

0 Helpfuls