Most teams running Microsoft Fabric alongside Snowflake aren’t migrating. Four hybrid patterns show up in production estates today, and only one is a full migration off Snowflake. OneLake shortcuts and Fabric Mirroring for Snowflake move data between the two platforms with zero lineage propagation, by design: both are data-access and replication features, not lineage ones. Microsoft Purview’s Snowflake connector tracks lineage too, but it stays Snowflake-internal; it doesn’t stitch into Fabric’s side of the graph. Snowflake’s own External Lineage feature, dated by Snowflake’s release notes to general availability on September 3, 2026, is the first native crack in that boundary, but it’s push-based: something has to send OpenLineage events to it, and nothing documented makes Fabric do that automatically. The result is two separately-crawled, separately-governed metadata graphs sharing some of the same underlying data. Closing that gap, and doing it again for the business definitions living in Snowflake Semantic Views and Power BI semantic models, is a context layer’s job: crawl both platforms, then join what you find on matching identifiers.
What follows: what each native tool actually covers, how to tell which pattern an estate is running, what changes for the smaller group genuinely migrating, and the mistakes teams make most often assuming one platform’s governance reaches the other.
- Time to assess: 1–2 weeks to map the pattern and audit each platform’s native lineage.
- Time to close the gap: 2–4 weeks to configure cross-platform crawling and identifier matching, on top of standing up the architecture itself.
- Difficulty level: Intermediate to advanced. Identifier and metadata hygiene across both platforms matters more than any single step.
- Prerequisites: Admin or read access to Snowflake (Horizon or Snowsight) and Fabric (OneLake, Purview if licensed), plus clarity on the pattern in play.
- Tools needed: Snowflake Horizon, Microsoft Purview (if licensed), the native Fabric integration in use, and a cross-platform context layer if closing the gap.
Why doesn’t lineage cross the Snowflake–Fabric boundary without a context layer?
Fabric’s and Snowflake’s native tools were built to move and access data across the boundary between them, not to carry lineage across it, and that gap shows up regardless of why a team runs both.
Per Microsoft and Snowflake’s own joint framing of their partnership, in Snowflake and Microsoft announce expansion of their partnership (Microsoft, 2024), the goal was never governance continuity. Christian Kleinerman, Executive Vice President of Product at Snowflake: “As both Snowflake and Microsoft are firm believers in open standards, we see our joint support for Apache Iceberg as an opportunity to offer customers choice when it comes to how and where they interact with their data.” A statement about data access and open formats, not lineage or shared definitions.
What’s missing is narrower than “unified governance”: an identifier-matching problem between two independently-crawled systems, Snowflake’s own lineage graph and whatever Fabric and Microsoft Purview see on their side. A context layer for Snowflake closes that for one half of the estate: crawl both platforms, then join what comes back on matching identifiers, a context engineering problem more than a migration one. Coexistence, not replacement, is the estate most teams run, and the context layer reference architecture that does the stitching is infrastructure work, not a byproduct of whichever vendor’s roadmap wins. Atlan’s comparison of Microsoft Fabric and Snowflake covers the architecture-level differences; what follows goes deeper on lineage specifically, the same ground a context layer for AI agents covers more broadly.
Prerequisites for a cross-platform lineage audit
Four things need to be in place, and skipping any one is the most common reason audits stall halfway through.
Organizational: authority to request admin or read access on both platforms, plus agreement on the hybrid pattern in play, a decision that changes every step after.
Technical: Snowflake Horizon or Snowsight access, Fabric OneLake access, Purview access if licensed, and a documented mapping of which Snowflake tables resolve into which Fabric Lakehouse or workspace. Atlan’s Snowflake connector architecture and the OneLake catalog are useful references here.
Team: a data platform owner on the Snowflake side, and a Fabric or Purview owner on the other, roles that rarely sit with the same person.
Time: one to two weeks for the audit alone, two to four more if the gap needs closing.
Decide which of the four patterns you’re actually running
Name whether the estate is coexisting indefinitely or genuinely migrating first: the gap exists in both cases, but what to do about it differs. Four patterns cover what’s out there; only the fourth is a true migration, addressed further down.
| Pattern | Snowflake’s role | Fabric’s role | Is this a migration? |
|---|---|---|---|
| Snowflake-primary, Fabric for BI/Copilot | Remains the primary warehouse | Added for BI/Copilot consumption via OneLake shortcuts or Mirroring | No |
| Bidirectional Iceberg sharing | Shares data via open Iceberg tables | Reads and writes the same Iceberg tables | No |
| Permanent coexistence via Mirroring | Runs core workloads indefinitely | Hosts near-real-time mirrored copies for Fabric-native tools | No |
| Phased full migration | Progressively decommissioned | Becomes the primary platform over 12–18 months | Yes |
The common mistake is treating all of this as one undifferentiated “migration” because that’s the default vocabulary. The multi-cloud context layer logic that applies to a Databricks-and-Snowflake estate applies here too: name the pattern before picking tooling. The same discipline carries over to a Synapse to Fabric migration running in parallel elsewhere in the estate: a different source platform, the identical metadata-and-lineage-continuity problem.
What does Fabric’s native Snowflake integration actually give you?
Fabric’s native Snowflake integrations are data-access and replication features. Neither mentions lineage or metadata propagation in Microsoft’s own documentation.
OneLake shortcuts give Fabric zero-copy, read-only access to Snowflake’s Iceberg tables: data “remains in Snowflake but appears in the OneLake logical data estate,” per Microsoft Learn. Fabric Mirroring for Snowflake works differently, using change data capture to land near-real-time replicas of entire Snowflake databases into OneLake. Microsoft’s Mirroring overview and GA announcement, like Snowflake’s own OneLake REST catalog integration docs, describe pure data access and replication, no lineage claim anywhere, a citable absence, not an inference from silence.
Reliable data movement isn’t reliable lineage. Fabric’s native tools solve the first problem well and don’t attempt the second, which is why a coexistence estate needs something watching both sides. Fabric IQ, Work IQ, and Foundry IQ, including what Fabric IQ itself covers, leave the identical gap open for anything outside Fabric itself.
Does Microsoft Purview’s Snowflake connector extend lineage into Fabric?
No. Purview’s Snowflake connector lineage is scoped to relationships among Snowflake’s own objects.
Microsoft’s “Connect to and manage Snowflake in Microsoft Purview” documentation says scanning Snowflake gives Microsoft Purview “static lineage on assets relationships among tables, views, streams, and stored procedures,” lineage inside Snowflake, not lineage reaching into Fabric. Snowflake and Fabric are registered as separate sources inside Purview’s Unified Catalog, with no documented mechanism stitching the two registrations together. Where Purview’s own data governance coverage stops on non-Microsoft sources generally is the same boundary this lineage gap sits on.
Teams running Purview, who’ve worked through its governance evaluation questions or configured its AI controls for agents, can reasonably assume governance is covered. It covers plenty, just not this. “We have Purview, so we have lineage” is true within each platform separately; it isn’t true across the boundary, and assuming otherwise is the most common planning error in a Snowflake-and-Fabric estate. Whether to coexist with, extend, or replace Purview outright is a separate decision from this specific lineage gap, one worth making deliberately rather than by default.
What does Snowflake’s own lineage tooling cover, and what does External Lineage change?
Snowflake’s native lineage graph, inside Snowsight and Horizon, covers its own table-like objects. External Lineage is the first crack in that boundary, but it’s push-based, not automatic discovery.
Per Snowflake’s Snowsight lineage documentation, native scope covers tables, views, dynamic/external/Iceberg tables, materialized views, and semantic views, all within Snowflake. A separate, narrower claim says Snowflake “can track data lineage for sources and destinations outside of Snowflake,” but names nothing specific to Fabric, OneLake, or Power BI.
External Lineage reached general availability on September 3, 2026, according to Snowflake’s release notes. Nothing in Microsoft’s Fabric documentation describes Fabric emitting events to it, so in an unconfigured hybrid estate it shows nothing from the Fabric side, much like Snowflake Horizon’s catalog capabilities stop at Snowflake’s own boundary. Teams querying Snowflake through its MCP server hit the same wall: a protocol for reaching Snowflake doesn’t resolve the other side of the estate.
Five native mechanisms, side by side:
| Mechanism | What it does | Carries lineage across platforms? | Source |
|---|---|---|---|
| OneLake shortcuts | Zero-copy, read-only access to Snowflake’s Iceberg tables | No, metadata-only access | Microsoft Learn, Snowflake Docs |
| Fabric Mirroring for Snowflake | CDC-based near-real-time replication of entire Snowflake databases into OneLake | No, data replication only | Microsoft Fabric Mirroring docs |
| Purview’s Snowflake connector | Scans Snowflake, builds lineage among its own tables, views, streams, and procedures | No, stays Snowflake-internal | Microsoft Purview docs |
| Snowflake native lineage (Snowsight/Horizon) | Tracks lineage among Snowflake’s own tables, views, and materialized/semantic views | No, Snowflake-internal only | Snowflake Docs |
| Snowflake External Lineage | Accepts OpenLineage events via REST endpoint from tools like dbt or Airflow | Only if something pushes Fabric-side events, nothing does by default | Snowflake Docs |
How do you close the lineage gap between Snowflake and Fabric?
Closing the gap is a configuration problem, not a one-click feature: crawl both platforms, then match what comes back on identifiers they actually share.
A cross-platform context layer crawls Snowflake, typically by parsing query history for the SQL statements that create and transform tables, and crawls Fabric independently, extracting lineage from the warehouse layer into Fabric assets. See Atlan’s Microsoft Fabric connector overview and Snowflake connector overview for what each side covers. The two graphs are then joined on matching identifiers, not automatic discovery with zero configuration: it depends on how consistently both platforms name the same assets.
No one-click migration or unification claim either. What implementing an enterprise context layer requires here is the harness engineering discipline any multi-system lineage problem needs: crawl order matters, identifier hygiene matters, and AI-ready lineage means something only once both sides are actually watched.
Keeping business definitions consistent, not just lineage
“Lineage” and “definitions” are two different problems that this topic’s search vocabulary blurs together.
Snowflake Semantic Views govern business meaning, what “active customer” or “net revenue” means, inside Snowflake. Power BI semantic models do the equivalent job in Fabric and Power BI. Neither is aware of the other, and a metric defined in one doesn’t propagate to the other: two separately-governed, non-interoperable systems for the same problem.
| System | Platform | Scope | Interoperable with the other? |
|---|---|---|---|
| Snowflake Semantic Views | Snowflake | Business definitions and metrics for Snowflake-native consumption | No |
| Power BI semantic models | Fabric / Power BI | Business definitions and metrics for Power BI reports | No |
Less visible than a broken lineage graph, which is why it gets dropped. Teams who’ve read why semantic layers fail without context graphs, or compared Power BI’s semantic model against a dedicated semantic layer, know the pattern: a semantic layer stopping at one platform’s edge solves half the job, whether the second system is a dbt Semantic Layer or Fabric’s own. Treating semantic views as materialized context on the same semantic layer checklist as lineage keeps “definitions across both” from quietly dropping.
If you’re actually migrating off Snowflake, what changes
For the smaller group genuinely migrating, a phased twelve-to-eighteen-month move, the fourth pattern in analyst taxonomies like Kanerika’s, is the honest secondary case here.
Migration mechanics (object inventory, data movement, cutover sequencing) are covered elsewhere. What belongs here is the lineage and definitions gap during and after cutover, which doesn’t close itself just because the move is one-way. Migration is a forcing function to audit it properly, an audit teams running Fabric and Power BI lineage proofs of value or building end-to-end column-level lineage for Power BI already run regardless of why Snowflake is in the picture.
No one-click Purview migration claim either. Whether lineage survives a cutover depends on the crawl-and-match mechanism above, run once as a checkpoint instead of ongoing maintenance. A Fabric database agent and a data agent solve related but distinct jobs, the same way, rather than one covering the other.
What goes wrong when you assume Purview or Mirroring carries lineage for you?
Every mistake below treats a data-access or replication feature as if it were a lineage feature.
Assuming Purview’s Snowflake scan lineage extends into Fabric
Why it happens: Purview’s real Snowflake-internal lineage is easy to mistake for full coverage.
How to avoid it: Check whether the lineage stays inside one registered source first.
Assuming OneLake shortcuts or Fabric Mirroring carry metadata
Why it happens: both move real data reliably, which reads as integration.
How to avoid it: Check Microsoft’s own docs. Neither mentions lineage or metadata propagation.
Assuming Snowflake’s External Lineage will show Fabric activity without configuration
Why it happens: the name implies it “sees” external systems automatically.
How to avoid it: Confirm something is actually pushing OpenLineage events. Nothing does by default.
Conflating business definitions with lineage
Why it happens: the working vocabulary, search queries included, blurs both terms.
How to avoid it: Track definitions coverage separately from lineage, the discipline an ontology-first approach applies more broadly.
Treating migration as the only pattern worth planning for
Why it happens: search and sales vocabulary defaults to migration language, even when the job is extending ontology beyond Snowflake rather than leaving it.
How to avoid it: Name the pattern before choosing tooling. A ReGovern-style approach to building a semantic layer treats this as a first step, not an afterthought.
Every mistake above traces to one root cause: a feature built for data access, replication, or internal scanning, doing a job it was never designed for.
Best practices for keeping Snowflake and Fabric lineage and definitions aligned
Teams that get this right share a few habits: name the pattern before picking tooling, track lineage and definition gaps as separate checklist items rather than one “governance” line, and treat identifier consistency, workspace IDs, Lakehouse IDs, exact-case column names, as a prerequisite, not an afterthought.
If using External Lineage, instrument the Fabric-side pipeline to push OpenLineage events; nothing does this automatically. Re-verify native tool scope periodically, and decide who owns the stitched graph, data platform or governance, before scaling past a pilot.
Teams running Fabric’s own MCP servers or experimenting with translytical task flows hit an identical lesson: a feature built for one job rarely covers an adjacent one, confirmed again by evaluating the best semantic layer tools against this estate.
What to do after you’ve mapped your Snowflake–Fabric lineage gap
“Done” looks like one place where a Snowflake table and its downstream Fabric asset show up connected, with identifier matching documented rather than assumed.
Measure it as a ratio: matched assets against skipped assets over time, not a one-time snapshot. A high skip rate usually points to a naming mismatch worth fixing at the source, not a sign the approach is wrong.
Revisit the mapping after any native-tooling change on either side. External Lineage is new enough that its behavior, and whatever Fabric does or doesn’t eventually push to it, is still moving. The gap above is a snapshot of where the two platforms stand today, not a permanent limit.
How does Atlan close the Snowflake–Fabric lineage gap?
Atlan’s role here is precise: crawl both platforms, join them on matching identifiers, and skip what doesn’t match rather than guessing.
A Snowflake-and-Fabric hybrid estate produces two independently-crawled metadata graphs, each accurate on its own side, with no native stitch between them: the gap documented above.
Atlan crawls Snowflake by parsing query history, statements like CREATE TABLE, CREATE VIEW, CTAS, MERGE, INSERT INTO, UPDATE, and CLONE, for table- and column-level lineage. On the Fabric side, per Atlan’s documentation, it extracts upstream SQL lineage from external warehouse assets into Fabric assets, the same pattern Atlan uses for upstream lineage from the data warehouse layer generally.
The cross-platform hop has a hard prerequisite, stated plainly in Atlan’s own documentation: “Tables cataloged by another connection must be crawled before the Microsoft Fabric crawler runs.” Atlan matches Lakehouse tables to the external source by workspace and Lakehouse IDs, and column names must match the cataloged columns exactly, including case. Datasets that don’t match are skipped; Atlan doesn’t create placeholder assets for them.
A narrower, more honest claim than unifying governance outright: identifier matching across two systems that were never going to reconcile themselves. That’s the coexistence logic running through every pattern above. Snowflake and Fabric don’t need to be at war for their metadata to need a mediator.
FAQs about Snowflake-to-Fabric lineage
1. Does Microsoft Purview track lineage into Snowflake?
Purview can scan Snowflake and build lineage among Snowflake's own tables, views, streams, and stored procedures, but that lineage stays inside Snowflake. Purview registers Snowflake and Fabric as separate sources, with no documented mechanism stitching the two together.
2. Does Fabric Mirroring for Snowflake carry over metadata or lineage?
No. It replicates data using change data capture, landing near-real-time copies of Snowflake databases into OneLake. Neither Microsoft's mirroring overview nor its GA announcement describes any lineage or metadata propagation alongside the replicated data.
3. Can I use Snowflake and Microsoft Fabric together without migrating fully?
Yes, and most teams do. Of the four common architecture patterns, three keep Snowflake permanently in the estate: Snowflake-primary with Fabric for BI and Copilot consumption, bidirectional Iceberg sharing, and permanent coexistence through Mirroring. Full migration is only one of the four, not the default.
4. What’s the difference between OneLake shortcuts and Fabric Mirroring for Snowflake?
OneLake shortcuts give Fabric zero-copy, read-only access to Snowflake's Iceberg tables; the data stays in Snowflake and appears inside OneLake. Mirroring instead replicates entire Snowflake databases into OneLake using change data capture, creating near-real-time copies rather than pointers.
5. Does Snowflake’s lineage graph show what happens to data after it moves into Fabric?
Not by default. Snowflake's native lineage, inside Snowsight and Horizon, covers tables, views, dynamic and external tables, materialized views, and semantic views within Snowflake. A separate, narrower capability exists for some external sources, but names nothing specific to Fabric, OneLake, or Power BI.
6. How do I keep one set of business definitions across Snowflake Semantic Views and Power BI semantic models?
Neither platform does it natively; they're two separate, non-interoperable systems. Snowflake Semantic Views govern meaning inside Snowflake, and Power BI semantic models govern meaning inside Fabric. A metric defined in one doesn't propagate to the other, so keeping them aligned takes a layer that reads both.
7. What is Snowflake’s External Lineage feature, and does it cover Microsoft Fabric?
External Lineage, generally available since September 2026, lets Snowflake accept OpenLineage-compatible events via a REST endpoint from tools like dbt or Airflow, then display lineage nodes for outside systems. It doesn't cover Fabric automatically; something has to be configured to push those events, and nothing in Fabric's documentation does that by default.
8. Do I need a third-party catalog if I run both Snowflake and Fabric?
Not to use either platform, but something beyond their native tooling is needed if lineage and business definitions need to carry across both. Purview's Snowflake lineage stays internal, and neither OneLake shortcuts nor Mirroring carry metadata, so a cross-platform context layer is what closes that gap.
Sources
- Integrate Microsoft Fabric with External Systems, Microsoft Learn
- Connect to and Manage Snowflake in Microsoft Purview, Microsoft Learn
- Microsoft Fabric Mirroring Overview, Microsoft Learn
- Announcing General Availability of Mirroring for Snowflake in Microsoft Fabric, Microsoft Fabric Updates Blog
- Configure a Catalog Integration for OneLake REST, Snowflake Docs
- Snowsight Data Lineage, Snowflake Docs
- External Lineage, Snowflake Docs
- External Lineage General Availability, Snowflake Release Notes
- Snowflake Horizon Catalog Overview, Snowflake Docs
- Snowflake and Microsoft Announce Expansion of Their Partnership, Microsoft
- What Lineage Does Atlan Extract From Microsoft Fabric, Atlan Docs
- How Can Atlan Generate Upstream Lineage From the Data Warehouse Layer, Atlan Docs
- Microsoft Fabric Connector Overview, Atlan Docs
- Snowflake Connector Overview, Atlan Docs
