SnowConvert AI CLI (scai) Command Reference¶

CLI tool for accelerated database migration to Snowflake.

Global Options¶

JSON Output¶

When –json is present, the CLI writes a single JSON document to stdout at the end of the command (envelope with success, warnings, errors, and an optional result object). Human-oriented tables and markup are suppressed for commands that implement JSON mode.

Commands with structured result:

• scai code extract

• scai code convert

• scai code deploy

• scai code add

• scai code resync

• scai code find

• scai query

• scai code find always sets the envelope result payload (items, total, truncated); when –json is not used, the no-op envelope writer discards it and the table is shown instead.

• scai connection list, scai connection test (success path), scai project info, and scai project status attach a command-specific result when –json is active.

• Keep commandsWithStructuredResult aligned with GlobalHelpJsonOverview in the CLI source when adding new Json result writers.

Quick Start¶

Basic workflow to get started:

1. Create a project (use -c to set default Snowflake connection)

scai init -n <name> -l <language> -c <connection>

2. Add source code (full migration: SqlServer, Redshift)

scai code extract

3. Add source code (other languages)

scai code add -i <path>

4. Convert to Snowflake SQL

scai code convert

5. Deploy to Snowflake

scai code deploy --all

Using -c <connection> saves the Snowflake connection in the project, avoiding the need to specify it for each command.

For commands that only need Snowflake account/user metadata (for example code extract and code convert), the CLI reads your local Snowflake CLI config (TOML) first without opening a live session. If account and user cannot be read from that config while you are online, it falls back to testing the Snowflake connection. Missing or blank account or user in TOML also triggers a live connection test when online.

Global –json prints one JSON envelope to stdout (success, warnings, errors, and an optional command-specific result) for automation, CI/CD, and agents. It can appear anywhere on the command line. See jsonOutput.commandsWithStructuredResult for commands that attach a structured result payload today.

With –json, connection list, connection test (on success), project info, and project status populate the envelope result; other commands may emit the envelope with warnings/errors only or a minimal result until documented.

Run ‘scai <command> -h’ for detailed help on any command.

Commands¶

scai init¶

Create a new migration project in the specified directory (or current directory if PATH is omitted).

scai init [PATH] -l <LANGUAGE> [-n <NAME>] [-i <INPUT_PATH>] [--code-already-split] [-c <CONNECTION>]

Prerequisites:

• Target directory must not contain an existing project
• Valid source language must be specified

Behavior:

• Creates the project directory structure and configuration files
• When –input-code-path is provided: SqlServer, Redshift, and Teradata run the arrange and parse-and-assess pipeline, promote processed files to source/, and generate a code unit registry; other languages copy source directly to source/
• When –code-already-split is used with –input-code-path (SqlServer, Redshift, and Teradata), skips the arrange/split phase, promotes raw source directly to source/, runs assessment only for code unit registry generation, and marks the project as project type: Full (new folder structure)
• Redshift and Teradata SQL source files (.sql, .ddl, .dml) require paired SC tags (e.g. -- <sc-table> table_name </sc-table>) for the arrange step. Script files (.bteq, .btq, .fl, .fload, .ml, .mld, .mload, .tp, .tpump, .tpt) are exempt from SC-tag requirements. If validation (ADD0010) or arrange (ADD0011) fails, the project is still created but source code is not added. Recovery: fix source files and run scai code add -i <path>, or use --code-already-split if the code is already split

Supported Languages:

Full Migration:

• SqlServer
• Redshift

Code Conversion Only:

• Oracle
• Teradata
• BigQuery
• Databricks
• Greenplum
• Sybase
• Postgresql
• Netezza
• Spark
• Vertica
• Hive
• Db2

Options:

Project folder structure:

Examples:

# Create a project in a new folder (recommended)
scai init my-project -l Teradata

# Create a project in the current directory
scai init -l Teradata

# Create project with source code
scai init my-project -l Oracle -i /path/to/code

# Create project with pre-split source code (skip arrange phase)
scai init my-project -l SqlServer -i /path/to/code --code-already-split

# Create project with a specific connection
scai init my-project -l Oracle -c my-snowflake-conn

scai project¶

View and manage project configuration.

scai project info¶

Display project details including name, source language, and status.

scai project info

Prerequisites:

• Must be run from within a migration project directory

Behavior:

• With global –json, prints only the JSON envelope; the result object includes project id, name, source language, project type (raw and display strings), explanations, created metadata, optional description and cloud project id, schema version, connectionDefaults (Snowflake and source defaults split into shared project.yml vs workspace-local project.local.yml), and a localYamlNote string.

Output: Project details displayed

Output fields:

• Project Name: Name of the migration project
• Project ID: Unique identifier (MIGRATION_PROJECT_ prefix)
• Source Language: Source database dialect (e.g., Teradata, Oracle)
• Snowflake Connection: Default connection name (if configured)
• Source Connection: Default source connection name (if configured)
• Project Root: Absolute path to project directory

Examples:

# Show current project details
scai project info

# Machine-readable project details
scai project info --json

scai project status¶

Show project.yml context and Code Unit Registry snapshot (read-only).

scai project status [OPTIONS]

Prerequisites:

• Must be run from within a migration project directory

Behavior:

