> ## Documentation Index
> Fetch the complete documentation index at: https://docs.generalvalidation.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Validate a migration to Fabric

> Compare the Tables your legacy pipeline produced with the Tables your new Fabric pipeline produces, one Table Pair per table, before and after cutover.

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](https://docs.generalvalidation.com/get-started/quickstart.md) 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](https://docs.generalvalidation.com/validate-data/runs-and-evidence.md).

## 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](https://docs.generalvalidation.com/validate-data/ongoing-validation.md).
Every active Table Pair counts toward your plan limit. Deleting a Table Pair
archives it; its Runs and Results remain.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.