> ## 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.

# Validating your ADF to Fabric migration

> Reconcile old and new pipeline outputs, review discrepancies, and retain the customer-owned evidence needed for a migration decision.

General Validation reconciles the output of your existing pipeline with the
output of your migrated pipeline. You define and review the checks in the
hosted application; validation executes in your Azure environment.

## Before you start

* Complete [Getting started](/getting-started) with a ready customer
  **Environment** and an Owner or Contributor account.
* Have the old and new outputs available in
  [supported formats](/supported-scope).
* Connect the relevant ADF factory and Fabric workspace in **Discovery**, then
  import and prepare the exact datasets or tables you will compare.
* Confirm the outputs cover the same completed load or time window. Preserve
  that scope while validation runs.

Fabric Lakehouse and Warehouse tables are read through their SQL endpoints by
your customer ADF execution factory. Data preparation and validation stay in
your Azure environment. The factory needs workspace access, and each imported
table must pass preparation before it is ready for validation. Follow
[Connect Microsoft Fabric](/connect-microsoft-fabric) to connect the workspace,
review its table catalog, and resolve access or listing issues.

## Pair the old and new outputs

Create a Dataset Pair with the existing pipeline's output as the **source** and
the migrated pipeline's output as the **target**. Apply source and target filters
if you are validating a specific window or partition.

Choose stable join keys for row-level comparisons. A Pair supports up to five
key columns. Joined-value Tests reject ambiguous matching keys; see
[Comparison and safety rules](/supported-scope#comparison-and-safety-rules)
for how matching and unmatched keys are handled.

For detailed authoring steps, see
[Creating your first test](/creating-your-first-test).

## Build the migration checks

| Check                      | Use it to establish                                                       |
| -------------------------- | ------------------------------------------------------------------------- |
| `COUNT_ROWS`               | Whether the row counts reconcile for the selected scope                   |
| `SUM`, `AVG`, `MIN`, `MAX` | Whether important aggregates reconcile                                    |
| `COUNT`, `COUNT_DISTINCT`  | Whether field population and distinctness reconcile                       |
| `VALUE`                    | Whether selected field values match on corresponding keys                 |
| `OUTER_VALUE`              | Whether selected values match, including rows missing from either side    |
| Set functions              | Whether a field's value set is contained in the other side or equal to it |

Counts and aggregates alone can miss changes that cancel each other out. Add
value checks for the columns that matter to the cutover. Set thresholds and
allowed failed rows deliberately, and enable a bounded failed-row capture
limit when reviewers need discrepancy evidence.

If the migration intentionally changes a representation, choose an explicit
supported transform where the editor offers one. General Validation reconciles
outputs against the rule you configure; it does not recreate your business
transformation.

## Run and review

1. Save the Pair and Tests, then choose **Run pair**.
2. Open **Results**, select the Run, and wait for validation and result delivery
   to finish.
3. Review each Test's verdict and rule. An execution error requires an
   operational fix; a failed comparison requires investigation of the data or
   configured expectations.
4. Open the selected result to see exact source and target observations and
   captured failed rows where available. Your browser uses your delegated
   Storage access to read these directly from your Azure account.
5. Record the Run ID, checked scope, outcomes, and customer evidence references
   in your organization's cutover record. Review unresolved failures before
   approving the migration.

The hosted service retains configuration snapshots, status, verdicts, counts,
and artifact references. Exact values, deltas, and row evidence remain in your
Azure Storage. Preserve those artifacts under your own retention policy and
use your existing approval process for cutover sign-off. See
[Runs, results & evidence](/runs-results-and-evidence).

## After the cutover

Keep the relevant Pairs and Tests for regression checks on later releases and
loads. A Pair's source and target cannot be changed after creation. If the old
system is retired, create a replacement Pair with the new reference source and
author its Tests; retain or archive the migration Pair for its history. See
[Validating on an ongoing basis](/validating-on-an-ongoing-basis).