Proving parity.

The fastest way to lose trust in a new BI platform is for someone to spot a number that doesn’t match the old one. After that, every figure is doubted, and people keep the old dashboards open “just to check”. Parity testing exists to make sure that moment never happens.

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. Tableau LOD expressions rewritten in DAX are a classic case (see Tableau to Power BI migration), as are Domo Beast Modes (see FIXED functions in Beast Modes and Domo to Power BI migration). Qlik set expressions under a chart axis are another (see Qlik’s {1} ignores selections, not the axis).
• 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. The storage mode you pick changes how that security behaves, which is why it is worth settling before the build.

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. If you are comparing vendors, here is a checklist for testing a Domo migration before you commit.

And once the old platform is switched off, the signed-off numbers need a home too: the parity report should outlive the migration.