Skip to main content
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 with a ready customer Environment and an Owner or Contributor account.
  • Have the old and new outputs available in supported formats.
  • 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. The runtime stages the selected data to customer-owned Parquet before comparing it. A listed Fabric workspace or table still needs a ready endpoint, a qualified schema, and execution access.

​
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. General Validation supports up to five key columns; duplicate normalized keys fail a joined-value Test so ambiguous row matches cannot pass silently. For detailed authoring steps, see Creating your first test.

​
Build the migration checks

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.

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