US Health Payer Converts 2,400 Alteryx Workflows to DBT on Snowflake — 1,860 Models, 540 Snowpark Jobs, Git as the Contract

Executive Summary

A US health payer had already bought Snowflake. Medical economics, provider network, membership, and pharmacy still lived in Alteryx Server: 2,400 workflows, 1.9 million lines of tool XML and formulas, 310 macros, Gallery schedules nobody could draw. The platform team’s requirement was not “more Snowpark.” It was DBT — models in Git, ref() as the DAG, tests in CI, exposures for the actuarial workbooks that actually get signed. MigryX classified each workflow: SQL-shaped graphs became DBT models (1,860). Iterative macros, multi-file spatial, and row machines became Snowpark called from a DBT Python model or a Task (540). Eleven months. Gallery is off. Three-year license gap: $4.8 million.

Client Overview

Payer analytics is Excel downstream of Alteryx. Actuaries and medical economists built 2,400 workflows because Designer was faster than a ticket to EDW. Snowflake was the new warehouse. Without DBT, the same people would have rebuilt Gallery as 2,400 unnamed worksheets in a schema called SANDBOX. That is how the last “migration” died in 2023.

This program is distinct from a Snowpark-only Alteryx conversion: the artifact the bank of analysts will maintain is a DBT project, not a Python repo they will never open.

Business Challenge

• Most Alteryx is SQL wearing a canvas. Join / Filter / Formula / Summarize is a DBT model. Emitting Snowpark for those 1,860 would have been the expensive, unreadable choice.
• Macros are not Jinja. 310 Alteryx macros. The ones that were parameterized SQL became DBT macros. The ones that looped files or called R became Snowpark. Pretending they are the same construct is how you get 400-line Jinja nobody can test.
• Gallery is not a DAG. 2,400 schedules, 180 of them overlapping the same claim extract. DBT ref() plus a documented source freshness test replaced “who ran what at 2 a.m.”
• PHI. HIPAA. Dynamic masks in Snowflake, not a Designer file on a laptop with an ODBC password in the workflow.
• LOC is not COBOL. 1.9M is tool XML + formulas, counted once per macro. We do not count .yxmd packaging as poetry.

The MigryX Approach

The classifier is the architecture. Each workflow’s tool graph was scored: if every node had a SQL equivalent and no iterative macro, emit models/<domain>/<name>.sql with ref() / source() from the Alteryx input tools. Schema.yml tests were generated from Alteryx Auto Field + known grain (claim_id, member_id, npi). That is why 1,860 models shipped with unique/not_null tests on day one — not because someone wrote them by hand.

The 540 remaining jobs: batch macros that explode a file list, a handful of spatial drive-time tools, and R predictive. Those became Snowpark Python with a thin DBT Python model or a Snowflake Task that DBT exposures point at. Actuaries still see one lineage graph.

dbt Cloud runs the project against Snowflake. Dev/stage/prod are three databases, not three Galleries. The 180 overlapping extracts collapsed to 22 src_ models. That collapse is in the PR history.

Target Architecture

Alteryx Gallery → MigryX → DBT Core/Cloud on Snowflake (Snowpark only when SQL is a lie)

Alteryx estate

Designer2,400 .yxmd

Server / Gallery310 macros

Schedules180 overlapping extracts

→

MigryX

dbt emit1,860 SQL models

Snowpark emit540 non-SQL

→

Snowflake + DBT

dbt CloudGit, CI, slim CI

Virtual WHDev / stage / prod DBs

SnowparkMacros / spatial / R

DDM + RLSPHI columns

GitPR = change control

schema.ymlGrain tests from tools

dbt is the contract. Snowpark is the exception list. If a workflow could be a SELECT, it is a .sql file. That list is in the repo, not in a slide.

Estate Inventory and Cutover Waves

1,860 + 540 = 2,400. The 200 “shared macros / loops” on Snowpark are why we did not promise 100% dbt. Finance close dual-ran two month-ends.

Results

"If you give a payer’s economists Snowpark they will ask IT to run it. If you give them a DBT model with a failing unique test on claim_id, they will fix the grain. That was the whole requirement."

— VP of Analytics Engineering, US health payer