• Shows project context from project.yml: absolute project root, project id, project type, source dialect, created metadata, optional description and cloud project id, default Snowflake connection
• When environments are defined in project.yml, shows a table with Snowflake database, schema, and description per environment (non-secret)
• When the registry is initialized, reads code units from the Code Unit Registry; when not, prints project context with registry metrics zeroed and an uninitialized-registry warning
• Registry overview: one table with registered, converted, deployable; with –full, inventory adds object types from Target.ObjectType and source locations from Source database/schema
• Deployable counts converted code units that pass registry deploy checks (required registry fields and no issues whose codes are in a small explicit deploy-blocking set; registry severity/level fields are not used). Missing references count reflects assessment failures (migration completeness)
• SQL drift from FindSqlFileChanges: modified tracked SQL vs non-modified file-change types and untracked paths; console warns when the drift query fails
• Registry overview includes a dim one-line EWI/FDM/PRF/OOS instance total (category totals)
• Aggregates conversion issues (EWIs, FDMs, PRFs, OOS) from registry issue entries
• Objects ranked by issue load and most common issue codes appear on the console only with –full (row caps 10 / 12 where documented)
• Ranks code units by total conversion issue instances (sum of Count for issues with non-empty codes); top rows shown with –full
• With global –json, prints only the JSON envelope; the result object has full (boolean, same as –full) and status (aggregated ProjectStatusData: registry snapshot, project context, and metrics) instead of formatted tables.

Options:

Output: Teal header. Bold subsection titles directly above tables (no blank line between title and table). Default: project context, environments, registry overview, code unit registry summary. –full adds inventory (object types / source locations, first 12 each), issue rankings (10 rows), most common codes (10 rows), plus extra SQL drift prose when unsynced. Dim footer notes metrics are from the code unit registry.

Examples:

# Show project status
scai project status

# Extended tables (inventory and issues)
scai project status --full

# Machine-readable status snapshot
scai project status --json

# Machine-readable extended status
scai project status --full --json

scai project defaults¶

scai project defaults set¶

Set project-level defaults (Snowflake connection, source connection, warehouse, database, schema). Values are tested before save; saved connection profiles are not modified. Always writes to project.local.yml to prevent credentials from being committed to version control.

scai project defaults set [[-c <NAME>]] [[-s <NAME>]] [[--warehouse <NAME>]] [[--database <NAME>]] [[--schema <NAME>]] [[--role <NAME>]]

Prerequisites:

• A migration project initialized with ‘scai init’
• Connections must exist in connections.toml or config.toml

Behavior:

• Only provided flags are persisted for the project
• Always writes to project.local.yml (gitignored), never to the shared project.yml
• Snowflake fields: loads saved connection profiles, merges existing project Snowflake defaults to your current connection without modifying it, then tests it
• Source (-s): tests the source connection for the project’s source language and defines it as the project’s default source connection (if valid)

Options:

Examples:

# Set project Snowflake connection
scai project defaults set -c my-snowflake

# Set project source connection
scai project defaults set -s my-oracle

# Set warehouse default
scai project defaults set --warehouse COMPUTE_WH

scai project defaults unset¶

Clear project-level defaults for the current project. Always clears from project.local.yml.

scai project defaults unset [[--connection]] [[--source-connection]] [[--warehouse]] [[--database]] [[--schema]] [[--role]]

Behavior:

• Only flags you pass clear the matching field; other fields are unchanged
• Always clears from project.local.yml (gitignored), never from the shared project.yml

Options:

Examples:

# Clear project Snowflake connection
scai project defaults unset --connection

# Clear warehouse default
scai project defaults unset --warehouse

scai project doctor¶

Check project folders, code unit registry, and connection names without connecting to databases.

scai project doctor [[OPTIONS]]

Prerequisites:

• Must be run from within a migration project directory

Behavior:

• Runs offline only (does not log in to Snowflake or the source database)
• Lists each expected folder and file (required vs optional) with OK, Warning, or Problem
• Checks the code unit registry can load when present
• Checks Snowflake and source connection names exist in local TOML (not a live connection test)

Options:

Output: Table of findings or JSON with json_schema_version and findings[]

Examples:

# Run health checks
scai project doctor

# JSON for automation
scai project doctor --json

scai project set-default-connection¶

Set the default Snowflake connection for the current project.

scai project set-default-connection -c <CONNECTION>

Prerequisites:

• A migration project initialized with ‘scai init’
• Snowflake connection available in connections.toml or config.toml

Behavior:

• Validates the connection exists and works before saving
• Saves the connection name in project.yml
• All project commands will use this connection by default

Options:

Examples:

# Set project default connection
scai project set-default-connection -c my-snowflake

scai connection¶

Manage source database connections (Redshift, SQL Server, Teradata, Oracle, Postgresql).

scai connection add-redshift¶

Add a new Redshift source database connection.

scai connection add-redshift [OPTIONS]

Prerequisites:

• Network access to the Redshift cluster/serverless endpoint
• For IAM auth: AWS credentials configured (AWS CLI or environment variables)
• For standard auth: Username and password

Authentication Methods:

• IAM Serverless: AWS IAM with Redshift Serverless
• IAM Provisioned: AWS IAM with Provisioned Cluster
• Standard: Username/password authentication

Operation Modes:

• Interactive: Prompts for all required information (recommended)
• Inline: Use command-line options for automation/CI

Options:

Output: Connection saved to ~/.snowflake/connections.toml (or project-local)

Examples:

# Add connection interactively (recommended)
scai connection add-redshift

