A lot of the advice about adopting dbt assumes you're starting from nothing. In practice, most teams have years of views, materialized views, and scheduled queries doing real work before anyone proposes adopting dbt at all. Rewriting all of that by hand is exactly the kind of project that gets approved, started, and quietly abandoned six weeks in.
Warehouse import is built for that situation specifically. It scans your schemas, tables and views and shows what could become dbt models, including which views read which tables and the primary key, unique and foreign key constraints the database already declares.
How it actually generates the project
You choose what to bring in. Warehouse import then writes sources, staging models, and tests generated from the primary key, unique, and foreign key constraints it found, and rewrites the SQL behind your existing views to use ref() instead of hardcoded table names, using sqlglot rather than a set of regexes that would break on the first nested CTE.
It writes all of this to a new branch, not directly to your main branch. Before you commit anything, it runs dbt parse, a SQLFluff lint pass with autofix, a full dbt build, and a row-level parity check against every original relation, so "the migration worked" means something more concrete than "it compiled."
We built it this way because the risk in a warehouse migration was never writing the YAML. It was writing YAML that quietly changes what a number means. Parity checking on every migrated relation is the part that makes this safe to actually run against something in production.