mssql-to-snowflake-dbt-migration

mssql-to-snowflake-dbt-migration

Pick architecture → inventory source → convert → confirm → build to isolated schema → parity → verify → dashboard.

When NOT to use this skill

• Source is PostgreSQL / MySQL / Oracle / BigQuery (not T-SQL) → migrating-sql-to-dbt.
• Target is not Snowflake → migrating-sql-to-dbt + the appropriate warehouse skills.
• Just one T-SQL snippet with no isolated-deploy or parity requirement → migrating-sql-to-dbt.
• Enhancing an existing dbt model → dbt-model-enhancement.

Prerequisites

command -v altimate-code     # strongly preferred — carries MS SQL + Snowflake adapters and data-parity
command -v dbt               # required for the deploy phase
command -v git               # required

Must have:

• A dbt project configured for Snowflake (dbt_project.yml + a working profiles.yml or env-var profile).
• A Snowflake role with CREATE SCHEMA on the target database and USAGE on a warehouse. The skill writes to an isolated schema, not prod.
• A dedicated migration target in profiles.yml with a schema: override (see Phase 5 Method 1). The skill refuses to deploy without it — the --vars '{target_schema: ...}' trick is a no-op on standard projects.
• dbt_utils package installed (packages.yml + dbt deps) — the rewrite table recommends dbt_utils.generate_surrogate_key as the NULL-safe way to port T-SQL IDENTITY columns. If dbt_utils isn't installed, add it before Phase 2 or avoid the IDENTITY mapping.
• Source access via one of:
  • altimate-code configured with an MS SQL connection (altimate-code providers), OR
  • A directory of .sql dumps already in the repo.
• For parity: source rows must be readable from Snowflake — either replicated (Fivetran/Airbyte/pre-existing bronze), or landable via stage + COPY INTO. Phase 6 hard-stops if neither is true.

If altimate-code is unavailable AND no dump exists, stop and tell the user.

If dbt is not installed, Phase 5 cannot run — stop and tell the user.