Replace reporting without losing trust in the numbers.

Begin with the reporting job

A reporting migration is often described as moving dashboards from one tool to another. That description leaves out the decisions, definitions, source assumptions, and operating habits that make the dashboards useful.

Start by identifying the business job each report performs. Who uses it? When? Which decisions or investigations follow? What happens when the number is late or unclear?

The answers help separate the essential reporting scope from accumulated charts that no longer support an operating decision.

They also create a better acceptance test. “The team can review location collections on the agreed basis” is more meaningful than “the new page resembles the old page.”

Inventory the reports and their dependencies

Create a route or report inventory before implementation begins. Include the dashboards, scheduled packs, exports, filters, and drilldowns that people actually rely on.

For each item, record its audience, business questions, measures, source systems, current period conventions, delivery routine, and known limitations.

Also identify the owner of the business definition and the person who can help verify the source. One person may know the meeting; another may know why a particular field behaves unexpectedly.

Do not confuse the inventory with a promise to rebuild everything. Use it to agree on a bounded initial scope.

Classify each measure before copying it

An existing dashboard may contain source facts, derived calculations, manually maintained inputs, estimates, or values whose definitions are no longer clear.

Classify them explicitly. A measure can be:

• Defined and reproducible from an available source.
• Usable with a documented limitation or proxy.
• Dependent on an additional source or business decision.
• No longer required by the operating review.

This step prevents an old ambiguity from being recreated in a new interface.

If a value cannot be supported, keep that limitation visible in the migration plan. A familiar label does not justify inventing a replacement number.

Agree on the metric contracts

For each retained measure, establish the business definition, population, period, calculation, aggregation rule, source basis, and comparison.

Pay particular attention to fields whose names make them look interchangeable. A booking location and a servicing location may support different questions. A collection and a recognized-revenue measure may use different rules. A contact created this month may not belong to the month’s paid-media acquisition cohort.

Document how the measure behaves when the user filters it. Distinct counts and percentages need more care than additive amounts.

Have the relevant business owner approve the meaning before the visual design makes it feel settled.

Map the source path and historical coverage

Identify how each source reaches the reporting foundation. The path may involve a direct connection, an ingestion vendor, an existing warehouse, or a controlled extract.

For each path, record the access method, account scope, available history, source limits, date basis, and refresh process. Determine whether the source provides event history or only its current state.

Historical reconstruction should be a visible part of the scope. A source that never retained an event cannot always provide it later. A current campaign name does not automatically establish historical classification.

The migration plan should distinguish what can be reproduced now from what requires new data collection or additional work.

Reconcile one complete slice

Before scaling the implementation, choose a bounded reporting slice that can be checked thoroughly: a defined period, location scope, and measure family.

Reconcile it against agreed controls. Check not only the top-line total but the exclusions, detail rows, date boundaries, aggregation, and selected filters.

When a difference appears, classify it. It may be:

1. A source or coverage issue.
2. A calculation defect.
3. A period or population mismatch.
4. A deliberate definition correction.
5. A limitation in the earlier report.

The goal is an explained result. A difference is not automatically a failure, and a matching total is not automatically proof that every underlying rule is correct.

Keep a difference register

Record material differences between the old and new reports. Include the affected measure, observed difference, explanation, evidence, owner, and resolution.

If a corrected definition intentionally changes the result, the people using the report need to understand that before rollout. Otherwise a more accurate number may be rejected because it is unfamiliar.

The register also prevents repeated investigation. A known period cutoff or excluded population should not have to be rediscovered in every review meeting.

Keep it practical. Focus on differences that affect interpretation or acceptance, and link them to the relevant metric contract.

Run a focused parallel review

A parallel review gives the team a chance to use the replacement in a familiar routine while the old reporting remains available.

Choose the reports, periods, and stakeholders that exercise the important cases. Avoid leaving “parallel review” as an indefinite state with no acceptance criteria.

Ask users to complete the actual operating tasks: find a change, inspect the location detail, explain a definition, identify an unavailable measure, and understand a source delay.

Record whether the new view supports the decision and what remains unresolved. Distinguish a defect from a new requirement discovered during the review.

Roll out the reporting and its meaning

The handoff should cover the interface, the definitions, the source and period context, and the process for reporting a discrepancy.

Users need to know which filters apply to which measures. They need to recognize missing, partial, or withheld values. They should understand how the new view differs from a familiar older report.

A concise operating guide can be more useful than a tour of every button. Organize it around the questions the team will ask during the meeting.

Record the accepted scope and the decision to change the reporting routine. Keep a rollback or fallback plan appropriate to the implementation.

Give ongoing responsibilities a home

A reporting replacement is not finished when the first correct chart appears.

Sources change, location mappings evolve, and new measures are requested. The engagement needs an owner for publication, exceptions, definition changes, maintenance, and additional work.

Document the connection and account responsibilities, where the definitions live, how issues are raised, and what the customer retains if the engagement changes.

The data ownership checklist can help make that handoff specific.

A practical acceptance checklist

Before the new reporting becomes the operating reference, confirm:

• The initial report inventory is complete or explicitly revised.
• Every accepted metric has an understandable contract.
• Source coverage and historical limitations are documented.
• Important totals and filters have been reconciled.
• Material differences are explained and accepted.
• Missing or incomplete information has a clear interface state.
• Users can complete the intended operating tasks.
• Access and data-handling requirements have been tested for the scope.
• Ongoing owners and maintenance responsibilities are identified.
• The handoff includes definitions, operational guidance, and a fallback plan.

There is no universal migration duration hidden in this checklist. The schedule depends on source readiness, scope, historical coverage, and decision-making. A bounded first scope makes those dependencies easier to understand and manage.