# IAM Serverless (inline)
scai connection add-redshift --source-connection my-redshift --auth iam-serverless --workgroup my-workgroup --database mydb --region us-east-1

scai connection add-sql-server¶

Add a new SQL Server source database connection.

scai connection add-sql-server [OPTIONS]

Prerequisites:

• Network access to the SQL Server instance
• For Windows auth: Valid domain credentials
• For standard auth: SQL Server username and password

Authentication Methods:

• Windows: Windows Authentication (Integrated Security)
• Standard: SQL Server Authentication (username/password)

Operation Modes:

• Interactive: Prompts for all required information (recommended)
• Inline: Use command-line options for automation/CI

Options:

Output: Connection saved to ~/.snowflake/connections.toml (or project-local)

Examples:

# Add connection interactively (recommended)
scai connection add-sql-server

# Windows Authentication
scai connection add-sql-server --source-connection my-sqlserver --auth windows --server-url localhost --database mydb

# Standard Authentication
scai connection add-sql-server --source-connection my-sqlserver --auth standard --server-url localhost --database mydb --username sa

scai connection add-postgresql¶

Add a new PostgreSQL source database connection.

scai connection add-postgresql [OPTIONS]

Prerequisites:

• Network access to the PostgreSQL host (TCP, default port 5432)
• A PostgreSQL role with CONNECT + USAGE on the target database and SELECT on pg_catalog
• Username and password for standard authentication

Authentication Methods:

• Standard: Username/password authentication (MVP — only method supported)

SSL Modes:

• Disable: No SSL (local / loopback only)
• Prefer: SSL if available, plaintext otherwise
• Require: SSL required, server certificate not verified (default)
• VerifyCA: SSL required, CA validated against trust store
• VerifyFull: SSL required, CA + hostname validated

Operation Modes:

• Interactive: Prompts for all required information (recommended)
• Inline: Use command-line options for automation/CI

Options:

Output: Connection saved to ~/.snowflake/connections.toml (or project-local)

Examples:

# Add connection interactively (recommended)
scai connection add-postgresql

# Standard authentication (inline)
scai connection add-postgresql --source-connection my-pg --auth standard --host db.example.com --database analytics --user postgres --password ****

# Local Docker (Disable SSL, custom port)
scai connection add-postgresql --source-connection local-pg --auth standard --host localhost --port 5432 --database scai_pg --user scai --password scai --ssl-mode Disable

scai connection set-default¶

Set the default source connection for a database type.

scai connection set-default -l <LANGUAGE> -s <SOURCE_CONNECTION>

Prerequisites:

• Connection already added with ‘scai connection add-redshift’, ‘scai connection add-sql-server’, ‘scai connection add-teradata’, ‘scai connection add-oracle’, or ‘scai connection add-postgresql’

Behavior:

• Marks a configured connection as the default for extraction and validation
• Default source connection is used when no -s/–source-connection option is specified on commands that need a source database

Options:

Examples:

# Set default Redshift connection
scai connection set-default -l redshift -s prod

# Set default SQL Server connection
scai connection set-default -l sqlserver -s dev

scai connection list¶

List connections for a given source database.

scai connection list [-l <LANGUAGE>]

Behavior:

• Without –source-language: shows Snowflake connections (from Snowflake CLI config) and configured source connections per supported database type.
• With global –json and no –source-language: prints only the JSON envelope; result uses mode summary with hasAnyConnections, snowflake (default name, connection rows, distinct config paths), and sources (per dbType: configPath, defaultConnectionName, connection name rows).
• With –source-language and –json: result uses mode detailed with connections (masked credentials JSON per profile), config path, and default name.

Supported Languages:

• SqlServer
• Redshift

Options:

Output: Without –json: tables (summary) or detailed rows. With –json: see behavior for envelope result shapes.

Examples:

# List all connections summary
scai connection list

# List Redshift connections
scai connection list -l redshift

# List SQL Server connections
scai connection list -l sqlserver

# JSON summary of all connections
scai connection list --json

# JSON detailed list for one source language
scai connection list -l sqlserver --json

scai connection test¶

Test a source database connection.

scai connection test -l <LANGUAGE> [-s <SOURCE_CONNECTION>]

Prerequisites:

• Connection already configured
• Network access to the database

Behavior:

• Attempts to connect to the database
• Verifies credentials and network connectivity
• Reports connection success or failure details
• Exits with a non-zero code when the connection test fails so scripts and CI/CD can detect failures
• With global –json on success: prints only the JSON envelope; result includes connectionName, dbType, credentialsMaskedJson (JSON document as a string, secrets redacted), and success true. On failure, errors appear on the envelope and the result table is not used.
• With global –json, the ‘using default connection’ line is omitted to keep stdout as a single JSON document.

Supported Languages:

• SqlServer
• Redshift

Options:

Examples:

# Test SQL Server connection
scai connection test -l sqlserver -s my-sqlserver

# Test Redshift connection
scai connection test -l redshift -s my-redshift

# JSON result on successful test
scai connection test -l sqlserver -s my-sqlserver --json

scai code¶

Code operations: extract, convert, add, deploy, find, where.

scai code extract¶

Extract code from the source database.

scai code extract [OPTIONS]

Prerequisites:

