Azure Synapse to Snowflake migration: dedicated pools, T-SQL and the collation trap

Azure Synapse dedicated SQL pools often move to Snowflake when teams want to stop managing distributions, pause-and-resume cycles and fixed DWU sizes, while staying on Azure. Snowflake runs on Azure, so data can move through ADLS in the same region, and Power BI keeps working through Snowflake’s connector.

This is the approach we recommend.

1. Inventory

List dedicated pool schemas, tables, views, stored procedures, workload groups, serverless SQL views over the lake, Synapse Spark notebooks, Synapse or Azure Data Factory pipelines, and the Power BI datasets and other consumers that read them. Query history shows what is actually used; retire the rest.

2. Map Synapse to Snowflake

Synapse	Snowflake	What to watch
Dedicated SQL pool (DWUs)	Virtual warehouses sized per workload	Separate loading, transformation and BI warehouses with auto-suspend.
DISTRIBUTION = HASH / ROUND_ROBIN / REPLICATE	None (automatic micro-partitions)	Drop from DDL.
Clustered columnstore and other indexes	None; optional clustering keys	Drop index logic.
Case-insensitive collation (common)	Case-sensitive by default	Joins and filters on text change.
Workload groups and classifiers	Separate warehouses, resource monitors	Isolate workloads by warehouse instead.
T-SQL procedures	Snowflake Scripting (via SnowConvert)	Rewrite error handling and dynamic SQL.
GETDATE(), ISNULL()	CURRENT_TIMESTAMP(), IFNULL() or COALESCE()	Many small function changes; tooling handles most.
PolyBase, COPY INTO from ADLS	External stage on ADLS, COPY INTO, Snowpipe	Use a storage integration, not keys.
Serverless SQL views over the lake	External tables or Iceberg tables	Or load the data.
Synapse Spark	Snowpark, or keep Spark elsewhere	Port PySpark logic case by case.
Synapse or ADF pipelines	ADF with the Snowflake connector, or dbt with tasks	Keep ADF for orchestration if it works.

3. Move the data through ADLS

1. Export dedicated pool tables to Parquet in ADLS Gen2 with CREATE EXTERNAL TABLE AS SELECT (CETAS).
2. Create a Snowflake storage integration and external stage on that container.
3. Load with COPY INTO, then keep changes flowing during the parallel run with incremental exports, Snowpipe or a replication tool.

Keep the export and the Snowflake account in the same Azure region to avoid egress cost and delay.

4. Convert the code

Run SnowConvert on the DDL, views and procedures. Remove distribution and index clauses, fix the functions it flags, and rewrite procedures that depend on dynamic SQL or temp-table patterns. Many teams move transformation logic into dbt models at this point rather than carrying procedures forward.

5. Reconcile, repoint and pause pools

Compare every table by domain on row counts, totals and row-level differences matched on business keys; collation and timestamp precision explain most mismatches. Repoint Power BI with Snowflake’s native connector, test refresh times and gateway settings, then pause and finally delete the dedicated pools domain by domain.

The short version

Export dedicated pool tables to Parquet in ADLS, load with a storage integration and COPY INTO, convert T-SQL with SnowConvert, drop distributions and indexes, fix collation on text keys, replace workload groups with separate warehouses, reconcile on business keys and pause pools as each domain cuts over.

Staying in the Microsoft ecosystem? See Azure Synapse to Microsoft Fabric or Azure Synapse to Databricks. Browse all migration guides or compare platforms with the platform chooser.

Sources

• SnowConvert overview, Snowflake documentation (supported sources include Azure Synapse)
• CREATE STORAGE INTEGRATION and COPY INTO table, Snowflake SQL reference
• CETAS with Synapse SQL, Microsoft Learn