Fabric Warehouse deployed successfully but still differs: inspect the skipped change

A deployment pipeline finishes, yet the Warehouse still shows a difference from its source. A recent Fabric practitioner discussion describes this frustrating state. It is tempting to press Deploy again. First establish which objects actually changed and which did not.

Compare before and after at object level

Save the pipeline comparison, deployment operation and schema inventory for both stages. Microsoft says Fabric's Warehouse deployment pipeline uses DacFx to compare and apply schema changes, and the feature is in preview. Inspect the specific table, view or column that still differs; a generic “different” badge is not an explanation.

Know what success does not cover

Microsoft explicitly notes that a successful Warehouse deployment may skip a requested table drop because drops are blocked by default. The same guide says logins, users and permissions are excluded from the deployment, and objects present only in target are not automatically dropped. These are design boundaries, not evidence that the data itself is corrupt. Resolve each intended exception through a reviewed schema or access change, not a broad retry.

Turn the comparison into a release gate

Define an expected change list, an allowed-drift list and an after-deploy comparison. Include downstream query smoke checks for objects that changed. If a target-only object is deliberately retained, document its owner and expiry. If the plan contains a destructive change, handle it as a separate migration with data and access impact reviewed first.

Adovo’s view

Deployment success means the operation completed under its rules. Release success means the intended contract exists in the target. Treat those as two checks, and the drift badge becomes an action list instead of a mystery.