Data migration without breaking reporting.

Migration

A data migration succeeds when the business can keep making decisions without losing trust in the numbers. The technical work matters, but the real risk is moving reporting before you have proved that the new system explains the same business reality as the old one.

Define migration success as reporting trust, not tool replacement

A reporting migration is not complete when data lands in a new warehouse, dashboard tool, or model layer. It is complete when the people who rely on the reports can use the new system with confidence.

That confidence comes from evidence. The new system should show that key reports match the old system where they are supposed to match, that known differences are explained, and that owners know what to do if something breaks after cutover.

Start by writing a short success definition. For example: executive revenue reporting, weekly operating dashboards, and finance extracts must be available in the new system, reconciled against the old system for the last three closed periods, and signed off by named business owners before cutover.

Inventory the reporting surface before moving data

Do not start with tables alone. Start with the reporting surface the business actually uses: dashboards, recurring spreadsheets, scheduled emails, extracts, board metrics, finance reports, customer lists, and ad hoc scripts that quietly support decisions.

For each artifact, capture the owner, audience, refresh cadence, source system, business purpose, critical filters, downstream dependencies, and whether the report is required for cutover. This keeps the migration focused on operational risk instead of vague system completeness.

The inventory will also expose reports that should not be migrated as-is. Some spreadsheets contain manual cleanup that should become modeled logic. Some dashboards are unused. Some extracts feed external processes and need stricter file-shape compatibility than a normal dashboard.

Artifact	Migration question	Common risk
Dashboard	Which metrics, filters, date ranges, and audiences must match before cutover?	Users notice missing filters or changed totals after the old dashboard is retired.
Spreadsheet	Which manual transformations should become modeled logic?	Hidden cleanup steps are lost and the new report appears wrong.
Extract	Which downstream process depends on the file shape, timing, or naming?	A technically correct dataset breaks an operational workflow.
Scheduled email	Who reads it, what decision does it support, and is it still needed?	Recurring reports are migrated without confirming usage.
Executive metric	What is the approved definition and comparison period?	Leadership sees a changed number without an explanation.

Classify reports by cutover risk

Not every report deserves the same migration effort. A weekly executive metric, a finance reconciliation file, and a forgotten exploratory dashboard should not receive equal attention.

Use a simple risk classification. High-risk reporting affects revenue recognition, cash, customer commitments, executive decisions, regulatory work, or operational workflows. Medium-risk reporting informs team management or recurring planning. Low-risk reporting is exploratory, duplicated, unused, or easy to regenerate.

This classification helps you decide where to spend parity effort. High-risk reports need explicit reconciliation and business signoff. Medium-risk reports may need sampled checks and owner review. Low-risk reports may be retired, rebuilt later, or moved only if there is clear usage.

Risk level	Examples	Migration requirement
High	Revenue dashboards, finance extracts, board metrics, customer commitments	Document definitions, reconcile against legacy output, obtain owner signoff, and prepare rollback criteria.
Medium	Team performance dashboards, recurring planning reports, operational summaries	Sample parity checks, owner review, and clear issue path after cutover.
Low	Unused dashboards, duplicated reports, exploratory analysis	Retire, defer, or rebuild only when there is confirmed demand.

Map metric definitions before comparing numbers

Parity checks fail when teams compare numbers before agreeing on definitions. A legacy report may include refunds differently, filter out test accounts, use a local timezone, or rely on a manual spreadsheet override. The new system may be more correct, but unexplained differences will still damage trust.

Before running comparisons, document the core definitions behind each critical metric. Include grain, filters, business rules, timezone, currency handling, deleted records, late-arriving data, and any known manual adjustments.

If the old report is wrong, do not hide that fact. Label the difference clearly: intentional correction, legacy defect, timing difference, source limitation, or unresolved discrepancy. A migration is a good time to fix bad logic, but the business needs to understand what changed and why.

Run old and new reporting side by side

Side-by-side operation is the safest way to transfer trust. For a defined period, run the legacy report and the new report on the same business periods and compare the outputs.

