A Direct Lake model moves workspaces but still points at the old source

The semantic model appears in the new Fabric workspace, yet refresh or query behavior reveals that it still depends on the old lakehouse. A Fabric community account describes that surprise. The failure can look like a permission problem while the underlying issue is the connection target.

Verify the binding, not the item name

Record the model's current Direct Lake connection expression, SQL analytics endpoint URL and source item ID. Microsoft documents cross-workspace dependency binding: for Git-based deployment, a Direct Lake on SQL model's expressions.tmdl can retain the original endpoint URL and database GUID. A model named “Production” is not proof that it reads production data.

Separate Git from pipeline behavior

Deployment pipelines can apply dependency binding under their documented conditions; copying an item or deploying from Git is a different path. Identify the actual route used before editing connection expressions. Then verify the service identity has the needed rights on the intended source. A correct endpoint with the wrong principal still fails, and a permissive principal can hide a wrong endpoint.

Test with a source fingerprint

Use a harmless known record or data-version marker that differs between old and new lakehouses. Query through the moved model and confirm the expected marker, source identity and refresh behavior. Store that check with the deployment record. It catches both an obvious broken connection and the more dangerous case of a model that quietly serves old data.

Adovo’s view

Moving a model is not moving its meaning. The meaning includes the source it reads and the identity allowed to read it. A release is complete only when those bindings are proven against real data.