Moving to ServiceNow Reporting and Dashboards: Migration Considerations

Moving reporting into ServiceNow is mostly a decision about each legacy output: rebuild it, feed it from an integration, keep its history somewhere the platform does not hold, or switch it off. This page covers what to inventory, the rebuild-versus-integrate assessment, data source mapping, a phased approach, common pitfalls, data quality validation, access control, training, governance after go-live, and the cutover sequence for the final weeks when the old output stops.

What to Inventory

Catalog existing reports: how many exist, what do they report on, who uses them, how often are they run? Interview stakeholders: which reports are critical, which are nice-to-have, which are out of date? Many organizations find a significant portion of reports are no longer used and can be deprecated without rebuilding.

Categorize: operational dashboards (daily use, real-time, monitoring), tactical reports (weekly/monthly, tracking trends), executive reports (monthly, high-level summary). Prioritize migration of high-use, business-critical reports.

Assessment: Rebuild vs Integrate

For each report, decide: rebuild as a ServiceNow report/dashboard (uses ServiceNow data directly), or integrate data from legacy system into ServiceNow then report? Rebuild if data is in ServiceNow or easy to sync. Integrate if source system is external and will stay external (e.g., financial data from accounting system).

Estimated effort: simple report (list with filters, total count) is smallest, medium report (grouping, calculations, multiple tables) is larger, complex report (forecasting, anomaly detection, custom visualization) is largest.

Data Source Mapping

Identify data sources for each report: which ServiceNow tables? Which external systems? If report pulls from multiple sources, how are they joined? Document this mapping so rebuilding report uses same logic.

Common challenge: legacy report uses different logic than current ServiceNow tables. Example: report counts “requests in progress” using a custom field; ServiceNow native logic uses state field. When rebuilding, align to ServiceNow standard data model, not legacy logic. This is opportunity to fix data inconsistencies.

Phased Migration Approach

Phase 1: Pilot. Rebuild 3-5 high-use operational reports as ServiceNow reports/dashboards. Validate accuracy (numbers match legacy report accurately). Run legacy and new in parallel for a short period. Business owner signs off. This validates approach before scaling to all reports.

Phase 2: Tactical Reports. Rebuild medium-priority reports. Less urgency than operational, so can take more time per report. Continue parallel run.

Phase 3: Executive and Historical. Rebuild remaining reports. Decommission legacy system once all reports are migrated and users are trained.

Common Pitfalls During Migration

Pitfall: Rebuilding with legacy logic. Legacy reports used inconsistent definitions (incident vs request, open vs active). Rebuilding exact replicas perpetuates inconsistency. Fix definitions upfront and use ServiceNow standard logic. Document changes; brief users on differences.

Pitfall: Performance problems post-migration. Legacy BI tool was optimized; ServiceNow report queries large tables and is slow. Before go-live, performance test with realistic data volume. If slow, optimize queries or add indexes in ServiceNow.

Pitfall: User confusion from different numbers. New report shows different count than legacy (due to definition fix or data quality improvement). Users distrust new report. Before migration, reconcile: why are numbers different, which is correct? Communicate difference proactively.

Data Quality Validation

Before declaring report migration done: verify numbers are correct. Run report on test data, verify calculations match legacy. Check edge cases: empty results, zero values, very large values. If numbers do not match, investigate and fix.

Common causes of mismatch: different field used (status vs state), different join (left join vs inner join), different time zone or date handling, null values handled differently.

User Training and Communication

New reports work differently than legacy: different interface, different access method (ServiceNow portal vs email), different timing (real-time vs nightly export). Train users on how to access new reports, how to use filters, how to export/share results.

Communicate changes: which reports migrated, where to find them, timing of data updates, what changed from legacy. Provide side-by-side comparison or links to legacy for transition period (agreed with the business owner). Have support staff available for questions.

Access Control Migration