Compare more than row counts. Check totals, subtotals, segment-level values, date boundaries, null handling, record inclusion, duplicate behavior, and known edge cases. For dashboards, test the filters that users actually use, not just the default view.

Set tolerance rules before reviewing results. Some reports require exact agreement. Others may allow small timing differences because source systems update asynchronously. The important point is to decide what level of variance is acceptable before the numbers are politically sensitive.

Every material discrepancy should have an owner, explanation, resolution path, and status. Do not let unresolved differences accumulate in chat threads. A simple reconciliation log is often enough.

Check type	What to compare	Why it matters
Row counts	Records by date, source, status, or segment	Catches missing loads, duplicate records, and filter mismatches.
Metric totals	Revenue, users, orders, pipeline, costs, or other key measures	Shows whether the business-facing number agrees.
Breakdowns	Region, product, channel, owner, plan, or customer segment	Finds errors hidden by matching top-line totals.
Date boundaries	Month-end, timezone cutoff, fiscal periods, late-arriving records	Prevents close-period and trend-reporting surprises.
Known edge cases	Refunds, cancellations, deleted records, test accounts, merged customers	Validates the messy cases users already know about.

Protect historical reporting with planned backfills

Many migrations work for today’s data but fail when someone asks for the same report over the last two years. Historical reporting needs explicit planning.

Decide how much history each reporting area needs, how historical source changes will be handled, and whether old business logic should be preserved for prior periods. Backfills should be repeatable, documented, and validated against known closed periods.

Be careful with slowly changing business concepts. Account ownership, customer segments, product names, territories, and lifecycle stages may have changed over time. If the new model applies today’s labels to historical events, trend reporting may look different from the legacy system. That may be correct or incorrect depending on the business question, but it should be intentional.

Use a controlled parallel run, not an indefinite shadow system

A parallel run gives users time to compare reports before cutover. It should have a defined scope, start date, end date, success criteria, and review cadence.

Avoid running two official reporting systems indefinitely. Long shadow periods create confusion, duplicate maintenance, and arguments about which number is right. The goal is to gather enough evidence to make a cutover decision, not to maintain permanent optionality.

During the parallel run, ask report owners to review the outputs they know best. Analytics and engineering teams can catch technical issues, but business owners are more likely to notice missing filters, strange segment behavior, or operational definitions that never made it into documentation.

Cut over with owners, communication, and rollback criteria

A clean cutover has named owners, a date, a communication plan, and a short rollback path if a critical report is wrong. The plan should say which reports become official, which legacy reports are frozen, who approves the move, and where users should raise issues.

Rollback should not be vague. Define the conditions that would trigger it, such as a critical executive metric being materially wrong, a required finance extract failing, or a major workflow losing data. Also define who can make the rollback decision.

Communicate expected differences before users discover them. If the new system fixes a legacy defect, changes a metric definition, or removes unused filters, say so plainly. Trust improves when differences are explained before they surprise people.

Monitor the new reporting system after cutover

The migration is not finished the morning after cutover. Watch the new reporting system through at least one normal business cycle, such as month-end close, weekly executive review, or campaign reporting.

Monitor pipeline freshness, failed jobs, dashboard load issues, unexpected nulls, row-count anomalies, and user-reported discrepancies. Keep the reconciliation log open long enough to capture post-cutover issues, then close it intentionally when the system is stable.

Retire or restrict the legacy reports once confidence is established. If old dashboards remain available without clear labels, users may keep comparing numbers forever and reopen issues that were already resolved.

Key takeaways

• A data migration should be planned around reporting dependencies, not only around source tables or tools.
• Inventory dashboards, spreadsheets, extracts, and executive metrics before deciding migration scope.
• Parity checks should include definitions, totals, segment breakdowns, date boundaries, and known edge cases.
• Historical backfills need explicit rules for how much history to load and how changing business concepts are represented.
• Cutover should have named owners, user communication, approval criteria, and a rollback path.

Next step

Create a migration inventory with one row per report or extract. Include owner, audience, business purpose, source, refresh cadence, risk level, required history, parity requirement, signoff owner, and cutover status.