Snowflake AIM unifies the proven capabilities of SnowConvert AI, Snowpark Migration Accelerator, and Datometry into a single AI-powered platform for assessing, modernizing, and migrating enterprise data and code workloads to Snowflake. Designed to reduce the complexity, risk, and operational overhead traditionally associated with large-scale migrations, Snowflake AIM enables organizations to define their target state while the platform orchestrates the migration process end to end. From analyzing Spark code and converting APIs to Snowpark, to modernizing warehouses, tables, views, ETL pipelines, reporting assets, and stored procedures across major platforms, Snowflake AIM combines intelligent assessment, automated code conversion, dependency mapping, orchestration, and virtualization into a unified migration experience. By eliminating the need to rebuild workloads from scratch or maintain parallel legacy environments, Snowflake AIM dramatically accelerates modernization timelines while minimizing disruption to ongoing business operations.

Through this guide you will learn how to do an end-to-end migration of a Microsoft SQL Server environment with SSIS to Snowflake using Snowflake AIM, the Cortex Code CLI, and the Snowflake CLI. This guide walks you through project setup, extracting your source DDLs, converting them, leveraging AI to fix remaining issues in the converted code, deploying objects, migrating historical data with a locally-run orchestrator + worker, and finally replatforming your SSIS ETL pipelines into a Snowflake task graph plus a Snowflake-native dbt project.

The lab is driven entirely from a single Cortex Code session — at each step you tell the assistant what you want and the bundled snowflake-migration:migration skill orchestrates the underlying scai / snow / SQL calls.

By the end of this guide, you will learn to work with:

An end-to-end migration of a SQL Server database and an SSIS package to Snowflake, including: code conversion, hand-fixed deploy/test/fix loop, data migration using a locally-run Data Migration & Validation orchestrator + worker, and deployment of an SSIS-derived Snowflake task graph that calls a Snowflake-native dbt project.