• A migration project initialized with ‘scai init’
• Source database connection configured (use ‘scai connection add-redshift’, ‘scai connection add-sql-server’, ‘scai connection add-teradata’, ‘scai connection add-oracle’, or ‘scai connection add-postgresql’)
• Network access to the source database

Behavior:

• Connects to the configured source database connection
• Extracts DDL and writes to source/ folder

Supported Languages:

• SqlServer
• Redshift
• Postgresql

Interactive Mode:

Requirement: Requires an interactive terminal. In non-interactive or CI environments use –schema, –object-type, and –name instead.

• Pre-fetch: prompt for schema (or leave empty for all) and multi-select object types to scope the catalog query.
• Post-fetch: multi-select schemas to include, optional name filter (wildcard * supported), summary table, then confirm extraction.

Options –schema, -t/–object-type, and -n/–name pre-fill the interactive prompts when used with -i.

Options:

Output: Extracted SQL files organized by database

source/
  └── <database>/        One folder per source database
      └── <schema>/      One folder per database schema
          └── <type>/    One folder per object type
              └── *.sql  DDL files for each object

Examples:

# Interactive extraction (browse and select schemas, object types, filter by name)
scai code extract -i

# Interactive with pre-filled schema
scai code extract -i --schema public

# Extract tables from a schema
scai code extract --schema public --object-type TABLE

# Extract tables and views
scai code extract --object-type TABLE,VIEW

# Extract from all schemas
scai code extract

# Extract code with a custom source identifier
scai code extract --source-id prod-redshift-cluster

scai code convert¶

Transform source database code to Snowflake SQL.

scai code convert [OPTIONS]

Additional dialect-specific options are dynamically loaded based on the project’s source language. Run ‘scai code convert –help’ within a project to see all available options for that dialect.

Prerequisites:

• A migration project initialized with ‘scai init’
• Source code in the ‘source/’ folder (from ‘scai code extract’, ‘scai code add’, or manual copy)

Behavior:

• Reads SQL files from source/ folder
• Transforms code to Snowflake-compatible SQL
• Writes converted code and reports to snowflake/ folder

Options:

Output: Converted Snowflake SQL files and reports

snowflake/
  ├── Output/                     Converted Snowflake SQL files
  │   └── <schema>/               Organized by schema
  │       └── *.sql               Converted DDL files
  ├── Reports/
  │   ├── TopLevelCodeUnits.csv   List of all converted objects
  │   ├── Issues.csv              Conversion issues/warnings
  │   └── Summary.html            HTML conversion summary
  └── Logs/                       Conversion log files

Examples:

# Convert using project defaults
scai code convert

# Convert with custom context path
scai code convert --context-path /path/to/context

# Show all conversion settings for the project's dialect
scai code convert --help

# Convert with custom schema
scai code convert --customschema MY_SCHEMA

# Convert with comment on missing dependencies
scai code convert --comments

# Convert with object renaming file
scai code convert --renamingfile /path/to/renaming.json

# Convert only procedures
scai code convert --where "objectType = 'procedure'"

scai code add¶

Add source code from an input file or directory to the project’s Source folder.

scai code add -i <INPUT_PATH> [--code-already-split] [OPTIONS]

Prerequisites:

• A migration project initialized with ‘scai init’
• Input must be a valid SQL source file or a directory containing SQL source files

Behavior:

• Copies the specified file, or all files and directories from the input path, to artifacts/source_raw/
• SqlServer, Redshift, and Teradata: runs arrange-only, produces artifacts/source_raw_Processed/, merges into source/
• Other languages: copies source directly into source/
• When –code-already-split is used (SqlServer, Redshift, and Teradata), skips the arrange/split phase, promotes raw source directly to source/, runs assessment only for code unit registry generation, and marks the project as project type: Full (new folder structure)
• Checks for conflicting files when destination folders are non-empty (unless –overwrite is set)
• Reports up to 10 conflicting file names if conflicts are detected

Options:

Output: Original input in artifacts/source_raw/; source/ contains arranged output (SqlServer, Redshift, and Teradata) or copied source (other languages)

artifacts/source_raw/
source/

Examples:

# Add source code to project
scai code add -i /path/to/source/code

# Add pre-split source code (skip arrange phase)
scai code add -i /path/to/source/code --code-already-split

# Add code using full option name
scai code add --input-path ./my-sql-scripts

# Add a single file
scai code add -i /path/to/script.sql

# Add code overwriting existing files
scai code add -i /path/to/source/code --overwrite

# Add code with a source identifier for traceability
scai code add -i /path/to/source/code --source-id prod-sql-server-01

scai code accept¶

Accept the latest converted artifact versions into the snowflake output folder.

scai code accept [OPTIONS]

Prerequisites:

• A migration project initialized with ‘scai init’
• Source code must be split and registry files must be generated (run ‘scai code add’)
• At least one code conversion run with ‘scai code convert’

Behavior:

• Scans the artifacts directory for timestamped conversion outputs
• For each code unit, selects the most recent version based on the timestamp folder name (yyyyMMdd.HHmmss)
• Copies the latest .sql files into the snowflake folder, preserving the directory structure
• Skips source_raw and source_raw_Processed directories

Options:

Output: Updated snowflake folder with latest artifact versions

snowflake/<database>/<schema>/<type>/<name>.sql

Examples:

# Accept all latest artifacts
scai code accept

scai code deploy¶

Deploy converted SQL code to Snowflake.

scai code deploy [OPTIONS]

