Netezza to Snowflake migration tools and converters compared on what actually lands
Eleven ways to move IBM Netezza into Snowflake, judged on the rows that arrive. Snowflake's converter covers Netezza tables and views but not procedures, turns INTERVAL into text, and the usual CDC vendors say Netezza has no change log they can read. All of it is in the vendors' documentation.
The live demo needs no card, and Starter is $49 a month.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Vendor documentation read 8 October 2026
Which Netezza to Snowflake migration tool should you use?
Use SnowConvert for the tables and views, because it is Snowflake's own converter and it reads Netezza DDL. Budget the NZPLSQL procedures separately, since SnowConvert does not list them for Netezza. For data, unload history with external tables or nz_unload and load it with COPY, then keep Snowflake current with an incremental sync on a timestamp column. Fivetran, Qlik Replicate and AWS DMS do not read Netezza as a source.
This route sits under our data migration tools guide. If another IBM source is on the same program, the Db2 version of this decision, with its own DECFLOAT trap in Snowflake's converter, is on Db2 to Snowflake migration tools.
Eight documented behaviors that change your Netezza to Snowflake plan
Each row sets a tool's documentation against what IBM or Snowflake say about the same thing. Two rows come from Snowflake's own 2020 Netezza migration guide, which is still the most linked document on this route and is now contradicted by IBM on sizes and by its own type rules on time zones.
| Tool and setting | What the documentation says | Why it matters to a buyer | What we would ship |
|---|---|---|---|
| SnowConvert, Netezza scope | Platform table: Netezza, GA, "Tables, views". No source connection, data migration or AI code conversion. Redshift lists procedures and functions. | Teams expect the procedures in the output. For Netezza they are not there, and the NZPLSQL estate is the slowest part of the project. | Scope NZPLSQL separately |
| SnowConvert, TIMESPAN | TIMESPAN, the Netezza INTERVAL, "is not supported in Snowflake. VARCHAR is used instead." Warning SSC-EWI-0036. | A duration stored as text cannot be added to a timestamp or summed. Snowflake added interval types as a preview in November 2025. | NUMBER of microseconds |
| SnowConvert, ORGANIZE ON | Netezza CREATE TABLE reference: ORGANIZE ON sits under "Translation pending". DISTRIBUTE ON is removed. | ORGANIZE ON is how the big fact tables scanned fast. Results stay right, scan cost on large date ranges does not. | CLUSTER BY on large tables |
| Snowflake guide, TIMETZ | Snowflake's Netezza guide, Appendix C, maps TIME WITH TIME ZONE to TIMESTAMP_TZ. | IBM defines TIMETZ as a time of day with a GMT offset and no date. TIMESTAMP_TZ needs a date, and Snowflake TIME has no zone. | TIME plus offset column |
| Snowflake guide, NCHAR | The same appendix maps NCHAR to CHAR and gives NCHAR as "Max 64K". | IBM: NCHAR maximum 16,000 characters, padded with spaces. Snowflake CHAR is "not space-padded". Joins on padded codes stop matching. | VARCHAR, trimmed on load |
| Fivetran, Netezza source | You cannot connect Netezza as a source "because they have no change capture mechanism." | A plan that assumes log-based CDC fails at the first vendor call. Qlik lists Netezza only as a target, and DMS not at all. | Incremental on a timestamp |
| AWS SCT, target | Netezza 7.0.3 and higher is supported with Amazon Redshift as the target. Agents upload extracted data to S3. | Snowflake is not a target in SCT or in DMS, so the AWS toolchain does not carry this route without your own load step. | Leave AWS SCT out |
| Netezza constraints | IBM: Netezza "does not support constraint checking and referential integrity." | Years of loads were never checked for duplicate keys. Snowflake does not enforce them either, so duplicates move across unseen. | Count duplicates first |
The first row is the one that moves budgets. Snowflake's platform table gives Netezza a single entry under supported code conversion, "Tables, views", while the Redshift row next to it reads "Tables, views, stored procedures, functions". A Netezza estate with a few hundred NZPLSQL procedures therefore converts its schema in an afternoon and its logic by hand, and the NZPLSQL to Snowflake Scripting mapping is where that work starts. The sixth row decides the data path: with no change log to read, ongoing sync means a timestamp or key column, which is how change data capture tools behave on any source without a readable log.
Netezza types in Snowflake, and the wrong target a careless map picks
Netezza grew out of PostgreSQL and Snowflake speaks ANSI SQL, so INTEGER, BIGINT, DATE, BOOLEAN and most VARCHAR columns cross unchanged. DISTRIBUTE ON simply disappears, which SnowConvert's reference states plainly. These twelve are where the obvious choice, or the one a tool makes for you, is wrong.
| Netezza type | Right Snowflake target | Common wrong target |
|---|---|---|
| BYTEINT (INT1), -128 to 127 | BYTEINT, an alias of NUMBER(38,0) | BOOLEAN, if values beyond 0 and 1 exist |
| NUMERIC(p,s), p up to 38 | NUMBER(p,s) | NUMBER(38,0), which drops the cents |
| REAL, DOUBLE PRECISION | FLOAT | NUMBER with a guessed scale |
| CHAR(n), space padded | VARCHAR(n), trailing spaces trimmed | CHAR(n), expecting padding |
| NCHAR, NVARCHAR up to 16,000 | VARCHAR, length in characters | CHAR, with padding assumed |
| VARCHAR up to 64,000 | VARCHAR | VARCHAR(255) from a template |
| TIMESTAMP, microseconds | TIMESTAMP_NTZ(6) | TIMESTAMP_LTZ, shifted by session zone |
| TIME, 6 decimals | TIME(6) | VARCHAR from a CSV load |
| TIMETZ | TIME(6) plus an offset column | TIMESTAMP_TZ with an invented date |
| INTERVAL (TIMESPAN) | NUMBER of microseconds | VARCHAR, the converter default |
| VARBINARY, ST_GEOMETRY | BINARY, or GEOMETRY from WKB | VARCHAR of hex, never decoded |
| Primary and unique keys | Declared, plus a dedupe check | Trusted to reject duplicates |
The CHAR row causes the most confusing tickets. IBM documents that CHAR and NCHAR values "are padded to normal
length with spaces" and that Netezza ignores trailing spaces when it compares strings. Snowflake documents that
its CHAR "deviates from common CHAR semantics" because shorter strings are not padded. A customer code unloaded
as 'AB ' from a CHAR(5) column no longer equals 'AB' from a VARCHAR column, and
the join that matched every row on Netezza silently drops some. Trim on load and type the column VARCHAR. The
same logic applies to every other warehouse target, and the loading side is compared on
Snowflake ETL tools.
Netezza to Snowflake migration tools and converters compared
Billing units rather than price tags, because almost nobody on this list publishes one. Three rows are here to save you a sales call: AWS SCT, Fivetran and Qlik Replicate all appear in searches for this route, and none of them moves Netezza into Snowflake. The last column says where each tool is wrong for the job, including us.
| Tool | Approach | Best for | Billing unit | What to watch |
|---|---|---|---|---|
| SnowConvert AI | Snowflake's converter, Netezza tables and views | The DDL half of the project | Provided by Snowflake | No procedures, no data movement |
| phData SQLMorph | Translates directories of Netezza SQL to Snowflake | Large script estates | Toolkit plus services, quoted | Flags nzsql commands it cannot map |
| Intricity | Pattern-based conversion of ETL, scripts and procedures | Teams buying the migration as a service | Services engagement, quoted | Scope drives the bill |
| Nexla | Netezza exporter feeding Snowflake | Teams wanting a managed data flow | Subscription, quoted | Check how INTERVAL and TIMETZ land |
| CData Virtuality | IBM Netezza connector in a data virtualization layer | Querying both sides during cutover | Subscription by edition | A query layer, not a converter |
| nz_unload and COPY | Snowflake's documented file path, external tables or nz_unload | One-time history load | No license, your engineering time | You own every rerun and check |
| Netezza as a Service | IBM's managed NPS on AWS or Azure | Leaving the appliance but not Netezza | IBM subscription, quoted | Not a move to Snowflake |
| AWS SCT | Netezza schema and data agents | Netezza to Redshift only | No license fee | No Snowflake target |
| Fivetran | Managed connectors | Other sources into Snowflake | Monthly active rows | Documents no Netezza source |
| Qlik Replicate | Log-based replication | Writing into Netezza | Quoted license | Netezza listed as target only |
| Adapters | Declared column mapping, incremental sync, per-record logs | Keeping Snowflake current until cutover | Flat monthly from $49, no per-row overage fees | No NZPLSQL conversion |
The split to notice is code against data, and on this route the data half has fewer options than anywhere else. Snowflake Openflow has no Netezza connector, so after SnowConvert the first-party help ends. Most programs pair a translator or partner for the code with unload files for history and an incremental sync for the months of parallel running, and the budget for that pair is laid out in what a data migration really costs. For another warehouse-era source moving into the same target, compare Oracle to Snowflake migration tools.
Six numbers to know before you sign anything
Tables, views
Everything SnowConvert lists as convertible for Netezza. No stored procedures, no data migration, no source connection.
SnowConvert AI platform table, read 8 Oct 2026
0
Log-based CDC sources for Netezza across Fivetran, Qlik Replicate, AWS DMS and Snowflake Openflow. Fivetran says it has no change capture mechanism.
Vendor source lists, read 8 Oct 2026
30 Apr 2023
End of support for the PureData System for Analytics N3001-005. IBM says service extensions are not available.
IBM withdrawal notification
16,000 vs 64K
NCHAR maximum per IBM, against the "Max 64K" in Snowflake's 2020 Netezza guide. Size from IBM, not the guide.
IBM Netezza data types and Snowflake guide
100 MB to 1 GB
File size Snowflake recommends for unloaded Netezza data, so bulk loading can run in parallel.
Snowflake Netezza migration guide
13 vs 8
Decimal places for NUMERIC(10,2) divided by NUMERIC(10,2): IBM's guideline on Netezza against Snowflake's division rule.
IBM support note and Snowflake arithmetic operators
The last card is arithmetic from both vendors' published rules. IBM's guideline gives a division result scale of the larger of 6 and the dividend's scale plus the divisor's precision plus one, which is 13 for two NUMERIC(10,2) values. Snowflake adds six digits to the dividend's scale up to a ceiling of 12 and rounds, which is 8. Totals in dollars and cents are unaffected. Ratios, rates and allocations computed in SQL differ in the later digits, which is why reconciliation should compare them at Snowflake's scale.
Eight ways this migration goes wrong while every check stays green
Neither Netezza nor Snowflake enforces primary keys, and both accept almost anything a loader hands them. That makes this one of the quietest migrations to get wrong. Each row is a load that succeeds and means something different after it lands.
| The failure | What you see | What is actually happening |
|---|---|---|
| Reports stop refreshing | Conversion finished, no errors | SnowConvert converted tables and views only. The NZPLSQL procedures behind the nightly jobs were never in the output. |
| Durations become text | Columns load fine | INTERVAL columns landed as VARCHAR, so every query that adds them to a timestamp needs rewriting. |
| Joins lose rows | Row counts match | Padded CHAR codes from unload files meet trimmed values. Netezza ignored trailing spaces in comparisons, Snowflake does not. |
| Times get a fake date | Values look plausible | TIMETZ loaded into TIMESTAMP_TZ, so every time of day now carries a date nobody chose. |
| Duplicate rows appear | Totals slightly high | Netezza never enforced keys, and neither does Snowflake. Old duplicates and replayed batches both load. |
| Updates never arrive | Incremental sync healthy | The sync keys on a created date set by a now() default. New rows move, changed rows do not. |
| Ratios differ slightly | Reconciliation flags thousands of rows | Division keeps fewer decimal places in Snowflake than on Netezza, so ratios round differently. |
| Rows split in two | COPY rejects a few lines | Free text with newlines or the delimiter was unloaded without quoting, so one record became two. |
The sixth row deserves its own warning. IBM's advice for finding new Netezza rows is a column with a default of now(), because the hidden createxid column "does not map to any date or time". A default only fires on insert. If the incremental sync keys on that column, updated rows never move. Add an updated timestamp maintained by the load jobs before the parallel run starts, or sync the tables that change by key and full comparison.
Six steps that decide whether this migration works
Step 1
Inventory what Netezza runs
List tables, views, NZPLSQL procedures, UDFs and the nzsql shell scripts that call them. The procedure and script count, not the table count, is the schedule.
Step 2
Find the risky columns
Query the catalog for every INTERVAL, TIMETZ, NCHAR, CHAR, VARBINARY and ST_GEOMETRY column. Count duplicate keys on the large tables, since Netezza never checked them.
Step 3
Convert DDL, then fix it by hand
Run SnowConvert on the tables and views. Change INTERVAL from VARCHAR to a NUMBER, TIMETZ to TIME plus an offset, CHAR to VARCHAR, and add CLUSTER BY where ORGANIZE ON mattered.
Step 4
Unload history in parallel
External tables or nz_unload, quoted fields, files of 100 MB to 1 GB, staged in cloud storage and loaded with COPY. Keep each table's unload query so you can rerun it.
Step 5
Keep Snowflake current until cutover
With no change log to read, sync on an updated timestamp or a key, merge on the declared key, and dedupe in the same statement. Add an updated column where only a created one exists.
Step 6
Reconcile values, not counts
Compare SUM on numeric columns, MIN and MAX on timestamps and a hash of each key, and test ratios to the scale Snowflake keeps, not to Netezza's.
Step five is where a subscription earns its keep or does not. If the move is one weekend, files and COPY do it and you are done. If Netezza keeps feeding Snowflake for months while procedures and reports are rewritten, you need the same mapping running every few minutes, INTERVAL kept numeric, CHAR trimmed, a merge on the declared key and a log of every record, which is what a flat Adapters plan covers with no per-row overage fees.
Why US teams fund this project
Retiring an out-of-support appliance
N3001 support ended in April 2023 with no extensions, so the hardware in the data center is a risk the audit committee can see.
Retail and CPG analytics
Point-of-sale and loyalty history built up over a decade on Netezza moves to Snowflake so planners can share it with partners and suppliers.
Bank and insurer reporting
Regulatory and risk marts move while the source systems stay put, so Snowflake needs a steady, audited feed during a long parallel run.
Healthcare claims warehouses
Claims and eligibility data with long text fields and padded codes, where the CHAR rules decide whether member joins still match.
Consolidating two warehouses
An acquired Netezza estate is folded into the Snowflake account the parent company already runs, table by table.
Running both during the rewrite
NZPLSQL and report rewrites take a quarter or more, so Netezza keeps feeding Snowflake while each report is checked against the old one.
Five jobs where you should not pick us
A comparison page that never says the competition wins is an advert. These are the cases where something else on this page is the right answer.
- The project is mostly NZPLSQL procedures and ETL scripts. That is code conversion, and a translator plus a services partner is the right purchase. We do not convert procedural code.
- You only need a one-time copy over a weekend. Unload files, cloud storage and COPY do it, and a subscription adds nothing once the history is in.
- You are staying on Netezza and only leaving the appliance. IBM's managed Netezza service on AWS or Azure is the shorter move.
- The target is Amazon Redshift rather than Snowflake. AWS SCT supports Netezza to Redshift directly, with data extraction agents included.
- You need sub-minute latency from Netezza. Without a readable change log nobody delivers that cleanly, and our scheduled sync will not either.
Four questions to ask any vendor on this list
Question 01
How do you read changes from Netezza?
There is no change log for third parties. A straight answer names the column the sync keys on, how updates and deletes are caught, and what happens to a row changed twice between runs.
Question 02
What lands for INTERVAL and TIMETZ?
The fastest question on this route. A good answer is a numeric duration or a tested interval type, and a time of day with its offset kept, not text and not an invented date.
Question 03
Do you convert NZPLSQL, and how much?
Ask for the share of procedures that compile and pass tests, not the share of lines translated. REFTABLE procedures and AUTOCOMMIT blocks are the ones to ask about by name.
Question 04
What does the load month cost?
History loads once and is often the most expensive month in compute and in metered tools. Ask for the bill for the initial load and for a normal month after it.
Related Netezza and Snowflake guides
Convert Netezza NZPLSQL to Snowflake Scripting
The procedure half SnowConvert leaves to you, with a construct mapping and the behaviors that change results.
Db2 to Snowflake migration tools
IBM's other source into the same warehouse, where the converter's DECFLOAT default cannot hold 10.
Oracle to Snowflake migration tools
A source that does have an Openflow connector, which changes the data half entirely.
Postgres to Snowflake migration tools
Netezza's ancestor into the same target, with logical replication available where Netezza has none.
Change data capture tools
How log-based and column-based capture differ, and why Netezza only allows the second.
Data migration tools
The pillar above this page, covering one-time cutovers across every source and target.
Questions buyers ask about Netezza to Snowflake migration
- How do I migrate from Netezza to Snowflake?
- Convert the DDL with SnowConvert or another translator, then fix by hand what it leaves: NZPLSQL procedures, INTERVAL columns, TIMETZ and ORGANIZE ON. Unload each table with external tables or nz_unload into files of 100 MB to 1 GB, load them with COPY, keep Snowflake current until cutover, and reconcile on sums and hashes.
- What is the best Netezza to Snowflake migration tool?
- There is no single one, because no tool covers both halves. SnowConvert converts Netezza tables and views. Procedures need phData SQLMorph, a services partner or a rewrite. For data, the common path is unload files plus COPY for history, then an incremental sync on a timestamp column until the switch, since Netezza has no change log tools can read.
- Does SnowConvert support Netezza?
- Yes, with a narrow scope. Snowflake's platform table lists Netezza as generally available for tables and views, with no source connection, no data migration and no AI code conversion. Redshift, by contrast, includes stored procedures and functions. Plan NZPLSQL procedures as a separate piece of work rather than expecting them in the output.
- Can Fivetran replicate Netezza to Snowflake?
- No. Fivetran's database documentation says you cannot connect Netezza, Teradata or Vertica as sources "because they have no change capture mechanism." Qlik Replicate lists Netezza as a target, not a source, and AWS DMS does not list it as a source either. Ongoing sync from Netezza runs on a timestamp or key column instead.
- Can AWS SCT migrate Netezza to Snowflake?
- Not to Snowflake. AWS SCT supports Netezza 7.0.3 and higher with Amazon Redshift as the only target, and its data extraction agents upload to S3 for Redshift. AWS DMS has no Netezza source and no Snowflake target. On this route AWS tools only help if you build the S3 to Snowflake load yourself.
- How do I unload data from Netezza for Snowflake?
- Use external tables for single files or nz_unload for several files in parallel, as Snowflake's own Netezza guide recommends, and aim for files between 100 MB and 1 GB. CREATE EXTERNAL TABLE with REMOTESOURCE writes to a client machine. Quote fields, escape the delimiter and keep timestamps at six decimal places.
- How do I convert NZPLSQL stored procedures to Snowflake?
- Rewrite them in Snowflake Scripting, because SnowConvert does not list procedure conversion for Netezza. Most constructs map directly. The work is in REFTABLE result sets, BEGIN AUTOCOMMIT ON blocks, RAISE NOTICE logging, INTERVAL variables and division that rounds to a different scale. Our NZPLSQL guide has the full mapping.
- Is Netezza end of life?
- The appliances are. IBM ended support for the N2001-020 on 30 June 2019 and the N3001-005 on 30 April 2023, with no service extensions for the latter. Netezza itself continues as Netezza Performance Server on Cloud Pak for Data System and as a managed service on AWS and Azure.
- Does Snowflake support the Netezza INTERVAL data type?
- Partly. Snowflake added interval data types as a preview in release 9.35 in November 2025. SnowConvert's Netezza reference still maps TIMESPAN to VARCHAR with a conversion warning. Durations stored as text cannot be added to timestamps, so store microseconds in a NUMBER or test the interval types before relying on them.
- How much does a Netezza to Snowflake migration cost?
- Three bills. Snowflake compute for the load and the new workloads, conversion work for DDL and NZPLSQL, and whatever keeps Snowflake current during the cutover. Converters and partners quote by scope, Fivetran and Qlik do not read Netezza, and an ongoing sync on Adapters starts at $49 a month on a flat plan.
For the wider vendor landscape see the best data integration tools, and for how the ongoing feed is billed once history is loaded, the credit cost of each Snowflake merge cadence applies to a Netezza feed unchanged.
Keep Snowflake in step with Netezza until the appliance goes dark
Declare the columns once with INTERVAL kept numeric and CHAR trimmed, run the backfill, then let the same mapping sync incrementally with a merge on your key, retries and per-record logs. From $49 a month, with no per-row overage fees.
The live demo needs no card, and Starter is $49 a month.