Looking right isn’t enough

A rebuilt dashboard can look identical and still be wrong. Common causes:

• A calculation evaluated in a different context — per row instead of per group, or across a join that fans out.
• A filter applied at a different stage.
• Nulls, rounding or time zones handled differently.
• Row-level security that’s slightly more or less permissive than before.

None of these show up in a visual check of one screen with one set of filters.

What a parity test does

For each migrated metric, a parity test asks the source and the target the same question, across the same slices, and compares the answers:

1. Choose the slices the dashboards actually use — by period, region, product and so on.
2. Query both platforms for the metric at each slice.
3. Compare the results within an agreed tolerance: exact for counts and currency, explicit for anything else.
4. Report every result, and block cutover for anything that fails.

Because the tests are automated, they can be run after every change, not just once before go-live.

Test the permissions too

Parity isn’t only about values. For each security role, check that a user in that role sees the same rows on both platforms. A migration that shows the right numbers to the wrong people isn’t a success.

Make it part of sign-off

Parity reports work best as the basis for business sign-off. Instead of “does this look right to you?”, owners are asked to approve a report showing every metric that was tested, at which slices, and with what result. That’s a much easier conversation — and a much more defensible one.

Parity testing is built into every full migration. Read more about risk and governance.

Start with evidence

Rationalisation goes wrong when it’s based on opinion. Everyone thinks their dashboards are essential. The answer is to put evidence in front of the people who decide:

• When was it last opened, and by how many people?
• Who owns it? Is that person still here?
• What depends on it? Does anything else read this dataset?
• Is there a near-identical version? Which one do people actually use?

A read-only scan of platform metadata and usage answers most of these questions without anyone opening a dashboard.

Four kinds of clutter

1. Dormant content — not opened in a long time.
2. Duplicates — copies that have drifted apart in small, unexplained ways.
3. Conflicting metrics — several definitions of the same business term, giving different answers.
4. Orphaned data — datasets and pipelines that no longer feed anything anyone looks at.

Retire, consolidate, migrate

Each candidate gets one of three outcomes:

• Retire — no longer needed. It stays in the open specifications, so nothing is truly lost and it can be brought back.
• Consolidate — merge duplicates and agree one definition for each metric.
• Migrate — used and needed, so it goes into the migration backlog.

Because retired items remain as specifications, owners are more willing to let things go. The decision can be reversed without an archaeology project.

Why it matters

A smaller estate is quicker to migrate, cheaper to run and easier to secure. It also gives people fewer conflicting answers — which is often the benefit they notice most.

Rationalisation is part of every estate assessment and full migration, and it’s worth doing even if you’re staying put. More on rationalisation.

It feels like progress. But look at what the organisation actually has at the end: the same analysis, now bound to a different vendor’s file format. The knowledge gained — what each calculation means, which dashboards matter, where every number comes from — lives in people’s heads and in the new platform’s proprietary objects.

The cost comes back

Platforms don’t last forever. Pricing changes, strategies shift, companies are acquired. When the next move comes, the estate has to be interpreted again from scratch — often by different people, with no guarantee they’ll reach the same answers.

That’s the real cost of a hand rebuild. It isn’t just the first migration. It’s that the expensive part — understanding the estate — has to be paid for again every time.

Split the migration in two

There’s a better way to structure the work. Split it into two halves:

1. Translate the estate into open specifications. Models become SQL, transformations become Airflow and Python, and dashboards become JSON and YAML definitions, with a field-level lineage graph behind them. This half is platform-neutral, and it’s where the understanding is captured.
2. Regenerate natively on the target BI platform. Our automated migration tool turns the specifications into native artifacts, with calculations rewritten in the target’s own language.

Only the second half is specific to a platform. The first is done once, and it doesn’t expire.

What changes

When the estate lives in open specifications in your own repository:

• Changing platform again means re-running our automated migration tool, not starting a complete migration project.
• Reviewing a change means reading a plain-text diff.
• Answering “where does this number come from?” means following the lineage graph, not reading old code.

The expensive half is done once, and it never expires.

If a migration is on your roadmap, start with a free estate scan and find out what’s actually in your estate.