SSIS to dbt conversion starts by reading each Data Flow Task in the .dtsx package as a graph of sources, transformations, and destinations. That graph can become warehouse-specific dbt SQL plus sources.yml, schema.yml, and dbt_project.yml. SSIS control flow still needs separate orchestration work because dbt models don't replace precedence constraints, loops, or package scheduling.
- Data Flow Tasks map to dbt model logic; package control flow belongs in an orchestrator or deployment job.
- The target warehouse matters because PostgreSQL, BigQuery, and Snowflake require different quoting, date functions, and unpivot patterns.
- A dbt folder full of valid SQL can still be wrong. Review branch outputs, lookup misses, data types, and materializations before running it.
- Deflows exports a project scaffold rather than one loose SQL file, with unsupported steps left visible for review.
Split the package before translating it
A .dtsx package has two execution layers. The control flow decides which tasks run, in what order, and under which conditions. Inside a Data Flow Task, the data flow reads rows, derives columns, filters, joins, aggregates, and writes results. dbt has a direct home for the second layer because a model is a SQL transformation with declared dependencies.
Precedence constraints, Foreach containers, Script Tasks, and package variables don't become model SQL. Keep those items in the migration inventory, then rebuild the required scheduling in dbt jobs, Airflow, Azure Data Factory, or the warehouse scheduler your team already owns.
What becomes a dbt model
OLE DB, flat-file, and Excel inputs become source declarations or staging inputs. Derived Column steps become selected expressions; Conditional Split outputs become filtered branches; Lookup and Merge Join steps become joins; Aggregate and Union All become their SQL equivalents. Each generated model keeps the original package and task names nearby so an engineer can trace the code back to the canvas.
- Raw inputs become source() references in sources.yml
- Model SQL uses ref() when one generated model depends on another
- schema.yml records model and column metadata for review
- dbt_project.yml supplies the project shell and model path
Warehouse dialect still decides whether the model runs
dbt doesn't erase SQL dialect differences. BigQuery expects backtick quoting and UNNEST patterns; Snowflake supports QUALIFY and its own date functions; PostgreSQL has different casting and lateral behavior. Pick the warehouse target before generation so the project doesn't begin with a cross-dialect cleanup pass.
Materialization also needs a human decision. A converter can place a safe default in config, but it can't infer whether a production model should be a view, table, incremental model, or ephemeral helper from the package alone.
Review the branches SSIS makes easy to miss
Conditional Split has a default output for rows that match none of its named expressions. Lookup can route unmatched rows down a separate path. Those branches often carry reject handling or audit records, and dropping one changes row counts without producing an obvious syntax error.
Deflows keeps control-flow tasks and unsupported script behavior visible instead of folding them into plausible-looking SQL. The dbt targets are beta, so generated files should enter the same pull-request and warehouse-test path as hand-written models.
Primary references
Questions teams ask
Does SSIS to dbt conversion include package scheduling?
No. dbt models cover row-level transformation. SSIS precedence constraints, loops, event handlers, and task scheduling need an orchestration plan outside the model files. Deflows preserves known control-flow tasks as reference so that work stays in the migration inventory.
Which dbt warehouses can Deflows target?
The current dbt targets generate PostgreSQL, BigQuery, or Snowflake SQL. All three are beta outputs and include a dbt project scaffold with model files, sources.yml, schema.yml, and dbt_project.yml.
Can one .dtsx package produce several dbt models?
Yes. A package can contain several independent Data Flow Tasks. They are parsed as separate graphs so their transformations aren't merged into a single model by accident.