Migration validation

How to validate a Tableau or Power BI migration to Sigma

Validate a Sigma migration with matched data cutoffs, source-to-target comparisons, filter tests, access checks, and explicit business acceptance.

Linus Tse

Greyfield Data

Updated 5 min read
In this article 7 sections

Validate a Sigma migration by comparing the same records, calculations, selections, permissions, and delivery outputs against the source. The first job is to establish a fixed baseline. Otherwise, a source refresh between two screenshots can look like a migration defect.

This guide builds an acceptance record for one small sales workflow. It separates independently calculated expectations from results you still need to collect in Power BI or Tableau and Sigma.

Freeze the population before comparing totals

This guide uses the Greyfield sample orders CSV: eight synthetic orders across January and February 2026. Each row is one order. Revenue is in generic currency units, with no tax, returns, or currency conversion. Dataset notes and calculated expected results are included. The arithmetic was checked independently with SQLite; it is a test specification, not a claim that a migration has passed in all three products.

Use Order Date from January 1 through January 31, inclusive, with all regions selected. The expected baseline is five orders, 290 revenue, and four known customers. Record the source refresh time, target data freshness, date field, time zone, and exclusions.

For timestamp data, define boundaries precisely rather than relying on a date label. A half-open range from the start of January to the start of February avoids dropping records later on January 31. Our CSV uses dates, so time-of-day conversion is not part of this fixture.

Export the qualifying Order IDs from both systems. If the populations differ, resolve that before tuning an aggregate formula. A matching total can conceal different rows.

Compare at more than one level

Check the overall number first, then month, region, product, and individual orders. January East should be 190, January West 100. Across both regions, January product A should be 170 and B should be 120.

Use the difference to narrow the investigation. If every value is exactly tripled after a join, inspect grain. If January is lower by 90 and February higher by 90, inspect O104 and the date role. It was ordered January 31 and shipped February 2.

These are diagnostic clues, not automatic diagnoses. Confirm the actual records and relationships before changing the model.

Power BI Model view with relationship cardinality and filter direction visible
Inspect the relationship line and its endpoint columns before rebuilding the model. Source: Microsoft Learn. Documentation screenshot; vendor sample data, not the Greyfield example. Select the image to view it at full size.

Power BI's Model view exposes relationships that can affect the source calculation. Capture the relevant relationship settings alongside the measure definition. A formula copied without its model context is an incomplete specification.

Give each test a reproducible record

Download the starter acceptance cases. Source and Sigma result fields are intentionally blank, and every case starts Pending.

Use one row per test with these fields: case ID, user role, source version, target version, data cutoff, starting state, action, expected result, source result, target result, evidence location, owner, and status.

For example, VAL-03 starts in January with all regions. Select East. The expected detail is O100, O101, and O104, totaling 190. Clear the selection and expect five orders totaling 290, with January still selected.

Leave the target result empty until someone runs it. “Expected 190” is not “Sigma returned 190.” Use Pending, Pass, Fail, or Approved difference. Record who approved a difference and why, rather than turning a mismatch into a pass.

Test interaction state as well as calculations

Run the workflow from a fresh visit, not only from the builder's current session. Check the landing month, region selection, navigation to detail, back navigation, and reset.

Sigma control Properties panel with a target table and target column
Check both the target element and the column. A visible control alone does not establish which data it filters. Source: Sigma documentation. Documentation screenshot; vendor sample data, not the Greyfield example. Select the image to view it at full size.

For a Sigma control, inspect its target element and column. In the sample design, month should affect Regional Sales, Product Mix, and Order Detail; region selection should narrow the intended detail views. A control can appear on the page without producing that exact scope.

Also test a selection with no matching records. The page should communicate the agreed no-data state instead of leaving a stale-looking number that users could mistake for the selected population.

Validate permissions with distinct audiences

Define the access rule before testing it. Our proposed acceptance case gives an East reviewer only East records and a West reviewer only West records. This is a requirement to configure and verify, not a security rule implemented by the CSV.

Test each restricted identity in the published target. Inspect the detail rows, totals, navigation destinations, and available exports. Check whether changing a visible region control can expose another region.

A filter is an interaction control; don't treat it as proof of access enforcement. An administrator seeing the correct total also does not prove a restricted user sees the correct subset. Keep access evidence separate from calculation evidence.

Open the actual exported file

For January East, inspect an export containing O100, O101, and O104. Confirm five required fields: Order ID, Order Date, Region, Product, and Revenue. Check types and formatting if a downstream spreadsheet depends on them.

Sigma documentation Excel export showing repeated pivot row and column labels
Inspect the exported file itself, including labels needed by downstream users. Source: Sigma documentation. Documentation screenshot; vendor sample data, not the Greyfield example. Select the image to view it at full size.

The vendor example shows why output structure matters. Repeated labels can make a pivot export usable as data, while a visually tidy grouped layout may leave cells blank. Agree whether the recipient needs a printable report or a reusable data file.

For scheduled delivery, verify the saved control values, time zone, destination, and received attachment in an authorized test. A successful manual download does not verify a scheduled email.

Define the release decision before results arrive

Metrics, restricted access, and delivery feed the release decision. Any critical failure means hold, repair, and retest.
Metrics, restricted access, and delivery feed the release decision. Any critical failure means hold, repair, and retest. Greyfield teaching diagram; proposed workflow, not a screenshot or completed test.

Treat an unexplained material metric difference, an access leak, or a missing critical delivery as a release blocker. A label or spacing issue can be lower priority if it does not change interpretation and the owner accepts it.

Avoid one universal numeric tolerance. Integer order counts should match exactly in this fixture. Currency rounding, floating-point calculations, and approximate methods may require different rules in a real model. Document those rules per measure.

Sigma's migration tools are currently described as beta. Its guidance calls for human review beyond automated comparisons, including filters, layout, and restricted-user access. Sigma migration guidance

The useful handover is the completed acceptance record and unresolved exceptions, not a screenshot of two equal totals. Use the cutover checklist to turn that evidence into a release decision.

Related

← All articles