Prerequisites:

• Converted code in ‘snowflake/Output/’ (from ‘scai code convert’)
• Snowflake connection configured (set with ‘scai init -c’ or project settings)
• Appropriate Snowflake privileges (CREATE TABLE, CREATE VIEW, etc.)

Behavior:

• Executes successfully converted objects (tables, views, procedures, functions)
• Uses Snowflake connection from connections.toml, config.toml, or project default
• –warehouse, –schema, –role temporarily set missing connection fields (in-memory only, TOML is not modified)
• If the connection already has a value for an overridden field, an error is returned

Options:

Output: Console output shows deployment progress and results for each object. Objects are created in the target Snowflake database/schema.

Examples:

# Deploy using default connection
scai code deploy

# Deploy all objects
scai code deploy --all

# Deploy with specific connection
scai code deploy --connection my-snowflake

# Deploy with temporary warehouse override
scai code deploy --warehouse MY_WH

# Deploy filtered objects and their dependencies
scai code deploy --where "target.objectType = 'procedure'" --include-dependencies

scai code sync¶

Import a legacy migration project (.snowct) into the new SnowConvert AI Structure (Code Unit Registry).

scai code sync <PROJECT_PATH> -l <LANGUAGE> -i <SOURCE_FOLDER> --snowflake <CONVERTED_FOLDER> [-c <CONNECTION>]

Prerequisites:

• Existing source code directory with SQL files
• Existing converted Snowflake code directory
• Target project directory must not exist or must be empty
• Source language must be SqlServer or Redshift

Behavior:

• Creates a new SnowConvert project at the specified path
• Copies source code to the project’s source/ folder
• Validates the code unit registry for duplicate source file paths
• Runs a code conversion to generate full registry information
• Copies converted code to the project’s snowflake/ folder
• If any step fails, the project directory is deleted (rolled back)

Supported Dialects:

• SqlServer
• Redshift

Options:

Output: Project directory with source/, snowflake/, .scai/, artifacts/, reports/, and logs/ folders.

Examples:

# Sync a legacy Oracle project
scai code sync my-project -l oracle -i /path/to/source --snowflake /path/to/converted

# Sync with a specific Snowflake connection
scai code sync my-project -l sqlserver -i ./source-code --snowflake ./converted-code -c my-snowflake

# Sync a Teradata project
scai code sync /output/project -l teradata -i /legacy/source --snowflake /legacy/snowflake

scai code where¶

Show WHERE clause query reference for code unit filtering.

scai code where

Behavior:

• Displays all queryable fields, supported operators, and usage examples for WHERE clause filtering
• Does not require a project directory
• Works offline without network access
• When online, Snowflake is optional: account and user are read from local project configuration first when available, with a live connection test as a fallback when metadata is incomplete
• The reference is loaded dynamically from the CodeUnitRegistry native library (field list is auto-generated from the code-unit JSON schema)

Commands that support WHERE:

• scai code accept --where <EXPRESSION>
• scai code convert --where <EXPRESSION>
• scai code deploy --where <EXPRESSION>
• scai code find --where <EXPRESSION>
• scai data migrate --where <EXPRESSION>
• scai data validate --where <EXPRESSION>

Output: Printed reference guide including syntax, operators, queryable fields with types and allowed values, and example WHERE expressions. The content is generated at runtime from the CodeUnitRegistry; run the command to see the current field list.

Examples:

# Show WHERE clause reference
scai code where

scai code find¶

Find code units from project’s Code Unit Registry.

scai code find [OPTIONS]

Prerequisites:

• A migration project initialized with ‘scai init’
• An initialized Code Unit Registry (generated after ‘scai code convert’)

Behavior:

• Reads code unit information from the Code Unit Registry
• Displays code units in a table with Id, Fully Qualified Name, and Object Type
• Results are limited to 100 by default; use –no-limit to show all
• Can be filtered using a SQL-like WHERE clause

Options:

Output: Console output shows code unit information in a table format.

Examples:

# Find all code units
scai code find

# Find code units with a specific name
scai code find --where "source.name = 'my_table'"

# Find all code units without limit
scai code find --no-limit

scai code resync¶

Re-scan modified converted files and update issue metadata in the Code Unit Registry.

scai code resync

Prerequisites:

• A migration project initialized with ‘scai init’
• Code converted with ‘scai code convert’

Behavior:

• Detects code units whose converted files have been modified
• Re-scans each modified file for SnowConvert issue codes (EWI, FDM, OOS, PRF)
• Updates the issue metadata in the registry

Output: Console output shows the number of modified files resynced

Examples:

# Resync modified converted files
scai code resync

scai data¶

Data operations: migrate, validate, worker, orchestrator, diagnostics.

scai data migrate¶

scai data migrate start (Preview)¶

Migrate data from the source system into a Snowflake account.

scai data migrate start [--config <DATA_MIGRATION_CONFIG_PATH>] [-c <CONNECTION>] [OPTIONS]

Prerequisites:

• Data migration configuration file (YAML); if –config is omitted, an ephemeral default config is auto-generated under the OS temp directory with a unique per-run affinity
• Snowflake connection with appropriate privileges

Behavior:

• Reads the migration configuration and runs the data migration workflow
• When –config is omitted, the generated workflow config is written to the OS temp directory and deleted when the run finishes

Options:

Output: Returns a WORKFLOW_ID for tracking progress

Examples:

