Moving to ServiceNow Operational Metrics: Migration Considerations

Operational Metrics in ServiceNow: Purpose and Scope

Moving operational metrics into ServiceNow is mostly a migration of definitions, not of numbers. Every measure that lives today in a spreadsheet or a reporting tool carries an implicit calculation, a data source and a history that someone reads for trends, and each of those has to survive the move or be consciously retired. This page covers the inventory and selection of measures, validating the data they will draw on in the platform, setting baselines and targets, rebuilding dashboards, and keeping the history readable when a calculation changes.

Before migrating metrics to ServiceNow, assess what metrics you currently track and where. Are metrics in spreadsheets maintained manually? Extracted from ticketing tools but manually summarised? Calculated ad-hoc for reports? Consolidating metrics in ServiceNow centralises them, makes them auditable, and enables automated dashboards.

Metrics Inventory and Selection

Identify all metrics your organisation currently calculates or wants to calculate. Typical metrics: mean time to respond, mean time to resolve, first-contact resolution rate, customer satisfaction, cost per incident, change success rate, availability by service. For each metric, document: what is measured (the numerator and denominator), how it is calculated, what data sources it depends on, what the current value is, and what the target is.

Prioritise metrics: focus first on metrics that drive decisions. If leadership makes decisions based on incident resolution time, prioritise this metric. If a metric is interesting but no one acts on it, deprioritise it. Start with 5-10 core metrics; add more after you have established reliable data collection.

Data Collection and Source Validation

Each metric depends on data from ServiceNow tables. Mean time to resolve depends on incident create time and resolution time from the incident table. First-contact resolution depends on whether the incident was resolved by the help desk or escalated. Availability depends on monitoring data (events, outages). Before migrating a metric, confirm that the data source is reliable.

For each data source, establish data quality standards: are required fields consistently filled, are field values normalised (not “prod” and “Production” mixed), is data accurate? If data quality is poor, the metric will be misleading. Address data quality issues before deploying metrics.

Baseline and Target Setting

Before implementing metrics, establish baselines: what are the current values of each metric? Baseline data becomes your starting point. After improvements, you measure progress against the baseline. Setting targets is art and science: targets should be ambitious (driving improvement) but achievable (teams do not become demoralised).

Avoid setting targets without understanding drivers. If mean time to resolve is currently 20 hours and you target 8 hours without adding staff or tools, the target is probably unachievable. Work with teams to understand what drives each metric and what improvements are realistic.

Metric Definition and Calculation Logic

In ServiceNow, define metrics using Performance Analytics or custom dashboards. For each metric, specify: the calculation logic (formula), the data source (which table and fields), the reporting period (daily, weekly, monthly), and the display format (a number, a trend, a heat map).

Document the metric definition in plain language so others understand how it is calculated. For example: “Mean Time to Resolve is the average time from incident creation to resolution, calculated over the past 30 days, excluding incidents marked as duplicate or cancelled.” This clarity prevents misinterpretation.

Dashboard and Reporting Setup

Create dashboards that display metrics to the right audiences. An operations team dashboard shows incident and change metrics. A service owner dashboard shows service-specific metrics. An executive dashboard shows high-level trends. Use ServiceNow’s dashboard tools to create visualisations (charts, KPI tiles) that make metrics clear and actionable.

Set up automated reporting: metrics are calculated daily or weekly and reported to relevant teams. Rather than requiring teams to pull reports, push metrics to them regularly. This creates awareness and reinforces the importance of metrics.

Governance and Metric Evolution

Metrics should evolve as your organisation learns. If a metric is consistently missed despite improvement efforts, investigate: is the target unrealistic, or is there a fundamental barrier to improvement? Adjust targets based on experience. If a metric becomes less relevant (for example, if you retire a legacy system), retire the metric.

Establish an annual metrics review: assess which metrics are driving improvement, which are being ignored, whether new metrics should be added. Metrics that no one uses should be retired to reduce noise.

Common Pitfalls in Metric Migration

One error: migrating a metric calculation without checking data quality. If the source data has errors, the metric is unreliable. Another: setting targets without understanding what drives the metric. A third: creating too many metrics so everyone is overwhelmed with data. Focus on key metrics that drive decisions; add more after you have proven the value of measurement.

Keeping the history readable when the calculation changes

Moving operational measures into a new platform raises a question that the technical plan often leaves open: what happens to the history? Trend lines are the reason leaders trust a metric, and a move that resets them makes every comparison suspect for a year. Yet the old history was often calculated under rules that no longer hold. A spreadsheet might have excluded a category of work that the new definition includes, or averaged over a calendar that has since changed. Migration therefore has two jobs that pull in different directions: preserve the history people rely on, and be honest about where the old and new calculations differ.

The working answer is to restate history under the new definition wherever the source data allows it, and to label the gap clearly wherever it does not. A restated series that carries a note about the rule change is far more useful than a smooth line that hides a break.

Mapping old calculations to the new definitions

The table is a template for the inventory every migration needs. The last column is where the decision is recorded, because each legacy figure needs an explicit outcome rather than an assumption that it carried across.

A cutover sequence that protects the trend line

1. Inventory every figure that leadership currently sees, including the ones that appear in appendices, and note the owner of each.
2. For each figure, decide whether it will be restated, run in parallel, or started as a new series, using the table above as the frame.
3. Run the new calculation over the old source period and compare the results with the legacy figures, recording every difference with its cause.
4. Run the old and new reports in parallel across a complete reporting period, and circulate both with an explanatory note.
5. Ask each owner to sign that the new series is acceptable for the decisions they make, before the legacy report is retired.
6. Archive the legacy report and its calculation notes, so that a later question about a figure can be answered from the record.

Why parallel running is worth the cost

A parallel period is the cheapest insurance against a surprise. It shows the differences while they are still small and gives owners time to adjust their expectations before a board sees a changed number.

When restating is not honest

If the source data for the old period is incomplete or was overwritten, a restated series would invent precision. In that case, start a new series and keep the legacy figure visible as history.

Handling a figure nobody owns

Do not migrate it silently. An unowned figure is either dropped by decision or assigned an owner before cutover. Carrying it over without an owner repeats the problem on the new platform.

What owners should expect to see

They should see the old and new values for the same period, the reason for each gap, and the date from which the new series is the official one.

Placing the migration inside the wider program

The cutover sequence is one phase of the wider plan, and the implementation roadmap for operational metrics sets out the rollout sequence. Reconciliation between the old and new sources is covered by the data migration, reconciliation and cutover service, and the common mistakes guide lists pipeline errors that can surface during a parallel run. Naming each definition before the move is covered in the service metric dictionary note.

Bring the legacy figure list and the owner of each figure.

Questions about migrating operational metrics

Should the old spreadsheet be kept after cutover?

Keep it read-only until the owners agree, then archive it. A live spreadsheet that people still edit is the most common reason two versions of the same figure circulate after the move.

How do we explain a break in the trend line?

State the date of the rule change, what changed and the effect on the figure, in a note placed on the chart itself. A break explained once is far less damaging than a break found by a reader.

Can history be imported in bulk?

Historical records can often be loaded, but a load does not confirm that the calculation is right. Test the imported history against the legacy figures before relying on it.