Run A Warehouse Migration Your Own Team Can Finish

The Migration Quote Is High Because The Tooling Is Split Across Three Vendors

A platform lead is reading a quote for a Redshift to Snowflake migration. The project has 240 models, two semantic-layer YAMLs, and a long tail of stored procedures. The quote is six figures and three quarters. The team's internal answer would normally be a series of scripts: a SQL translator that works for 80 percent of the dialect surface, a parity tool that handles same-database diffs but not cross-database, and a connection layer that requires a credentials engineer to wire up. Three tools, two of them paid, none of them coherent. The team picks the services firm by default.

The migration is doable in-house. What is missing is one tool that handles translation, parity, and connectivity in the same agent session. That is the gap Altimate Code is built to close.

One Agent, Three Jobs: Translate, Validate, Diff

The Builder agent in Altimate Code handles a migration as a single workflow. From the Altimate Code migration guide, the per-model loop is concrete:

1. Read the source SQL.
2. Translate to the target dialect. Function-by-function over the AST: DATEADD(day, -7, x) → DATE_SUB(x, INTERVAL 7 DAY), IFF(cond, a, b) → IF(cond, a, b), TRY_TO_NUMBER(x) → SAFE_CAST(x AS NUMERIC), LATERAL FLATTEN(...) → UNNEST(...). The translator handles every case the parser handles, not just cases the model has seen.
3. Check lineage on both versions. Confirm the same column-level edges land in both the source and target output. A mismatch in lineage is the early signal that the translation lost information.
4. Validate against the target schema. Catch type-narrowing, missing identifier quoting, dialect-specific functions that need a manual mapping (VARIANT → STRUCT / JSON, STREAMS → CDC, TASKS → scheduled queries).

A 47-model project produces an honest output: "38/47 translated cleanly, 6 need manual review (VARIANT columns), 3 use Snowflake-specific features (STREAMS, TASKS)". The realistic first-pass rate is 70 to 90 percent depending on the source dialect's edge cases. The agent does not pretend to handle what it cannot; it ships the list of what it could not.

Twelve Warehouses, Including The Long Tail No General Agent Can Reach

Migration breaks when the agent cannot connect to the source or the target. A general coding agent (Claude Code, Cursor) treats the warehouse as a tab in a documentation page; it cannot install pyodbc, cannot manage credentials, and cannot run a pyodbc.connect() from cold. A real MSSQL to Snowflake task crashed on five bare attempts with zero working outputs, every attempt failing on connectivity.

Altimate Code ships the adapters. The data_diff tool covers twelve warehouses and any combination of them:

For tables beyond ~10M rows, partitioning into date, numeric, or categorical batches keeps the diff tractable. SQL Server and Microsoft Fabric carry six Azure AD auth flows out of the box (password, access token, service principal secret, MSI VM, MSI App Service, Default), and all Azure AD connections force TLS. The full warehouse list and the partitioning patterns are in the Altimate Code data parity guide. The long-tail warehouse that the services firm priced as a six-week add-on is in the matrix from day one.

A Real data_diff Call Against An MSSQL Source And A Snowflake Target

The headline shape, from the data parity guide:

Compare orders in mssql_prod with orders in snowflake_dw using id as the primary key.

The agent expands that into the actual workflow: list the warehouse connections, inspect both schemas, propose primary keys, flag audit and timestamp columns to exclude (updated_at, created_at, _fivetran_synced, _airbyte_emitted_at, anything with a NOW() default), confirm the choices, run a column profile first (cheap, no row scan), then run the row-level diff only on columns that diverged. The direct tool form is:

data_diff(
  source = "orders",
  target = "orders",
  source_warehouse = "mssql_prod",
  target_warehouse = "snowflake_dw",
  key_columns = ["id"],
  algorithm = "auto",
)

For tables larger than ~10M rows, add a partition column and a granularity (partition_column = "order_date", partition_granularity = "month") so the diff runs as independent month-sized batches. The output ships a per-partition breakdown of which months had differences, which is the artifact a migration lead actually wants for the post-cutover sign-off meeting. The diff is the proof; the proof is what closes the migration.

A Correctness Layer That Survives Audit, In Rust

What makes the parity claim defensible is the deterministic layer underneath. The same altimate_core Rust library that powers Altimate Code's column lineage runs the diff. 303 dedicated tests cover all dialect pairs the data parity matrix supports, and altimate_core.checkEquivalence proves two queries semantically identical by comparing parsed ASTs against the provided schema, with no live database in the loop. The correctness layer blog walks the engine in detail. The companion article on the deterministic correctness layer is the long-form for a platform lead who needs to defend the choice to legal or audit. The diff result is reproducible; the same input on the same schema produces the same output every time.

Here is one such migration end to end, a SQL Server data warehouse moving to Microsoft Fabric on dbt. The agent confirms the SQL diff is semantically identical before it builds anything, then works through the project checklist:

Every migrated table is diffed row for row against the original. Six of seven models come back byte-identical; the seventh differs only in decimal formatting, not in the underlying numbers:

The dashboard is the artifact a migration lead takes into the sign-off meeting: every stored procedure migrated, every test passing, every table validated, all in a 41-second build:

Auditors and future maintainers get a direct map from the old stored procedure to the new dbt model, with the logic changes called out line by line:

And the lineage graph shows exactly how data now flows from the raw source tables through staging into the finished dimension and fact tables:

A Migration The Team Can Finish, Not A Contract To Sign

Three pieces together turn a migration from a services-firm contract into a project a data team can run end to end. The Builder agent translates 70 to 90 percent of models on the first pass and ships an honest list of the rest. The data_diff tool covers twelve warehouses with auto, joindiff, hashdiff, profile, and cascade algorithms, and partitions large tables into independent batches. The connectivity layer ships the adapters and the credential registry the bare coding agents do not, which is the difference between a working pyodbc.connect() on turn one and five failed attempts. The companion article on parity diffs as the cross-warehouse migration tool covers the same data_diff from the parity-first angle. The migration becomes an in-house project; the savings are the line item the services quote was charging.

$ npm install -g @altimateai/altimate-code