Your DataStage logic. A path to Snowflake.

Use your existing job designs to start a practical migration to Snowflake. Inspect the source, review translated logic and plan the target environment together.

Carry forward the business rules

Begin with the source stage graph and column derivations. Identify joins, lookups, filters and calculations that define the result. Capture expected behaviour for unmatched records, duplicate keys and rejected rows before rewriting it.

Choose an execution shape

Sql and snowpark transformations provide a starting point for the target design. Snowpark Python lets you express transformations through DataFrames that execute processing in Snowflake.

PipelineX generates target code for engineering review. Inspect the stage mappings, function translations and conversion findings for each job, then configure its connections and runtime for the intended environment.

Make it operational

Agree the warehouse, database, schema and execution role. Decide how transformations are orchestrated and how each target table is written.

Keep environment-specific settings separate from transformation logic. Check permissions, failure handling, rerun behaviour and monitoring with the team that will operate the workload.

Compare the result

Run source and target against controlled inputs. Compare schemas, business keys, record counts, nulls, duplicate behaviour and important aggregates. Investigate record-level differences before accepting the migration.

Test edge cases deliberately: an unmatched lookup, an empty feed, a duplicate join key and a value near a decimal or date boundary.

Continue from here

DataStage and Snowflake: what changesFunction mapping referenceSnowpark Python documentationDiscuss your target