Migration
Snowflake to Microsoft Fabric migration: mirroring, T-SQL and what changes
How to move from Snowflake to Microsoft Fabric, or run both: mirroring and Iceberg interoperability, converting Snowflake SQL to Fabric Warehouse T-SQL, VARIANT, streams and tasks, Snowpark, security, and a domain-by-domain cutover.
Hemant Walchale
· 4 min read
Organisations standardising on Microsoft often look at moving Snowflake workloads into Microsoft Fabric, to put data engineering, warehousing and Power BI on one capacity with OneLake underneath. The good news is that you do not need a big-bang move: Fabric can mirror Snowflake data, so you can migrate consumers first and logic later. The real work is converting Snowflake SQL to Fabric’s T-SQL and replacing Snowflake-specific features.
This is the approach we recommend.
1. Decide: migrate, or run both
Be explicit about the end state:
- Coexist: keep Snowflake for core warehousing and mirror selected tables into Fabric for Power BI, data science and new domains.
- Migrate: move all workloads to Fabric and retire Snowflake domain by domain.
Either way, start by mirroring. It lets Power BI and Fabric workloads use Snowflake data in OneLake before any code is converted.
2. Inventory
List databases, schemas, tables (including transient, dynamic and Iceberg tables), views, stored procedures, UDFs, streams, tasks, Snowpipes, stages, shares, Snowpark code, roles and policies, and the dashboards and applications that read them. ACCOUNT_USAGE query and access history show what is used.
3. Map Snowflake to Fabric
| Snowflake | Microsoft Fabric | What to watch |
|---|---|---|
| Virtual warehouses | One capacity (F SKU) shared by all workloads | Size for smoothed peaks; isolate heavy workloads. See Fabric capacity sizing. |
| Snowflake SQL | Fabric Warehouse T-SQL, or Spark SQL in a lakehouse | Function and syntax changes; no Microsoft converter for Snowflake. |
| Unquoted identifiers stored upper case | Identifiers keep their case | Watch tools and code that rely on upper-case names. |
| Case-sensitive comparisons | Case-sensitive by default (Latin1_General_100_BIN2_UTF8); case-insensitive warehouses available |
Collation is set when a warehouse is created and cannot be changed later. |
VARIANT, OBJECT, ARRAY |
JSON in VARCHAR with JSON functions, or Spark structs in a lakehouse |
Semi-structured logic needs the most rewriting. |
| Snowflake Scripting procedures | T-SQL procedures, notebooks or pipelines | Rewrite error handling and loops. |
| Streams and tasks | Data Factory pipelines, notebooks, or CDC in Spark | Rebuild incremental logic and schedules. |
| Snowpipe, stages | Pipelines, copy jobs, shortcuts, mirroring | Land in OneLake. |
| Snowpark | Spark notebooks | DataFrame code ports with API changes. |
| Time travel | Warehouse time travel (FOR TIMESTAMP AS OF), 1 to 120 days, default 30 |
Check retention needs. |
| Zero-copy clone | Warehouse table clones | Similar. |
| Secure data sharing | OneLake shortcuts and external data sharing | Different model. |
| Roles, masking and row access policies | Workspace roles, SQL permissions, row-level security, dynamic data masking | Re-create; mirroring does not carry Snowflake security across. |
4. Mirror, then convert domain by domain
- Mirror the tables each domain needs into OneLake. Managed tables, Iceberg tables, views and materialized views are supported; transient, temporary, dynamic and external tables are not.
- Repoint Power BI to the mirrored data or a Fabric semantic model. Reports often deliver value in weeks, before any pipeline moves.
- Convert pipelines and logic for the domain: rebuild ingestion in Data Factory or notebooks, convert SQL to T-SQL or Spark SQL, and replace streams and tasks.
- Re-create security in Fabric, on groups, before users get access.
5. Reconcile and retire
Compare tables between Snowflake and Fabric on row counts, totals and row-level differences matched on business keys. Once a domain’s pipelines run natively in Fabric and owners sign off, stop mirroring those tables, suspend the related Snowflake warehouses and tasks, and drop the objects after an agreed read-only period.
The short version
Mirror Snowflake into OneLake first, repoint Power BI, then convert each domain’s pipelines and SQL to Fabric (T-SQL or Spark), replacing VARIANT logic, streams, tasks and Snowpark. Choose warehouse collation up front, re-create security on groups, reconcile on business keys, and retire Snowflake objects domain by domain, or keep both if coexistence serves you better.
Comparing the platforms first? See Snowflake vs Microsoft Fabric and Delta Lake vs Apache Iceberg. Browse all migration guides or use the platform chooser.
Sources
- Mirroring Snowflake in Microsoft Fabric, Microsoft Learn
- Migration Assistant for Fabric Data Warehouse, Microsoft Learn (supported sources)
- Data Warehouse collation, time travel and table clones, Microsoft Learn
- Use Iceberg tables with OneLake, Microsoft Learn
Further reading from other practitioners
Not sure where your own platform stands? Take the free 3-minute data platform scorecard, or see how we work on Snowflake. Unfamiliar terms are explained in the data engineering glossary.