Netezza to Snowflake migration: reconcile the business result.

What should be inventoried before a Netezza warehouse moves?

Inventory the source versions, SQL objects, stored procedures, extensions, load/export mechanisms, schedules and consumers. Keep source layout and distribution assumptions with the queries that rely on them. The assessment needs the full path to an accepted report or extract, not just a catalogue of tables.

Identify custom functions and procedures that a downstream calculation depends on. Record their input/output types, null behavior and meaningful edge cases before proposing a target expression or implementation. A similarly named target function should be compared on behavior rather than accepted from its name.

Include control files, rejects, reference data and any external system involved in publication. Use the warehouse migration playbook to turn that inventory into dependency waves. The Snowflake migration service remains the commercial owner for scoping the destination workload.

How can identical rows produce a different monetary total?

Specify numerical scale and the point at which rounding occurs. Rounding each line before aggregation and rounding only the aggregate are different calculations. Keep the consumer's accepted rule through extraction, transformation and reporting instead of assuming the same displayed decimal places imply the same result.

The illustrative fixture has three line amounts of 0.015. Under its stated decimal half-up rule, rounding each line to two places gives 0.02 + 0.02 + 0.02 = 0.06. Summing first gives 0.045, which rounds to 0.05. Both paths contain three rows; the difference comes from the calculation contract.

These are declared fixture results, not observations of either database's default rounding. IBM's nzpy documentation says numeric values are returned as strings. A migration path that uses that client therefore needs an explicit, loss-aware conversion into the selected exact numeric representation. Avoid an unexamined binary-floating-point step in a monetary comparison.

Which source assumptions need a target compatibility decision?

Keep semantics, physical workload behavior and orchestration as separate decisions. Each source object needs a target disposition and an acceptance case. Rewriting query syntax does not establish equivalent numeric behavior, concurrency or downstream publication.

The Snowflake platform guide supplies destination context. Preserve the source query and its workload evidence so that a target design can be justified against the question the consumer actually asks.

For each custom expression or extension, keep the actual typed arguments, expected values, null cases and caller grain before choosing a target implementation. Include the calculation order: casting, rounding and aggregation can be individually reasonable yet produce a different accepted result in another order. Retain unresolved features separately from emitted target candidates so that a translation report cannot hide a missing responsibility.

What should extraction and load comparisons preserve?

Record a consistent source reference, column representations, null markers, numeric scale, timestamp context and the accepted record population. Include the client or export mechanism actually used. Successful transport is one check; comparison of the resulting governed dataset is another.

The nzpy reference documents different returned Python representations for numeric, integer, floating-point, character and other values. Keep those boundaries explicit when building a comparison harness. A string containing an exact decimal and a binary float that happens to display the same digits are different intermediate representations.

Include a late correction, a missing field, an out-of-range value and a partial extraction in the scoped acceptance set. Define which records enter an exception path and whether that affects publication completeness. The data contracts guide provides the producer/consumer contract structure for those decisions.

Keep the value before and after each representation boundary: source expression, driver or file, target type and consumer calculation. The handoff map makes those references traceable to the publication offered to the consumer. The ETL vs ELT guide provides wider processing-boundary context; an exact-value comparison still needs the concrete source/transport/target path used by this workload.

Which checks determine the consumer switch?

Compare the accepted output with the candidate destination at the same business date, grain and access boundary. Retain component values and meaningful edge cases alongside totals. The consumer's use of a report, extract or model determines what must be correct and current before the reference changes.

The workflow below carries a consumer fixture through source extraction, typed comparison and the switch decision. Check the actual consuming identity and an explicit denied path. A privileged operator's correct query does not establish that the scheduled report can read the same permitted dataset.

Define the last accepted publication and the source history or files needed for a recovery. Include any already delivered extract or consumer action outside that recoverable boundary. The pipeline reliability guide explains why restored consumer state is a stronger acceptance target than a successful job rerun alone.

How should target performance and cost be evaluated?

Compare equivalent consumer queries on representative data, concurrency and refresh conditions. Record target configuration and the complete measurement window. Source distribution and zone-map assumptions inform the workload inventory, but they do not prescribe a direct Snowflake layout or performance outcome.

Include ingestion, retained storage, serving, parallel operation and the operating responsibility needed to keep the workload dependable. Separate isolated query observations from a full reporting wave. A candidate may change an individual query while leaving the business publication window constrained elsewhere.

Use the platform cost assessment to define attribution and exclusions. Preserve the correct calculation while evaluating performance; replacing 0.06 with 0.05 would not be a valid optimization of the fixture's declared contract.

Do not use the migration to silently change the accepted numerical contract while claiming a faster equivalent workload. First accept the result population and calculation, then measure comparable query mix, configuration and concurrency. The boundary pack below adds cancelling component values and an integer beyond exact binary64 representation; both demonstrate why an aggregate total or a successful load can miss a material difference.

What should the first Netezza migration brief contain?

Bring a consumer workload, source versions, SQL/extension inventory, extraction method, accepted output, business cutoff and numeric representation rules. Include one exact-decimal boundary case and the operational dependencies that produce and publish the result. These inputs make the assessment specific enough to evaluate.

Use synthetic monetary values and appropriately permitted object examples when sharing the brief. Keep unresolved dependencies visible and distinguish measured workload observations from estimates. A small reproducible fixture helps define acceptance; it cannot establish a full estate's duration or savings.

Compare the Teradata migration guide for row multiplicity and the Oracle migration guide for procedural and null/transport boundaries. Each source keeps its own compatibility evidence while feeding the established migration service.

Questions and trade-offs

Technical references

• IBM nzpy documentation: Netezza client data representations and transaction examples ↗
• dbt documentation: data tests for explicit model assertions ↗