Moving to ServiceNow Performance Analytics for ITSM: Migration Considerations

Moving reporting to Performance Analytics for ITSM means replacing spreadsheets and separate BI queries with indicators that read directly from the platform's ITSM tables. This page sets out the steps for that move, from inventorying current reports to validating history and retiring the old file.

Why Migrate to Performance Analytics for ITSM

Many organizations run ITSM on the Now Platform but manage reporting and dashboards in separate tools: Excel spreadsheets, BI platforms like Tableau, or ad-hoc queries. This duplication creates inconsistency: spreadsheet data versus platform data disagree, updates are manual and error-prone, and leadership sees different numbers depending on who ran the report. Performance Analytics brings reporting into the platform so data is single-source-of-truth and updates automatically.

The steps below run from inventorying the reports leadership relies on today, through defining metrics and mapping data sources, to designing dashboards, validating against history, planning cutover and training, and refining after go-live, with the pitfalls that recur at each stage, how to run a parallel period, and what to do with the spreadsheet afterwards.

Step 1: Inventory Your Current Reports

Begin by listing every report and dashboard leadership is currently relying on. Not just the official reports, but the Excel files that analysts build, the queries that supervisors run, the spreadsheets that show SLA performance. Document: what metric does each report show, who creates it, who uses it, how often is it refreshed, and how critical is it to leadership decisions.

Categorize them: Which reports must work on day one of your migration? Which can come later? Which reports are actually duplicate (three different sources showing the same thing)? Which reports measure the same thing but define it differently? This inventory is valuable even beyond Performance Analytics; it often reveals that teams are working with inconsistent data.

Step 2: Define Metrics and Calculations

ServiceNow Performance Analytics comes with pre-built indicators for common ITSM metrics: average time to resolve, SLA compliance, ticket aging, assignment distribution. These are good starting points, but you will need to customize them for your organization. Ask: How do we define resolution time? Does it include time on hold or only time worked? When is a ticket considered “resolved”—when it is marked resolved status, or when the user confirms the fix worked?

These definitions matter because they affect reported numbers. If your old spreadsheet counted resolution time differently than Performance Analytics calculates it, the numbers will not match and teams will distrust the new system. Document all definitions before migration so you can explain differences.

Step 3: Map Data Sources

Performance Analytics reads from the Now Platform database. It can pull from Incident, Request, Problem, or Change tables, and it can reference related records. Make sure all the data you need is captured in ServiceNow. If SLA performance is calculated based on a custom field that is not in ServiceNow, you need to either populate that field or adjust your definition.

Ask: What data is missing or incomplete? If incident assignments are recorded sporadically or customer business impact is often blank, reports based on that data will be unreliable. Before migrating reporting, invest in data quality. Garbage in produces garbage out, regardless of the reporting tool.

Step 4: Design Dashboards and Reports

Performance Analytics dashboards show trends, comparisons, and current status. Start with leadership needs: What does a director need to see weekly? What does a supervisor need to see daily? Build dashboards around those needs, not around available data. A dashboard showing every possible metric is overwhelming; a focused dashboard showing three key metrics for decision-making is useful.

Use visualization types appropriate to your data: time-series charts for trends (is SLA compliance improving or declining?), comparisons for performance versus targets, heat maps for patterns across teams or time periods. Test each dashboard with the intended users before going live; refine based on feedback.

Step 5: Validate Against Historical Data

Before cutting over, run Performance Analytics reports for a historical period and compare the numbers to your previous reports. Do they match? If not, investigate why. Is it a data quality issue, a definition difference, or an error in Performance Analytics calculation? Reconcile all major differences before migration; do not ask leadership to accept numbers that are different from what they have been managing to.

Step 6: Plan Cutover and Training

Decide when to cut over from old reporting to Performance Analytics. Options: run both in parallel for a month so people gain confidence, or cut over on a specific date and monitor closely. Train users on the new dashboards: where to find them, how to interpret them, what changed from the old reports.

Identify super-users who can troubleshoot and customize dashboards after launch. Not everyone needs to be an expert, but you need a few people who understand Performance Analytics well enough to adjust calculations or investigate data discrepancies.

Step 7: Monitor and Refine

After cutover, monitor adoption. Are users using the new dashboards, or are they still pulling old reports? Are there calculations that seem wrong? Are there new metrics people want that are not yet available? Schedule a 30-day review to address gaps and refine dashboards based on real usage patterns.

Common Pitfalls to Avoid

Do not migrate reporting before your ITSM data is clean; you will just automate bad data. Do not assume that performance analytics numbers will exactly match old reports; differences are often valid, but they need to be explained. Do not build dashboards without talking to the people who will use them; a beautiful dashboard that does not answer the questions people actually ask is wasted effort. Do not forget that dashboards need maintenance; thresholds that were relevant last year may not be relevant this year as your environment changes.

Decide the history question before the first dashboard is built

The first practical question in a move from spreadsheets to platform reporting is what happens to the history. Indicators switched on today collect new data from today onward unless backfilled. Anything before that date either has to be backfilled from the source records, if the data still exists in the required form, or it stays in the old file and is labeled as such. Some migrations go wrong because teams expect a year of trend lines on cutover day, and the first leadership review shows a chart that starts yesterday.

Run a parallel period with rules for each difference

