Teradata to Snowflake migration: a practical guide

Teradata estates usually move to Snowflake for the same reasons: a renewal date that forces a decision, hardware at end of life, and analysts who want elastic compute instead of a fixed-size appliance. Snowflake’s SQL is close enough to Teradata’s that most code converts, which makes it tempting to treat the move as a translation exercise. The programs that run late are the ones that discover the behaviour differences in production.

This is the approach we recommend.

1. Inventory and retire before you convert

List every database object (tables, views, macros, stored procedures), every BTEQ, FastLoad, MultiLoad and TPT script, every scheduled job, and every consumer (BI reports, extracts, applications). Use DBQL query logs to see what is actually queried and by whom. In most estates a large share of objects has not been touched in months: archive those instead of migrating them.

2. Convert the code, then fix what conversion can’t

Conversion tooling handles the routine work. Plan explicitly for these differences:

Teradata	Snowflake	What to watch
NOT CASESPECIFIC columns and case-insensitive comparisons	Case-sensitive by default	Joins and filters on text can return fewer rows. Use collations or UPPER() deliberately.
SET tables (duplicate rows silently rejected)	Tables accept duplicates	Add deduplication where the business relied on it.
Primary and secondary indexes	No indexes; automatic pruning, optional clustering keys	Drop index logic; add clustering keys only where measured.
Volatile and global temporary tables	Temporary and transient tables	Usually a direct replacement.
Macros	Stored procedures or views	Converted automatically in most cases.
BTEQ scripts	SQL scripts run by Snowflake Tasks, dbt or your orchestrator	Error handling (.IF ERRORCODE) needs explicit handling.
FastLoad, MultiLoad, TPT	COPY INTO, Snowpipe	Stage files in cloud storage first.
QUALIFY, SAMPLE, date arithmetic	QUALIFY supported; other functions differ	Test every date calculation, especially month and period logic.

3. Design the target, not a copy of the source

Use the move to fix what Teradata forced on you. Separate virtual warehouses by workload (loading, transformation, BI, data science) so each can be sized and suspended on its own. Model transformations as code in dbt or Snowflake stored procedures, and set up role-based access control with masking policies from the start rather than re-creating database-level grants one by one.

4. Load history once, then keep it in sync

Export history in bulk to cloud storage and load it with COPY INTO. For the parallel-run period, keep Snowflake in sync with change data capture or by running the converted loads against the same source files.

5. Parallel run and reconcile

Run both platforms side by side by business domain. Compare row counts, sums of key measures and full row-level differences for finance and regulatory tables. Most differences trace back to the items in the table above. Cut over a domain once its comparisons have been clean for an agreed number of runs and its owner has signed off.

6. Decommission before the renewal

The saving in the business case only arrives when Teradata is switched off. Schedule waves backwards from the renewal date, and stop each Teradata job the day its domain cuts over.

The short version

Inventory with query logs, retire what nobody uses, convert with tooling, handle case sensitivity, SET tables and date logic deliberately, separate warehouses by workload, reconcile every table in a parallel run and switch off Teradata before the renewal.

Moving to Databricks instead? See our Teradata to Databricks migration plan, or browse all migration guides. For a fixed-price plan for your own estate, start with the Data Platform Assessment.