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 SnowConvert AI, 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 19 objects in ~4s 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 ~12 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, claims all 16 wave-1 objects (3 schemas, 11 tables, 1 ETL, 1 function), and walks them through their tasks.

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, Cortex Code:

1. Generates .scai/settings/DataExchangeWorkerConfig.toml from the source connection credentials.
2. Starts the local Data Exchange Worker:

3. Generates the migration workflow YAML at artifacts/data_migration/workflows/where-<hash>.yaml covering all 11 tables (Full / Native, partitioned by primary key).
4. Runs the migration with the local orchestrator:

The workflow finishes in ~2.3 minutes:

Cortex Code runs:

This produces artifacts/tastybytesdb/tastybytes/function/fn_formatcustomername/test/fn_FormatCustomerName.yml with the step-based template. Because this is a simple 1-parameter scalar UDF that looks up a customer row and returns "LASTNAME, Firstname", Cortex Code fills test_cases: directly with 13 hand-crafted rows covering valid IDs, the lower boundary, and the not-found path:

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 confirms each branch:

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

Result:

All 13 cases match SQL Server output exactly on the first run.

Cortex Code now claims the remaining 3 wave-1 objects (1 procedure, 2 views) and walks them through deploy/test/fix.

The vw_CustomerOrderHistory view deploys cleanly. vw_TopSellingItems fails: SnowConvert flagged the SQL Server CROSS APPLY ... TOP 5 ORDER BY with SSC-EWI-TS0082 and emitted an unresolved !!!RESOLVE EWI!!! marker plus a non-lateral LEFT OUTER JOIN, which won't run in Snowflake.

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

Redeploy. Both views return 25 rows, matching the source.

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):

Cortex Code fills test_cases: with 6 rows covering:

Deploy the procedure:

Capture baselines and run validation:

Inspect the validation results from the framework's stored output:

All 6 cases come back as PASS:

The procedure produces identical post-run 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 19 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 CROSS APPLY view rewritten with window functions), migrated 185 rows of 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.