# Start migration with default config
scai data migrate start --connection my-snowflake

# Start migration with custom config
scai data migrate start --config my-data-migration-config.yaml --connection my-snowflake

scai data migrate create-workflow (Preview)¶

Create a cloud data migration workflow in Snowflake.

scai data migrate create-workflow [--config <DATA_MIGRATION_CONFIG_PATH>] [-c <CONNECTION>] [OPTIONS]

Prerequisites:

• Data migration configuration file (YAML); if –config is omitted, defaults to data-migration-config.yaml
• Orchestrator setup completed (run ‘scai data orchestrator setup’ first)
• Snowflake connection with appropriate privileges

Behavior:

• Validates the configuration and creates a Data Migration workflow in Snowflake
• By default, returns immediately after creating the workflow
• Use -w|–watch to wait for the workflow to complete

Options:

Output: Returns a WORKFLOW_ID for tracking progress

Examples:

# Create a cloud workflow (default config)
scai data migrate create-workflow --connection my-snowflake

# Create a cloud workflow with custom config
scai data migrate create-workflow --config my-data-migration-config.yaml --connection my-snowflake

# Create workflow and wait for completion
scai data migrate create-workflow --connection my-snowflake --watch

scai data migrate status (Preview)¶

Check the status of a Cloud Data Migration workflow.

scai data migrate status [WORKFLOW_ID] [OPTIONS]

Prerequisites:

• A workflow started with ‘scai data migrate start’ or ‘scai data migrate create-workflow’
• Snowflake connection with access to the workflow

Options:

Output: Progress bars for table preprocessing and partition processing. Error details if workflow failed.

Examples:

# Check workflow status
scai data migrate status DATA_MIGRATION_WORKFLOW_xx_yy_zz

# Watch workflow progress
scai data migrate status DATA_MIGRATION_WORKFLOW_xx_yy_zz --watch

scai data migrate list (Preview)¶

List all Cloud Data Migration workflows.

scai data migrate list [OPTIONS]

Prerequisites:

• Snowflake connection with access to the SNOWCONVERT_AI database

Options:

Output: A table with workflow name, status, creation time, end time, and error message.

Examples:

# List all migration workflows
scai data migrate list

# Filter by status
scai data migrate list --status running

# Use a specific connection
scai data migrate list --connection my-snowflake

scai data migrate generate-config (Preview)¶

Generate a YAML configuration file for data migration.

scai data migrate generate-config [--where <WHERE>] [-o <OUTPUT_PATH>] [--affinity <AFFINITY>]

Prerequisites:

• A migration project initialized with ‘scai init’
• Code added and converted (‘scai code add’ and ‘scai code convert’)

Behavior:

• Resolves source and target table names from the Code Unit Registry
• Generates a YAML config for ‘scai data migrate start’ (–config optional; defaults to data-migration-config.yaml)
• Sets synchronization strategy to ‘none’ and extraction strategy to ‘regular’

Options:

Output: A YAML file (default: data-migration-config.yaml) with source/target table mappings.

Examples:

# Generate config for all tables
scai data migrate generate-config

# Filter tables by schema
scai data migrate generate-config --where "source.schema = 'public'"

# Custom output path
scai data migrate generate-config -o my-config.yaml

# Set workflow affinity
scai data migrate generate-config --affinity my-team

scai data migrate pause (Preview)¶

Pause a running data migration workflow.

scai data migrate pause <WORKFLOW_NAME> [-c <CONNECTION>]

Prerequisites:

• An active workflow in ‘executing’ or ‘pending’ state
• Snowflake connection with appropriate privileges

Options:

Output: Confirmation that the workflow was paused.

Examples:

# Pause a workflow
scai data migrate pause MY_WORKFLOW

scai data migrate resume (Preview)¶

Resume a paused data migration workflow.

scai data migrate resume <WORKFLOW_NAME> [-c <CONNECTION>]

Prerequisites:

• A workflow in ‘paused’ state
• Snowflake connection with appropriate privileges

Options:

Output: Confirmation that the workflow was resumed.

Examples:

# Resume a paused workflow
scai data migrate resume MY_WORKFLOW

scai data migrate cancel (Preview)¶

Cancel a data migration workflow.

scai data migrate cancel <WORKFLOW_NAME> [-y] [-c <CONNECTION>]

Prerequisites:

• A workflow that is not yet completed or already cancelled
• Snowflake connection with appropriate privileges

Behavior:

• Prompts for confirmation unless -y is passed

Options:

Output: Confirmation that the workflow was cancelled.

Examples:

# Cancel a workflow (with prompt)
scai data migrate cancel MY_WORKFLOW

# Cancel a workflow (skip prompt)
scai data migrate cancel MY_WORKFLOW -y

scai data validate¶

scai data validate start (Preview)¶

Validate data between source and Snowflake.

scai data validate start [--config <DATA_VALIDATION_CONFIG_PATH>] [-c <CONNECTION>] [OPTIONS]

Prerequisites:

• Data validation configuration file (JSON); if –config is omitted, an ephemeral default config is auto-generated under the OS temp directory with a unique per-run affinity
• Snowflake connection with appropriate privileges

Behavior:

• Reads the validation configuration and runs the data validation workflow
• When –config is omitted, the generated workflow config is written to the OS temp directory and deleted when the run finishes

Options:

Output: Returns a WORKFLOW_ID for tracking progress

