Skip to main content
When you move a pipeline to Fabric, for example from Azure Data Factory, the new pipeline should produce the same data the legacy pipeline produced. General Validation compares the two outputs as a Table Pair: the legacy output is the source, the new Fabric output is the target, and each Test reports whether they agree. Tests compare outcomes; they do not reproduce your transformation. Complete Getting started first so your Environment is set up, and hold the Contributor or Owner role.

​
Bring both outputs into Fabric

Both sides of a Table Pair must be Lakehouse or Warehouse Tables, in any mix, and the account that runs validation needs read access to both. Your new Fabric pipeline already writes to one. For the legacy output, use one of:
  • Add a shortcut in a Lakehouse to the storage where the legacy pipeline already writes its tables. General Validation reads the shortcut at its logical path inside your Lakehouse and never follows it to the physical destination; Fabric controls access and reports reads it does not support.
  • Load the legacy output into a Lakehouse Table once with your own Fabric pipeline, for example when the legacy output is a file rather than a Table.
  • Pair the Warehouse Table directly when the legacy pipeline already lands in a Fabric Warehouse.
Warehouse Tables are read through SQL with your own SQL permissions, so you need SELECT on the Table, and they cannot be pinned to a version.

​
Pair the legacy and new Tables

  1. Open Table Pairs, click Add Table Pair, and enter a Table Pair name that identifies the migrated table. Create one pair per table.
  2. Choose the legacy output with Source Workspace, Source Lakehouse or Warehouse, and Source Table, then the new Fabric output with the matching Target fields. Source and target stay fixed after creation.
  3. Under Join keys, map the columns that identify a row on each side. VALUE and OUTER_VALUE Tests require them. Choose keys that identify rows uniquely; duplicate keys multiply matches.
  4. Under Source filters and Target filters, limit both sides to the wave, partition, or date window you are validating now. Only rows matching every filter are compared, and the filters apply to every Test in the pair.
  5. Click Add Table Pair.

​
Add Tests in order

On the Table Pair page, click Add Test, choose the Test function, and select the Source column and Target column. Add Tests in this order so each Result narrows where a difference lives.
  1. COUNT_ROWS first. It needs no columns and confirms both sides hold the same number of rows for the filtered scope.
  2. SUM, MIN, MAX, and COUNT_DISTINCT on the measures that matter, one Test per column. Leave Absolute threshold at 0 for exact equality.
  3. SET_A_EQUALS_B on identifier columns such as customer or order IDs, to confirm both sides contain the same distinct values. Use SET_A_IN_B when the new pipeline is allowed to add identifiers the legacy output lacks.
  4. VALUE or OUTER_VALUE with the join keys, on the columns you must match row by row; OUTER_VALUE also fails when a row is missing from either side. Set Max bad records to the number of mismatched rows you accept, and keep Evidence limit above 0 so mismatched rows are saved.

​
Run and review

  1. Confirm both loads for the wave have finished, then click Run validation on the Table Pair page or choose it from the pair’s ⋯ menu on Table Pairs. The two Tables are read separately, not as one snapshot.
  2. When the Run finishes, review each Test’s Result, Compared, Mismatches, and Reason. Could not read the Tables or The Test could not finish is an access or column problem, not a data difference.
  3. For a failed Test, click View details to see the exact Source value and Target value or a sample of mismatched rows. For the complete evidence, Run status meanings, and retention, see Runs, Results, and evidence.

​
Repeat per wave and keep the pairs

For the next wave, open the pair, click Edit Table Pair, and change the filters; the change applies to future Runs, past Runs stay intact, and the pair shows Not run until the new scope has a Result. Results lists every Run newest first, and each Run link can be bookmarked, so record the Run ID for each wave in your cutover record. After cutover, keep the pairs and run them after each later load as regression controls; see Validate on an ongoing basis. Every active Table Pair counts toward your plan limit. Deleting a Table Pair archives it; its Runs and Results remain.