Ensure users can only see reports and data appropriate to their role. If legacy system had access control, map to ServiceNow role-based security. Test: user in Sales sees sales data, not customer service data. User without executive role cannot see executive dashboard.

Timeline and Effort

Pilot (a few reports) first, then tactical reports, then executive and remaining reports. Timing and staffing depend on report count and complexity; set them after the pilot.

Post-Migration: Dashboard Governance

After migration, establish governance: who can create new reports, how are dashboards reviewed for accuracy, how are old/unused reports decommissioned? Without governance, reports proliferate and become inconsistent. Schedule quarterly dashboard review: are they accurate, are they being used, can any be deprecated?

The part of a reporting migration that gets forgotten: the day the old output stops

Rebuilding reports is the visible part of a migration. The quieter part is retiring the old outputs without breaking the people who depend on them. A legacy tool often has scheduled emails, bookmarked links, spreadsheets that pull from it on a timer and a manager who opens the same view every Monday. None of these appears in a report inventory, and each one fails silently when the old output is switched off. Plan the retirement as its own workstream, with its own list of consumers, rather than treating it as the last line of the rebuild plan.

Start by finding the consumers. Mail logs, scheduled task lists and access logs on the legacy system usually show who receives what, and the most useful source is often the person who has run the same export for years. Record each consumer against the output they use, the decision it supports and the date they need the replacement by. A consumer who cannot be found is a risk to record, not a reason to skip the step.

Deciding what happens to each legacy output

Not every legacy output deserves a rebuild, and not every one can be simply switched off. The choice for each item is one of four outcomes, and the reasoning should be written next to the decision.

The archive row deserves attention. Historical figures produced under an old definition are still valuable, but only if the definition travels with them. An archived number without its method is a number that someone will eventually compare with a new one and draw the wrong conclusion from.

Keeping history the platform does not hold

Some history never made it into the platform: snapshots taken monthly in a spreadsheet, figures from a retired tool, or totals produced by a finance system that the reporting platform only receives in summary. Decide early whether that history is needed for trend comparisons. If it is, load it as a clearly labelled data set with its own source note, and do not blend it silently with native records. A trend line that switches source halfway through will look like a performance change when it is really a change of definition.

A cutover sequence for the final weeks

1. Freeze new requests against the legacy estate, so the list of consumers stops growing while it is being checked.
2. Confirm each consumer and the decision it supports, and agree the replacement for each one.
3. Run the old and new outputs side by side for a period the decision owners accept, and record every difference with its cause.
4. Switch scheduled deliveries to the new outputs, keeping the old schedules paused rather than deleted until the first full cycle has passed.
5. Redirect bookmarks and send a short notice that names the replacement and its refresh timing.
6. Retire the legacy outputs in the order agreed with their owners, and keep the retirement record with the migration documentation.

Frequently asked questions about retiring legacy reporting

What if a manager refuses to give up the old report?

Find out which decision they make from it, then show whether the new output answers that decision. Often the disagreement is about one column or one filter, which can be added. If the disagreement is about the definition itself, that is a metric decision to settle with the business owner, not a reporting one.

Should we rebuild the old spreadsheets that people still maintain by hand?

Only if the spreadsheet feeds a decision that the platform should support. Manual spreadsheets often contain adjustments that nobody has written down. Capture those adjustments as requirements, or accept that they will leave with the spreadsheet.

How long should the old and new outputs run side by side?

Long enough to cover a full business cycle for the decision involved, including any month or quarter close. The exact period is for the decision owners to accept, and it should be written into the cutover plan before the parallel run starts.

Who signs off the retirement of a legacy output?

The decision owner who relied on it, with the migration lead recording the sign-off. An output retired without a named sign-off will be asked for again, often at the worst moment.

Next step

The migration page covers why organizations move to ServiceNow, and the migration reconciliation controls article covers how old and new figures can be reconciled before any switch-off. For the data loads themselves, the data migration and import sets guide covers the mechanics.