Examples:

# Start validation with default config
scai data validate start --connection my-snowflake

# Start validation with custom config
scai data validate start --config my-data-validation-config.json --connection my-snowflake

scai data validate create-workflow (Preview)¶

Create a cloud data validation workflow in Snowflake.

scai data validate create-workflow [--config <DATA_VALIDATION_CONFIG_PATH>] [-c <CONNECTION>] [OPTIONS]

Prerequisites:

• Data validation configuration file (JSON); if –config is omitted, defaults to data-validation-config.json
• Snowflake connection with appropriate privileges

Behavior:

• Validates the configuration and creates a Data Validation workflow in Snowflake
• By default, returns immediately after creating the workflow
• Use -w|–watch to wait for the workflow to complete

Options:

Output: Returns a WORKFLOW_ID for tracking progress

Examples:

# Create a cloud validation workflow (default config)
scai data validate create-workflow --connection my-snowflake

# Create a cloud validation workflow with custom config
scai data validate create-workflow --config my-data-validation-config.json --connection my-snowflake

# Create workflow and wait for completion
scai data validate create-workflow --watch --connection my-snowflake

scai data validate status (Preview)¶

Check the status of a Cloud Data Validation workflow.

scai data validate status [WORKFLOW_NAME] [OPTIONS]

Prerequisites:

• A workflow started with ‘scai data validate start’ or ‘scai data validate create-workflow’
• Snowflake connection with access to the workflow

Options:

Output: Per-table validation status showing schema, metrics, and row validation results.

Examples:

# Check workflow status
scai data validate status DATA_VALIDATION_WORKFLOW_xx_yy_zz

# Watch workflow progress
scai data validate status DATA_VALIDATION_WORKFLOW_xx_yy_zz --watch

scai data validate list (Preview)¶

List all Cloud Data Validation workflows.

scai data validate list [OPTIONS]

Prerequisites:

• Snowflake connection with access to the SNOWCONVERT_AI database

Options:

Output: A table with workflow name, status, creation time, end time, and error message.

Examples:

# List all validation workflows
scai data validate list

# Filter by status
scai data validate list --status failed

# Use a specific connection
scai data validate list --connection my-snowflake

scai data validate generate-config (Preview)¶

Generate a JSON configuration file for data validation.

scai data validate generate-config [--where <WHERE>] [-o <OUTPUT_PATH>]

Prerequisites:

• A migration project initialized with ‘scai init’
• Code added and converted (‘scai code add’ and ‘scai code convert’)

Behavior:

• Resolves source and target table names from the Code Unit Registry
• Generates a JSON config for ‘scai data validate start’ (–config optional; defaults to data-validation-config.json)

Options:

Output: A JSON file (default: data-validation-config.json) with source/target table mappings.

Examples:

# Generate config for all tables
scai data validate generate-config

# Filter tables by schema
scai data validate generate-config --where "source.schema = 'public'"

# Custom output path
scai data validate generate-config -o my-config.json

scai data validate pause (Preview)¶

Pause a running data validation workflow.

scai data validate pause <WORKFLOW_NAME> [-c <CONNECTION>]

Prerequisites:

• An active workflow in ‘executing’ or ‘pending’ state
• Snowflake connection with appropriate privileges

Options:

Output: Confirmation that the workflow was paused.

Examples:

# Pause a validation workflow
scai data validate pause MY_WORKFLOW

scai data validate resume (Preview)¶

Resume a paused data validation workflow.

scai data validate resume <WORKFLOW_NAME> [-c <CONNECTION>]

Prerequisites:

• A workflow in ‘paused’ state
• Snowflake connection with appropriate privileges

Options:

Output: Confirmation that the workflow was resumed.

Examples:

# Resume a paused validation workflow
scai data validate resume MY_WORKFLOW

scai data validate cancel (Preview)¶

Cancel a data validation workflow.

scai data validate cancel <WORKFLOW_NAME> [-y] [-c <CONNECTION>]

Prerequisites:

• A workflow that is not yet completed or already cancelled
• Snowflake connection with appropriate privileges

Behavior:

• Prompts for confirmation unless -y is passed

Options:

Output: Confirmation that the workflow was cancelled.

Examples:

# Cancel a workflow (with prompt)
scai data validate cancel MY_WORKFLOW

# Cancel a workflow (skip prompt)
scai data validate cancel MY_WORKFLOW -y

scai data worker¶

scai data worker setup (Preview)¶

Create the Data Exchange Worker SPCS service on the specified compute pool.

scai data worker setup --compute-pool <COMPUTE_POOL> [--connection <SNOWFLAKE_CONNECTION>] [--role <ROLE>] [--warehouse <WAREHOUSE>]

Prerequisites:

• Snowflake compute pool created and accessible
• Snowflake connection with appropriate privileges

Behavior:

• Creates the DEW SPCS service if it does not exist (idempotent)
• Waits for the service to reach a running state

Options:

Output: Status messages indicating progress of each setup step.

Examples:

# Set up DEW service with default connection
scai data worker setup --compute-pool MY_COMPUTE_POOL

# Set up with a specific role
scai data worker setup --compute-pool MY_COMPUTE_POOL --role MY_ROLE

scai data worker start (Preview)¶

Resume the Data Exchange Worker SPCS service, or run the local worker process when –local is passed.

