SQL Server to Snowflake Migration: What Actually Changes

SQL Server to Snowflake migrations are among the most common cloud data warehouse migrations — SQL Server's dominance in on-premises enterprise deployments means there is an enormous installed base of companies moving their analytical workloads to Snowflake as they adopt cloud infrastructure. The migration is rarely as simple as lifting and loading SQL code, and understanding where SQL Server and Snowflake differ is essential for planning realistic timelines and avoiding painful surprises.

What Actually Changes

The high-level differences that affect every migration:

**Snowflake is cloud-native; SQL Server is server-based.** SQL Server queries data from disk on a server you manage. Snowflake separates compute from storage — queries use virtual warehouses (compute clusters) that you can scale up, down, or suspend independently of storage. This changes how you think about performance tuning (no indexes, no statistics — Snowflake handles these automatically) and costs (you pay for compute only when queries are running).

**Different performance model.** SQL Server performance tuning relies heavily on indexes, query hints, execution plan analysis, and statistics management. Snowflake uses micro-partition pruning with clustering keys and metadata-driven optimisation. An SQL Server query that needed an index to be fast may run fast in Snowflake without any additional configuration — or may need a clustering key if it filters on a non-natural sort column.

**No stored procedures with T-SQL syntax.** SQL Server's stored procedures use T-SQL, which has many proprietary extensions. Snowflake supports JavaScript stored procedures and Snowflake Scripting (its own procedural SQL language), but T-SQL procedural code does not migrate directly. Complex stored procedures with cursors, EXEC statements, dynamic SQL, and TRY/CATCH blocks require substantial rewriting.

T-SQL Features That Do Not Exist in Snowflake

**TOP N syntax.** T-SQL uses SELECT TOP 100 * FROM table. Snowflake uses LIMIT 100 at the end of the query. Straightforward to fix but requires finding every TOP usage.

**NOLOCK hints.** SELECT * FROM orders WITH (NOLOCK) is a T-SQL pattern for reducing locking contention at the cost of dirty reads. Snowflake has no equivalent because it uses MVCC (multi-version concurrency control) — there is no locking on reads and no equivalent hint is needed. Remove NOLOCK hints entirely.

**ISNULL vs COALESCE.** SQL Server's ISNULL(column, default) is a two-argument null-replacement function. Snowflake uses COALESCE(column, default) for the same purpose. ISNULL also exists in Snowflake but as a boolean function (returns true if null). Renaming ISNULL to COALESCE in T-SQL context is straightforward but a required change.

**Date functions.** T-SQL uses GETDATE() for current timestamp; Snowflake uses CURRENT_TIMESTAMP() or SYSDATE(). DATEPART, DATEADD, and DATEDIFF have slightly different syntax in Snowflake. YEAR(), MONTH(), DAY() work in Snowflake. Date manipulation requires systematic review.

**STRING_SPLIT.** SQL Server 2016+ STRING_SPLIT function splits a string by delimiter and returns a table. Snowflake uses SPLIT_TO_TABLE for similar functionality.

**PIVOT and UNPIVOT.** SQL Server's PIVOT syntax differs from Snowflake's. Snowflake supports PIVOT but the syntax is different. Complex PIVOT queries require rewriting.

**Cross-database joins.** SQL Server allows joins between tables in different databases on the same server (database1.dbo.table1 JOIN database2.dbo.table2). Snowflake uses databases as logical separations but allows cross-database joins within the same account using fully qualified names (database1.schema1.table1 JOIN database2.schema2.table2). The concept is similar but the permission model differs.

**IDENTITY columns and sequences.** SQL Server's IDENTITY columns for auto-incrementing keys are replaced by Snowflake's AUTOINCREMENT or SEQUENCES. Functional equivalents exist but syntax differs.

**Cursors.** SQL Server cursors (for row-by-row processing in stored procedures) have no direct Snowflake equivalent. Cursor logic must be rewritten as set-based SQL or moved to application code.

Data Type Differences

**VARCHAR without length.** SQL Server's VARCHAR(MAX) has a Snowflake equivalent of VARCHAR (up to 16MB). Standard VARCHAR in SQL Server requires a length parameter; Snowflake VARCHAR defaults to 16MB without a length specified.

**DATETIME vs TIMESTAMP.** SQL Server DATETIME maps to Snowflake TIMESTAMP_NTZ (timestamp without timezone) for most analytical use cases. SQL Server DATETIMEOFFSET (with timezone) maps to Snowflake TIMESTAMP_TZ.

**BIT columns.** SQL Server BIT (boolean) maps to Snowflake BOOLEAN. Values stored as 0/1 in BIT columns may need handling in ETL as TRUE/FALSE.

**MONEY and SMALLMONEY.** SQL Server's monetary types have no direct Snowflake equivalent — use NUMERIC(38, 4) or DECIMAL as appropriate.

Migration Approach

**Assess and inventory first.** Before writing a single line of migration code, catalogue every SQL Server object that needs to migrate: tables, views, stored procedures, functions, jobs, and ETL processes that write to the database. Automated tools (SQL Server Migration Assessment, third-party tools like Ispirer) can do most of this inventory work.

**Migrate data first, logic second.** Load the data into Snowflake using whatever ETL tool is appropriate — ADF, Fivetran, custom JDBC exports — before addressing the query migration. Having the data available allows you to validate query output against SQL Server baselines.

**Automated SQL conversion tools.** Tools like Snowflake SnowConvert (previously Transposit) automate T-SQL to Snowflake SQL conversion, handling most dialect differences automatically. Automated conversion handles 60–80% of the work; the remaining 20–40% requires manual review for stored procedures, complex views, and application-specific patterns.

**Baseline comparison.** For every significant query or report, run both the SQL Server and Snowflake versions against equivalent data and compare results before declaring the migration complete. Automated result comparison tools (dbt audit_helper, custom diffing scripts) systematise this.

For cloud data warehouse migration including SQL Server to Snowflake, our data architecture consulting and cloud engineering practices manage full migration programmes — contact us to discuss your migration requirements.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.