29 Sep 2026

Snowflake to Microsoft Fabric: Warehouses Become Capacity

Snowflake and Microsoft Fabric both deliver enterprise-scale analytics, but they're built on genuinely different architectures. Snowflake separates storage from compute across independently scaling virtual warehouses; Fabric consolidates ingestion, engineering, warehousing, and BI into one platform built on OneLake, with F-SKU capacity shared across every workload. Migrating between them means re-architecting the platform, not just moving tables and calling it done.

Quick Summary

A Snowflake-to-Microsoft Fabric migration re-maps virtual warehouses to F-SKU capacity, Snowpipe ingestion to Data Factory pipelines, and Snowflake's ANSI SQL to Fabric's T-SQL/Spark SQL dialects. Schemas move to OneLake as Lakehouse or Warehouse items, RBAC roles map to Microsoft Entra ID and Purview, and every converted query needs validation because the two platforms handle functions, casts, and aggregation behavior differently. A phased, reconciliation-gated process is what keeps a large Snowflake estate from breaking during the switch.

snowflake-to-microsoft-fabric-automation

Key Takeaways

This is a re-architecture, not a lift-and-shift. Snowflake's decoupled warehouse model and Fabric's unified, OneLake-centered platform don't map one-to-one.
Virtual warehouses become F-SKU capacity. Fabric's shared, tenant-wide capacity model replaces Snowflake's independently scaling compute clusters.
SQL needs validation, not just translation. Snowflake's SQL dialect and Fabric's T-SQL/Spark SQL differ in functions, implicit casts, and aggregation behavior.
Snowpipe and Streams/Tasks become Fabric-native pipelines. Ingestion and change-data-capture patterns are rebuilt using Data Factory, Dataflow Gen2, or Spark notebooks.
RBAC becomes Entra ID and Purview. We re-implement Snowflake's role-based access control using Fabric's workspace roles and governance model.
Reconciliation is the gate, not a formality. We validate every migrated table and query against Snowflake output before cutover.

What Is Snowflake to Microsoft Fabric Migration?

Snowflake to Microsoft Fabric migration is the process of moving databases, schemas, warehouses, pipelines, and security models from Snowflake onto Microsoft Fabric. Snowflake operates as a decoupled cloud data warehouse, separating storage and compute, with independently scaling virtual warehouses handling query workloads. Fabric works differently: it's built around a lakehouse architecture where storage and compute converge through OneLake, and F-SKU capacity is shared across every Fabric workload, not scaled per-warehouse the way Snowflake does it, the same architectural mismatch covered in our Snowflake vs Microsoft Fabric comparison for organizations still weighing which platform to standardize on.

Because the two platforms organize data, compute, and governance differently, migration means re-architecting workloads rather than copying schemas across, the same rebuild-by-intent principle covered in our ETL migration to Microsoft Fabric guide for other source platforms landing on Fabric.

Why Organizations Make This Move

Unified analytics experience. Fabric consolidates ingestion, engineering, warehousing, and BI into one ecosystem, reducing the tool-switching a separate Snowflake-plus-BI-stack requires.
Tighter Azure and Power BI integration. Organizations already standardized on Microsoft get native connectivity to Azure services and Direct Lake performance for Power BI reporting.
Simplified consumption. Power BI queries Fabric's OneLake directly via Direct Lake mode, removing a separate import or refresh step that some Snowflake-plus-Power BI architectures require.
Licensing consolidation. Fabric capacity that's already purchased for Power BI can be shared across data engineering and warehousing workloads too, the same capacity-sharing logic covered in our Azure to Microsoft Fabric migration guide.
Governance consistency. Microsoft Purview and Entra ID give organizations one governance and identity model across data and BI, instead of separate Snowflake RBAC and a separate BI-tool permission model.

Snowflake to Fabric Asset Mapping

Snowflake Object	Fabric Equivalent	Migration Note
Database / Schema	Lakehouse / Warehouse (OneLake)	Redesigned around OneLake's storage model, not copied directly
Virtual Warehouse (compute)	F-SKU capacity	Independently scaling compute becomes shared, tenant-wide capacity
Table (native format)	Delta Lake table	Landed on OneLake in open Delta/Parquet format
Snowpipe (continuous ingestion)	Data Factory pipeline / Dataflow Gen2	Rebuilt using Fabric-native ingestion, not a direct port
Streams and Tasks (CDC/orchestration)	Data Factory pipeline triggers / Spark notebooks	Change-data-capture and scheduling logic rebuilt in Fabric's own model
Snowflake SQL / stored procedures	T-SQL (Warehouse) or Spark SQL/PySpark (Lakehouse)	Converted and validated, not translated line by line
Time Travel	Delta Lake time travel	A genuine parallel; both support querying prior table versions, though retention mechanics differ
RBAC (roles and grants)	Microsoft Entra ID + workspace roles	Access control redesigned around Fabric's identity and workspace model
Data governance / masking policies	Microsoft Purview	Governance and lineage centralized through Purview rather than Snowflake's native policies
Snowsight dashboards	Power BI reports (Direct Lake)	Rebuilt natively in Power BI, not converted

SQL and Query Behavior: What Actually Changes