scai data worker start [--local [<CONFIG_FILE> | --auto-config [PATH]]] [-c <CONNECTION>] [--role <ROLE>] [--warehouse <WAREHOUSE>]

Prerequisites:

• DEW service previously bootstrapped with ‘scai data worker setup’ (cloud mode)
• Python 3.11 or higher installed (local mode)
• A valid data exchange agent configuration file (local mode)

Behavior:

• Default (cloud): issues ALTER SERVICE … RESUME on the DEW SPCS service
• –local: installs the data exchange agent (if needed) and starts it as a foreground process

Options:

Output: Status message (cloud) or real-time agent output (local mode).

Examples:

# Resume cloud DEW service
scai data worker start

# Resume with a specific role
scai data worker start --role MY_ROLE

# Run local worker with config
scai data worker start --local my-agent-config.yaml

# Generate local config template
scai data worker start --local --auto-config

scai data worker stop (Preview)¶

Suspend or drop the Data Exchange Worker SPCS service.

scai data worker stop [--connection <SNOWFLAKE_CONNECTION>] [--role <ROLE>] [--warehouse <WAREHOUSE>] [--drop]

Prerequisites:

• Snowflake connection with appropriate privileges

Behavior:

• By default, suspends the DEW service (can be resumed later)
• Use –drop to permanently remove the service
• –local is advisory only (local worker is a foreground process; use Ctrl-C to stop it)

Options:

Output: Status message indicating whether the service was suspended or dropped.

Examples:

# Suspend the DEW service
scai data worker stop

# Suspend with a specific role
scai data worker stop --role MY_ROLE

# Drop the DEW service permanently
scai data worker stop --drop

scai data orchestrator¶

scai data orchestrator setup (Preview)¶

Start the Data Migration Service on a compute pool and wait for infrastructure to be ready.

scai data orchestrator setup --compute-pool <COMPUTE_POOL> [--connection <SNOWFLAKE_CONNECTION>]

Prerequisites:

• Snowflake compute pool created and accessible
• Snowflake connection with appropriate privileges

Behavior:

• Creates the SNOWCONVERT_AI.DATA_MIGRATION schema if needed
• Starts the Data Migration Service on the specified compute pool
• Waits for the Data Migration Service to set up the objects in the SNOWCONVERT_AI.DATA_MIGRATION schema

Options:

Output: Status messages indicating progress of each setup step.

Examples:

# Set up with default connection
scai data orchestrator setup --compute-pool MY_COMPUTE_POOL

# Set up with specific connection
scai data orchestrator setup --compute-pool MY_COMPUTE_POOL --connection my-snowflake

# Set up with a specific warehouse
scai data orchestrator setup --compute-pool MY_COMPUTE_POOL --warehouse MY_WAREHOUSE

scai data orchestrator start (Preview)¶

Resume the cloud Data Migration Service (SPCS), or run the orchestrator locally when –local is passed.

scai data orchestrator start [--local] [--connection <SNOWFLAKE_CONNECTION>] [--role <ROLE>] [--warehouse <WAREHOUSE>]

Prerequisites:

• Service previously bootstrapped with ‘scai data orchestrator setup’
• Snowflake connection with appropriate privileges

Behavior:

• Default (cloud): issues ALTER SERVICE … RESUME on the Data Migration SPCS service
• –local: starts the orchestrator as a foreground process using the resolved Snowflake connection

Options:

Output: Status message indicating whether the service was resumed.

Examples:

# Resume the cloud orchestrator
scai data orchestrator start

# Resume with a specific role
scai data orchestrator start --role MY_ROLE

# Run the orchestrator locally
scai data orchestrator start --local

scai data orchestrator stop (Preview)¶

Suspend or drop the Data Migration Service.

scai data orchestrator stop [--connection <SNOWFLAKE_CONNECTION>] [--role <ROLE>] [--warehouse <WAREHOUSE>] [--drop]

Prerequisites:

• Snowflake connection with appropriate privileges
• Orchestrator previously started with ‘scai data orchestrator setup’ or ‘scai data migrate start –start-service’

Behavior:

• By default, suspends the Data Migration Service (can be resumed later)
• Use –drop to permanently remove the service instead of suspending it

Options:

Output: Status message indicating whether the service was suspended or dropped.

Examples:

# Suspend the orchestrator (default)
scai data orchestrator stop

# Suspend with a specific role
scai data orchestrator stop --role MY_ROLE

# Drop the orchestrator permanently
scai data orchestrator stop --drop

scai data diagnostics (Preview)¶

Run diagnostic checks to verify Snowflake permissions for cloud data operations.

scai data diagnostics [OPTIONS]

Behavior:

• Connects to Snowflake and inspects the role’s effective grants
• Follows the role hierarchy to detect inherited privileges
• Does not create or modify any objects
• Reports PASS, FAIL, WARN, or SKIP for each check

Checks:

• SNOWCONVERT_AI database exists or can be created
• DATA_MIGRATION schema exists or can be created
• Required schema privileges (CREATE TABLE, CREATE STAGE, CREATE FILE FORMAT, CREATE PROCEDURE, CREATE VIEW, CREATE SEQUENCE, USAGE)
• Optional privileges (CREATE STREAMLIT for the migration dashboard)
• DATA_VALIDATION schema exists and USAGE privilege is granted

Options:

Output: Per-check PASS/FAIL/WARN/SKIP results for Snowflake permission verification.

Examples: