Migration
IBM Netezza migration: NZSQL, NZPLSQL and load scripts to the cloud
Novuz converts IBM Netezza estates, the NZSQL, the NZPLSQL stored procedures, the nzsql and nzload scripts and the schedules around them, to Databricks (on AWS, Azure or Google Cloud), Microsoft Fabric, Snowflake, Google BigQuery, Apache Iceberg or Delta Lake. It converts by fixed, versioned rules, runs inside your own environment, and every converted object ships with a reconciliation report against the original on the same inputs.
Why now
Why are Netezza estates moving now?
IBM has withdrawn the PureData System for Analytics appliances that many Netezza estates were built on. Its withdrawal notice for machine type 3565-EG7 lists the transition to end-of-support services on 30 June 2020, so estates still on those appliances depend on extended or third-party support.
That is why most Netezza migrations are timed to a support or hardware renewal. The data is the easy part to move. The cost sits in the procedures, the scripts and the schedules, and that is what Novuz converts.
Coverage
What does Novuz convert in a Netezza estate?
Every object type below is converted by rule and reconciled. Final coverage for your estate is confirmed object by object in the assessment.
| Netezza object | What it becomes |
|---|---|
| Tables, with DISTRIBUTE ON and ORGANIZE ON keys | Target tables, with distribution and organize keys mapped to the target’s clustering or partitioning, agreed per table |
| Views and materialized views | Views, or materialized views where the target supports them |
| NZSQL queries and scripts run through nzsql | Target SQL, or PySpark where the logic needs it |
| NZPLSQL stored procedures, with exception blocks, loops and dynamic SQL | Stored procedures or notebooks on the target, with control flow and error handling preserved |
| User-defined functions and aggregates | SQL functions or Python functions; C++ user-defined code is flagged for engineer review |
| Sequences | Identity columns or sequences, depending on the target |
| nzload jobs, external tables and their control files | The target’s bulk load (COPY INTO, Auto Loader or a load job), with the same file layouts, delimiters and error limits |
| Shell wrappers and cron or enterprise-scheduler jobs | Workflows on the target with the same dependencies and parameters |
| Data in Netezza tables | Bulk and incremental data migration, checked with the same reconciliation |
Risks
What breaks in a Netezza migration?
These are the problems that change results or run time if nobody plans for them.
- Queries tuned to Netezza’s distribution. A join that was fast because both tables were distributed on the same key can slow down on a target that lays data out differently. The layout is agreed per table in the assessment.
- Keys that were never enforced. Netezza accepts primary and unique keys without enforcing them, so duplicates can already sit in the data. The converted load keeps any de-duplication explicit, and reconciliation shows where duplicates exist.
- NZPLSQL features with no direct equivalent, such as procedures that return a table (REFTABLE), variable arguments (VARARGS) and dynamic SQL built with EXECUTE IMMEDIATE. Each is mapped to an agreed pattern or listed for review.
- Casts and dates. The :: cast, implicit conversions, date arithmetic and functions such as NOW() and AGE() differ in detail between Netezza and each target.
- Maintenance commands. GROOM TABLE and GENERATE STATISTICS have no place on the target; they are removed or replaced with the target’s own maintenance.
- Load logic hidden in nzload control files and shell wrappers: file layouts, delimiters, error limits and the dates the wrapper passes in.
By target
How does Netezza map to each target?
The patterns are agreed in the assessment before anything is converted. Part of an estate can go to one target and part to another, from the same inventory.
| Netezza | Databricks (AWS, Azure or Google Cloud) | Microsoft Fabric | Snowflake | Google BigQuery | Apache Iceberg or Delta Lake |
|---|---|---|---|---|---|
| Tables and keys | Delta tables in Unity Catalog, with liquid clustering for organize keys | Fabric Warehouse or Lakehouse tables | Tables, with clustering keys where they pay | Partitioned and clustered tables | Open tables with partitioning agreed per table |
| NZPLSQL procedures | SQL scripting or PySpark notebooks | T-SQL stored procedures | Snowflake Scripting procedures | BigQuery stored procedures in GoogleSQL | Spark SQL or PySpark jobs |
| nzload and external tables | COPY INTO or Auto Loader | COPY INTO or pipelines | COPY INTO from a stage | LOAD DATA or load jobs from Cloud Storage | Spark loads into the open table |
| Schedules | Databricks Workflows | Fabric Data Factory pipelines | Snowflake tasks | The orchestrator agreed in the assessment | The orchestrator agreed in the assessment |
Other tools
What do the free Netezza converters do, and what do they leave?
Run the free tool on the SQL it handles well, then price the remainder.
- Google’s BigQuery Migration Service translates IBM Netezza SQL and NZPLSQL to GoogleSQL, with no preview label in Google’s documentation. Google states there is no charge to use the BigQuery Migration API; storage for the input and output files is billed normally.
- Snowflake’s SnowConvert AI converts Netezza SQL to Snowflake SQL and returns what it cannot convert as messages for a person to fix.
- Databricks Lakebridge lists Netezza among the sources of its BladeBridge converter. Its Switch converter, which uses a language model and is marked experimental, also lists Netezza.
- What they leave: the shell and nzload wrappers, the schedules, C++ user-defined code, and proof on your own inputs that each converted object gives the same answers.
How it runs
How does a Netezza migration with Novuz run?
- Score the estate with the free Logic Debt Scorecard, in about ten minutes.
- The $3,000 assessment counts every object in three business days, bands each one by complexity, lists dead code with the evidence, confirms coverage object by object and fixes the price.
- The First Domain takes one domain of up to 1,500 components and 25 TB to reconciled, cutover-ready output in your environment in 5 to 6 weeks, for $25,000 to $40,000, credited against the full estate.
- Every converted object runs against the original on the same inputs and gets a result: pass, fail or review, with each miss listed by line.
- Further domains follow the same method, and the Netezza appliance is switched off domain by domain rather than all at once.
Next question
Where to read next
Moving Netezza to Google Cloud? The Google Cloud page covers BigQuery and Databricks on Google Cloud for every source.
FAQ
Frequently asked questions
Can Novuz migrate Netezza to Databricks, Snowflake, Fabric or BigQuery?
Yes. Novuz converts Netezza NZSQL, NZPLSQL stored procedures, nzsql and nzload scripts and their schedules to Databricks on AWS, Azure or Google Cloud, Microsoft Fabric, Snowflake, Google BigQuery, Apache Iceberg or Delta Lake, with a reconciliation report for every object. Coverage for your estate is confirmed in the assessment.
Does Novuz convert NZPLSQL stored procedures?
Yes. Procedures, including exception handling, loops and dynamic SQL, are converted by rule to the target’s procedural language or to notebooks. Features with no direct equivalent, such as procedures that return a table, are mapped to a pattern agreed in the assessment or listed for review, and every procedure is reconciled on the same inputs.
What happens to DISTRIBUTE ON and ORGANIZE ON?
They tell Netezza how to lay out data on its hardware; they are not business logic. Novuz maps them to the target’s clustering, partitioning or distribution, agreed per table in the assessment, so the results stay the same and run time is tuned for the new platform.
Is Netezza end of life?
IBM has withdrawn the PureData System for Analytics appliances: its notice for machine type 3565-EG7 lists the transition to end-of-support services on 30 June 2020. IBM’s current Netezza product is Netezza Performance Server. Check your own model and contract with IBM or your support provider.
Is the free BigQuery translator enough for Netezza?
It can be for plain SQL. Google’s BigQuery Migration Service translates Netezza SQL and NZPLSQL and reports what it could not translate. It does not rebuild the nzload wrappers or the schedules, and it does not prove each object on your own inputs. Many teams run it first and bring the remainder to Novuz.
Does our Netezza code or data leave our network?
No. Novuz runs as a Docker container or VM inside your own environment, next to the target. The code and the data stay where they are, and no outbound connection is required.
- 1 Vendor facts on this page come from each vendor’s own documentation, checked 14 November 2026.
Sources and further reading
- IBM, PureData System for Analytics (3565-EG7) withdrawal notification
- Google Cloud, Enable SQL translations: supported SQL dialects for BigQuery Migration Service
- Google Cloud, Introduction to BigQuery migration
- Snowflake, SnowConvert AI frequently asked questions
- Databricks Labs, Lakebridge: BladeBridge overview
- Databricks Labs, Lakebridge: choosing the right tools
Written by Ted Ghose, Co-founder and CTO, Novuz
Last reviewed:
Find out what your logic debt is costing you.
Every object counted, lineage, dead code and a fixed price in three business days. $3,000, credited.
Not sure which door? The scorecard takes ten minutes and tells you.