A parallel run only helps if each difference has a rule before the run starts. Otherwise the team investigates every mismatch, runs out of patience, and accepts whichever number looks better. The sequence below keeps the run disciplined.

1. Freeze the old report’s logic as it stands, including any manual adjustments, and record each adjustment in writing with the reason it was made.
2. Run the new indicator over the same period and list every record that appears in one result but not the other.
3. Classify each difference as a data cause, a definition cause or a calculation cause, and assign the investigation to a named person.
4. Agree in advance which kinds of difference are acceptable and which must be fixed before cutover. A difference caused by a deliberate definition change is acceptable if the change was approved and is documented.
5. Repeat the comparison for a second period after the first corrections, so that a fix has been tested on data it did not drive.

What to do with the spreadsheet after cutover

Retiring the old file is an operational task, and it is often skipped. Analysts keep working in the spreadsheet because it is familiar, and the two versions can drift apart within weeks. Give the file a defined end. Mark it as read-only with a date, move it out of the shared folder that managers use, and remove any scheduled refresh that feeds it. If someone needs a figure the platform does not yet produce, the request goes into the indicator backlog, not into a new spreadsheet. Keep a copy of the old file for the audit trail, with a note explaining that it has been superseded and where its logic now lives.

Questions that come up near cutover

Can the platform replace a report that uses data from outside ServiceNow?

Only for the part of the calculation that the platform holds. If a figure depends on a field maintained in another system, either import that field into the platform with a documented process or keep the report as a derived view. Do not let the platform show a number that quietly omits the external part.

Should we migrate everything at once?

Usually not. Start with the reports that leadership reads most often and that have the cleanest data. Moving the most contested report first tends to stall the whole program, because the argument about its definition consumes the time that the easier reports needed.

What if the old numbers were wrong?

Say so, show the corrected figure and explain the difference. A migration is a good moment to correct long-standing errors, but only if the correction is communicated. Quietly changing a historical series can make the new platform look like the source of the problem.

How do we know cutover is complete?

When the old report is no longer used in any meeting, no one has requested it for a full cycle, and the owner of each metric can explain its definition without referring to the spreadsheet. Until then the migration is still in progress, whatever the project plan says.

Where the migration fits in the wider reporting plan

Migration is the point where definitions are most likely to be argued, so the guide to common Performance Analytics mistakes is worth reading before the parallel run starts. The people who will read the new dashboards need preparation of their own, covered in the adoption and training plan. For a wider view of how reporting can be simplified before any tool changes, the note on common ServiceNow reporting challenges is a useful starting point.

ITSM analytics in ServiceNow: choosing between standard reports and Performance Analytics

ITSM analytics in ServiceNow means measuring incident, request, problem and change work from the same tables that run them. Standard reports show the current state of records. Performance Analytics adds scheduled data collection, so scores are stored over time and trends, targets and breakdowns can be read without exporting anything.

That difference settles most choices. A report answers how many incidents are open now. An indicator answers how the open count has moved against its target over a quarter, and which assignment group drove the change. If leadership questions are about trend and accountability, you want indicators. If they are about today’s queue, reports and dashboards are enough, and they typically do not need the separate licence that Performance Analytics usually requires.

When an outside analytics tool is involved, judge the connection on three points before building it:

• Whether it reads collected scores or only raw table rows, since raw rows cannot reproduce a stored trend.
• Who owns the metric definition, since two tools publishing one metric from different data cuts will disagree.
• How refresh timing and record permissions carry across.

The integration patterns guide covers these in more detail, and a Performance Analytics implementation starts by settling the definitions. Reports that need no history sit under reporting and dashboards.

How do I evaluate a third-party tool against Performance Analytics?

Compare them on the same three questions: where trend history is stored, who owns each metric definition, and how permissions are applied. Run both on one metric for a full period and reconcile every difference before choosing which becomes the source of record.

What data does Performance Analytics need before it is useful?

Consistent, populated fields on the ITSM records it measures. Indicators built on blank impact fields or sporadic assignments give unreliable scores, so fix capture at the form first and build indicators once the fields are reliably filled.

Who should own an ITSM metric definition?

One named owner per metric, usually the process owner for the work being measured, with the definition written down. That owner approves any change to how the figure is counted, so history stays comparable.

Deciding Which Spreadsheet Reports Should Move Into Performance Analytics

Move a report into Performance Analytics when many people read it, its definition has stopped changing, and every field it uses already lives in ServiceNow. Keep it outside when it depends on external data sources, when only one person uses it, or when the logic changes every month because the question keeps changing. Many reports fall clearly into one group once you ask those three questions.

The useful test is not whether the spreadsheet is important. It is whether a platform dashboard would give the same answer to the same question without someone rebuilding the numbers by hand. A report that needs a person to exclude a batch of records each month is usually a sign that the exclusion rule has not been written down yet, and that work belongs before any indicator is built.

Ask the report owner what decision the report feeds. If the answer is a monthly review of service levels, the report is a candidate to move, because the indicator can run without anyone opening the file. If the answer is a question that changes with each new initiative, a dashboard will go stale quickly, and a documented query is often the better choice.

Teams that want help drawing this line can look at our Performance Analytics implementation service page. Keep the list short, since each report you move adds a definition to maintain and a dashboard to review.