All of the source scripts, the SSIS package, and the SQL used in this quickstart live in the [sfguide-scai-e2e-ssis-migration](https://github.com/Snowflake-Labs/sfguide-scai-e2e-ssis-migration) repository. Clone it to your local machine before continuing:

The repository contains:

Later steps reference these paths (for example, when Cortex Code asks for the filesystem path to your SSIS folder, you will point it at this repository's etl/ directory).

1. In the SQL Server instance you will be using for this quickstart, run the sourcedb/00_ddl.sql script to create the database, schema, and DDLs that we will be converting.
2. Once the DDLs have been deployed successfully, run the sourcedb/01_data.sql script to insert sample data into the tables of the TastyBytes database.

In your Snowflake account, run the snowflake/init.sql script to create the initial database (TASTYBYTESDB) and warehouse (XSMALL_WH) we will deploy into. Because this lab runs the data-migration orchestrator and worker locally, you do not need to create an SPCS compute pool.

To enable the Snowflake CLI and SnowConvert AI to run against our Snowflake account, we need to add the connection details to the config.toml file used by both CLIs. Follow the steps in this guide to set up your config.toml with your connection details.

Test the connection:

In this quickstart we use a Snowflake connection named **migrations_sc** configured with warehouse XSMALL_WH, database TASTYBYTESDB, schema TASTYBYTES, and role ACCOUNTADMIN.

Run the following command to register your SQL Server connection with SnowConvert AI so it can later extract your code and migrate your data:

Test it:

You should see a Status: Success row in the output. We use a SQL Server connection named **tastybytesdb** throughout this quickstart.

Rather than running each scai command manually, we drive the entire migration from a single Cortex Code session. Cortex Code ships with a snowflake-migration:migration skill that orchestrates project initialization, source extraction, conversion, assessment, deployment, data migration, and ETL replatforming through a guided conversation.

The sections below show the exact prompts you'll send during the lab and the answers we selected for this quickstart, in order.

From the directory where you want to host the migration project (for example, an existing migrations_hol_summit/ folder), launch Cortex Code:

Tell the assistant exactly what you want, including how the data infrastructure should be deployed and what to skip:

This prompt does four important things in one shot:

1. Pins the SQL Server source to the existing tastybytesdb connection.
2. Asks for local data-migration infrastructure (orchestrator + worker on the host machine — no SPCS / compute pool needed).
3. Tells Cortex Code to skip ETL stabilization.
4. Tells Cortex Code to skip data validation after the data lands and jump straight to the deploy/test/fix loop.

The skill prints:

It then walks through a series of one-line prompts. Answer them as below.

Cortex Code asks four short questions before it touches any code:

It then confirms the active Snowflake connection and asks for the target database:

Cortex Code verifies that TASTYBYTESDB exists, picks it as the deploy target, and writes .scai/config/project.local.yml for the project.

Because the kickoff prompt named tastybytesdb, Cortex Code goes straight to the SQL Server connection list, selects tastybytesdb, and runs a connection test that returns connection_test: ok.

Cortex Code routes into the register-code-units sub-skill and runs:

For TastyBytes the extraction reports 18 objects in ~1.5s with no failures:

SQL files land under sqlserver-migration/source/tastybytesdb/<schema>/<object_type>/.

The convert sub-skill runs next. When asked whether you have ETL code to include, point it at the cloned repo's etl/ directory:

Cortex Code calls:

The conversion completes in ~10 s and reports:

Converted artifacts land in:

Cortex Code drives scai assessment and asks four short questions to scope the run. For this lab pick the lean defaults:

Cortex Code then dispatches three sub-skills in parallel — waves-generator, object-exclusion-detection, and etl-assessment — and finally renders a multi-tab HTML report at sqlserver-migration/assessment/multi_report.html.

The result for TastyBytes:

Open the report to review:

At this point Phase 1 (setup + assessment) is complete.

Per the kickoff prompt, Cortex Code now goes straight into the deploy/test/fix loop. It asks two questions to configure the testing framework:

Cortex Code then auto-deploys the VALIDATION schema and claims the 14 deployable wave-1 objects (3 schemas, 11 tables) — leaving the SSIS/ETL object unclaimed per the skip ETL stabilization instruction — and walks them through their tasks. The view, function, and procedure are claimed in a later batch once their dependency tables are migrated.

Cortex Code calls the deploy MCP tool for the 3 schemas (TastyBytes, dbo, etl_results). All 3 succeed.

Cortex Code deploys all 11 tables (Customer, FoodTruck, OrderDetail, Country, Inventory, OrderHeader, City, Menu, etl_logs, EmployeeShift, MenuItem). All 11 succeed.

Because we asked for local data-migration infrastructure (no SPCS / compute pool), Cortex Code:

1. Verifies the Microsoft ODBC Driver for SQL Server is installed (required by the Data Exchange Worker).
2. Generates .scai/settings/DataExchangeWorkerConfig.toml from the source connection credentials.
3. Generates the migration workflow YAML at artifacts/data_migration/workflows/where-<hash>.yaml covering all 11 tables (Full / Native, each partitioned by its integer primary key — an empty columnNamesToPartitionBy would finish the workflow without moving any data, so a key column per table is required).
4. Runs the migration with a local orchestrator and worker in a single command. The local path uses create-workflow with --start-orchestrator --start-worker (not scai data migrate start, which targets the SPCS/cloud orchestrator):

The workflow finishes in a few minutes with every partition loaded:

Because we answered Yes to the query-log question, Cortex Code runs scai test seed with --execution-log so the cases are hydrated from real captured calls:

This produces artifacts/tastybytesdb/tastybytes/function/fn_formatcustomername/test/fn_FormatCustomerName.yml. The seed finds 6 executions in the log and populates test_cases: with the 3 distinct CustomerID values that were actually called — so no AI swarm fill is needed:

SnowConvert produced a clean Snowflake SQL UDF for this scalar function — no manual rewrites required. The converted file at sqlserver-migration/snowflake/tastybytesdb/tastybytes/function/fn_formatcustomername.sql deploys directly:

A quick smoke test against the seeded customer IDs:

Now that the function is deployed, Cortex Code captures the source baselines and runs the cross-DB test:

Result:

All 3 cases match SQL Server output exactly (data_match) on the first run.

Cortex Code now claims the remaining wave-1 objects — the view and the procedure — and walks them through deploy/test/fix.

vw_TopSellingItems fails to deploy with a SQL compilation error (unexpected '!'). The SQL Server view uses SELECT TOP 1 PERCENT ... ORDER BY ... in two subqueries combined with UNION. SnowConvert flagged SSC-EWI-0040 (the TOP PERCENT clause is not supported in Snowflake) and left unresolved !!!RESOLVE EWI!!! marker text in the file, alongside a leading USE DATABASE TastyBytesDB; that points at the source database. The fix is to delete the marker text and the USE DATABASE line, fully qualify the view name with the target database, and rewrite each TOP 1 PERCENT ... ORDER BY <expr> DESC as a Snowflake QUALIFY ROW_NUMBER() OVER (ORDER BY <expr> DESC) <= CEIL(0.01 * COUNT(*) OVER ()) — which preserves SQL Server's ceiling semantics for the percentage of rows returned.

Replace the file at sqlserver-migration/snowflake/tastybytesdb/tastybytes/view/vw_topsellingitems.sql with:

Redeploy. Cortex Code then validates the view against the source by comparing row counts and a 10-row spot check — both sides return 2 rows with matching values (the only differences are cosmetic: Snowflake folds identifiers to uppercase and shows trailing decimal zeros).

Cortex Code seeds tests for sp_UpdateInventory (a procedure that updates Inventory rows for a given truck, with an Override flag controlling absolute-set vs. increment behavior, and an early return when TruckID IS NULL). It returns no result set, so we seed from the query log:

The seed populates 3 test_cases: of [TruckID, StockCount, Override]. Because this proc is side-effect-only DML, the default seeded YAML (which only compares the empty return) would pass trivially. Cortex Code edits the YAML to mark the CALL step validate: false and add a post-condition step that compares the affected Inventory row on both source and target, plus the modifies_data / affected_tables hints for delta capture:

Deploy the procedure:

Re-capture baselines (now that the YAML reads the affected table) and run validation:

All 3 cases come back as PASS with result_and_delta_match — both the post-condition row and the captured table delta match SQL Server:

The procedure produces identical post-run Inventory state on SQL Server and Snowflake across every test case, confirming the converted Snowflake Scripting body matches the original T-SQL semantics exactly.

A quick sanity check against INFORMATION_SCHEMA:

Expected:

Plus the TASTYBYTESDB.ETL_RESULTS.ETL_LOGS helper table in etl_results.

The data was already migrated in Phase 2 / Step 3. Confirm row counts on Snowflake:

With the database workload migrated, the last phase is to deploy the SSIS-derived artifacts. SnowConvert produced two things under sqlserver-migration/snowflake/_etl/daily_sales_agg/:

Tell Cortex Code:

Cortex Code loads the dbt-projects-on-snowflake skill and works through three high-level steps before triggering the run:

1. Patch the dbt project files. SnowConvert wrote dbt_project.yml, profiles.yml, and models/sources.yml with placeholders (YOUR_PROJECT_NAME, YOUR_PROFILE_NAME, YOUR_DB, YOUR_SCHEMA). Cortex Code rewrites them with the concrete project name df_load_daily_sales, target dev, role ACCOUNTADMIN, warehouse XSMALL_WH, database TASTYBYTESDB, sources at TASTYBYTESDB.TASTYBYTES, and drops the account / user / password fields (dbt runs inside Snowflake, so those aren't needed).
2. Deploy the dbt project with snow dbt deploy:

snow dbt deploy honors the connection's default schema over --schema, so the project actually lands at **TASTYBYTESDB.TASTYBYTES.DF_LOAD_DAILY_SALES** (matching the connection's schema = "TASTYBYTES"). Cortex Code re-points the task graph at the actual location. 3. Deploy the 4-task graph and run it. Cortex Code rewrites daily_sales_agg.sql: every WAREHOUSE=DUMMY_WAREHOUSE becomes WAREHOUSE = XSMALL_WH, the root task gets WAREHOUSE = XSMALL_WH added, the INSERT INTO etl_results.etl_logs calls get fully qualified to TASTYBYTESDB.ETL_RESULTS.ETL_LOGS, and the EXECUTE DBT PROJECT call points at TASTYBYTESDB.TASTYBYTES.DF_LOAD_DAILY_SALES. Cortex Code applies the four CREATE OR REPLACE TASK statements, resumes the three child tasks, and triggers the root with EXECUTE TASK TASTYBYTESDB.PUBLIC.daily_sales_agg.

Once EXECUTE TASK is dispatched, Cortex Code polls TASK_HISTORY until all four tasks land at SUCCEEDED:

The EXECUTE DBT PROJECT call ran dbt build --target dev inside Snowflake: 2 staging views, 4 ephemeral intermediate models (inlined as CTEs and not visible in INFORMATION_SCHEMA.TABLES), and 1 incremental mart materialized as TASTYBYTESDB.PUBLIC.DAILYSALESAGG. The two _insert_*_log tasks wrote start/end markers to TASTYBYTESDB.ETL_RESULTS.ETL_LOGS, exactly the side-effect SnowConvert lifted from the original SSIS package.

Finally, Cortex Code shows the materialized mart:

22 rows, one per (TruckID, SaleDate) pair from completed orders, aggregating OrderCount, GrossRevenue, TotalTips, and ItemsSold per truck-day. A sample of the output:

Totals across the mart: 22 truck-day rows, 22 orders, $1,015.31 gross revenue, $139.50 tips, 39 items sold. Cross-checking against TASTYBYTESDB.ETL_RESULTS.ETL_LOGS shows the two markers pkg_daily_sales_aggregate start and pkg_daily_sales_aggregate end written one task apart, confirming the full task graph executed end-to-end.

At this point all four phases are complete:

Congratulations! You've taken a Microsoft SQL Server database and an SSIS pipeline all the way from source extraction to a fully deployed, populated, and running workload in Snowflake — driven end-to-end by the Cortex Code CLI and its snowflake-migration:migration skill, plus the snow dbt deploy workflow for the SnowConvert-generated dbt project.

You started from a blank project, set up local data-migration infrastructure (no SPCS / compute pool needed), registered 18 SQL Server objects and 1 SSIS package, converted them with SnowConvert AI, generated a deployment plan with a classified SSIS assessment, deployed every in-scope database object using a deploy/test/fix loop (hand-fixing 1 conversion artifact — a view whose SQL Server TOP 1 PERCENT clause was rewritten as a Snowflake QUALIFY ROW_NUMBER() ... <= CEIL(0.01 * COUNT(*) OVER ()) and whose unresolved SnowConvert EWI markers were removed), migrated the table data via the locally-run orchestrator + worker, and finally hand-patched and deployed both the SnowConvert-generated dbt project (snow dbt deploy) and the SnowConvert-generated Snowflake task graph (with XSMALL_WH per task), executing the full graph end-to-end on demand.