Migration
Netezza to Snowflake migration: a practical guide
How to migrate IBM Netezza to Snowflake: inventory, converting NZSQL and NZPLSQL, replacing distribution keys and zone maps, loading with COPY INTO, parallel runs and switching off the appliance.
Hemant Walchale
· 2 min read
IBM Netezza appliances ran a generation of fast, simple analytics. Many are now past end of support or due for an expensive refresh, which makes Snowflake (another fully managed, SQL-first platform) a natural successor. The SQL converts well; the effort is in procedures, load scripts and leaving the appliance’s physical design behind.
This is the approach we recommend.
1. Inventory what’s used
List databases, tables, views, NZPLSQL procedures, user-defined functions, nzsql and nzload scripts, scheduled jobs and consumers. Netezza’s query history shows which objects are actually read. Archive the rest instead of migrating it.
2. Convert, then handle the differences
| Netezza | Snowflake | What to watch |
|---|---|---|
DISTRIBUTE ON, ORGANIZE ON, zone maps |
Micro-partitions, optional clustering keys | Drop physical design; add clustering only where measured. |
GROOM, GENERATE STATISTICS |
Not needed | Remove from maintenance scripts. |
| NZPLSQL procedures | Snowflake Scripting (SQL) or JavaScript/Python procedures | Rewrite cursor-heavy logic as set-based SQL. |
nzload, external tables |
COPY INTO from cloud storage, Snowpipe |
Stage files in S3, ADLS or GCS first. |
nzsql scripts |
SQL run by Tasks, dbt or your orchestrator | Rebuild error handling explicitly. |
BYTEINT, NUMERIC, NCHAR types |
NUMBER, VARCHAR |
Check precision on money columns. |
| Netezza-specific functions | Snowflake equivalents | Test date and string functions one by one. |
Conversion tooling (Snowflake’s SnowConvert where it supports your source, or third-party converters) handles much of the DDL and SQL.
3. Design the target
Separate virtual warehouses for loading, transformation and BI so each can be sized and suspended on its own, set up role-based access with masking policies, and move transformation logic into version-controlled SQL (dbt or stored procedures).
4. Parallel run and cut over by domain
Load history once, keep Snowflake in sync, and compare every table (row counts, totals and row-level differences) before cutting a domain over. Domain owners sign off their own numbers.
5. Switch off the appliance
Plan waves back from the support or refresh date, and stop each Netezza job the day its domain moves.
The short version
Inventory from query history, archive what’s unused, convert SQL with tooling, rewrite NZPLSQL and load scripts, drop distribution and organizing keys, reconcile every table and switch off the appliance by domain.
Browse all migration guides, or estimate your effort with the migration estimator. For a fixed-price plan, see the Data Platform Assessment.
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.