Query compatibility is where migrations quietly go wrong if you treat it as a mechanical find-and-replace. Snowflake's SQL dialect, its function library, semi-structured data handling (VARIANT, FLATTEN), and specific aggregation behavior don't map one-to-one onto Fabric's T-SQL (for Warehouse) or Spark SQL/PySpark (for Lakehouse). Implicit type casting, null handling, and window-function behavior are common places where a converted query silently returns a different result than the original- the same silent-drift risk covered in our guide to automating ETL testing with Python.

The reliable pattern is to convert, then validate: check every converted query or stored procedure against its Snowflake output using representative data and edge cases, not because it runs without error.

The Migration Process

Discovery and assessment. Inventory Snowflake databases, schemas, warehouses, pipelines (Snowpipe, Streams, Tasks), and downstream BI consumers, scoring complexity to sequence the work, the same complexity-scoring approach covered in our key checklist for BI modernization.
Design the Fabric target. Plan OneLake structure (Lakehouse vs. Warehouse per workload), F-SKU capacity sizing, workspace organization, and the Entra ID/Purview governance model.
Land the data. Move schemas and tables onto OneLake in Delta format, via Data Factory pipelines, Dataflow Gen2, or bulk export/import, depending on volume and freshness needs.
Rebuild ingestion and orchestration. Convert Snowpipe continuous ingestion and Streams/Tasks change-data-capture patterns into Fabric-native pipelines, triggers, or Spark notebooks.
Convert and validate SQL. Translate Snowflake SQL, stored procedures, and semi-structured data handling into T-SQL or Spark SQL, validating every converted object against source output.
Rebuild security and governance. Map Snowflake RBAC roles and grants to Entra ID and workspace roles, and configure Purview for governance, lineage, and masking policies.
Rebuild reporting. Recreate Snowsight dashboards as Power BI reports, using Direct Lake mode where it fits for performance.
Reconcile and cut over. Run Snowflake and Fabric in parallel, reconciling record counts, aggregations, and business metrics before decommissioning Snowflake, the same parallel-run discipline covered in our guide to BI automation for report migration.

Common Challenges

Architectural mismatch. Snowflake's per-warehouse compute scaling doesn't map directly onto Fabric's shared capacity model; workload sizing needs to be rethought, not just re-labeled.
SQL and function differences. Snowflake-specific functions, semi-structured data handling (VARIANT, FLATTEN), and implicit casting behave differently in T-SQL or Spark SQL and need case-by-case validation.
Ingestion and CDC redesign. Snowpipe and Streams/Tasks patterns don't port directly; they're rebuilt using Fabric's own pipeline and trigger model.
Security model mapping. Snowflake's RBAC doesn't map one-to-one onto Entra ID and Purview; access rules need explicit redesign and testing.
Capacity sizing and cost. Guessing F-SKU capacity from Snowflake's virtual warehouse sizing leads to throttling or overspend; size it from measured Fabric workload behavior instead.
Reporting rebuild. Snowsight dashboards have no direct Power BI import path and need to be rebuilt natively.

Best Practices

Inventory before converting anything. A full catalog of databases, warehouses, pipelines, and downstream consumers prevents wasted effort on unused or duplicate content, the same rationalize-first discipline covered in our key checklist for BI modernization.
Convert, then validate, every query. Treat SQL conversion as a translation that needs checking, not a mechanical find-and-replace.
Redesign ingestion around Fabric's own model, rather than trying to replicate Snowpipe's exact mechanics inside Fabric.
Size F-SKU capacity from real Fabric workload behavior, not from Snowflake's virtual warehouse sizing.
Rebuild security independently, testing that Entra ID and Purview rules produce the same access outcomes as Snowflake's RBAC did.
Run a genuine parallel period before decommissioning Snowflake, reconciling figures across a full reporting cycle, not just a spot check.

Frequently Asked Questions

Is this a lift-and-shift migration?

No. Snowflake's decoupled warehouse architecture and Fabric's unified, OneLake-centered platform are structurally different; migration re-architects workloads rather than copying schemas directly across.

What happens to Snowflake's virtual warehouses?

They're replaced by Fabric's F-SKU capacity model, shared, tenant-wide compute rather than independently scaling per-warehouse clusters. Sizing needs to be based on measured Fabric workload behavior, not a direct translation of Snowflake warehouse sizes.

Does Snowflake SQL convert directly to Fabric?

No. Snowflake's SQL dialect, functions, and semi-structured data handling differ from Fabric's T-SQL and Spark SQL. Validate every converted query or stored procedure against its original Snowflake output.

What replaces Snowpipe and Streams/Tasks?

Data Factory pipelines, Dataflow Gen2, or Spark notebooks, depending on the ingestion and orchestration pattern, rebuilt in Fabric rather than ported directly.

How is Snowflake security migrated?

Snowflake's RBAC roles and grants are mapped to Microsoft Entra ID and Fabric workspace roles, with governance, lineage, and masking handled through Microsoft Purview. This is a redesign, not a direct carryover.

Migrate Your Snowflake Estate with DataTerrain

DataTerrain brings 17+ years and 400+ clients in data platform migration to Snowflake-to-Fabric engagements, covering architecture assessment, SQL conversion and validation, ingestion rebuild, and security mapping through Entra ID and Purview, the same broad platform coverage reflected in our ETL migration to Microsoft Fabric work.

Talk to our migration team