How Do You Migrate a dbt Core Project to Fusion on Snowflake, and What Breaks?
A checklist for the parts of the move that dbt-autofix leaves to you
To migrate a dbt Core project to Fusion on Snowflake, first clear every deprecation warning (including those introduced in v1.10), then run dbt-autofix, then hand-fix what it cannot rewrite. The dbt upgrade guide for Fusion lists clearing deprecations as a hard prerequisite, and it points to dbt-autofix as the tool that fixes many issues automatically. The remainder is dynamic SQL, custom configs and macro behavior, and that is where migrations stall.
Key Takeaways
- •Fusion requires you to clear all deprecation warnings first, including those introduced in dbt Core v1.10, per the dbt upgrade guide.
- •Fusion turns many silent behaviors into errors: misspelled configs, unknown YAML keys, nonexistent macros and unused config paths all fail.
- •dbt-autofix handles mechanical rewrites; dynamic SQL, custom configs and macro logic still need a human review.
- •On Snowflake, dbt Core 1.11.11 has dbt Labs active support until Dec 18, 2026, while 1.10.15 is listed as deprecated.
- •Fusion writes manifest v12, which dbt Core v1 can read, so state:modified, --defer and mixed-version runs keep working during a staged rollout.
Why the date pressure is real, and why it is not a cliff
The Snowflake documentation on dbt Core versions lists four versions: 1.12.3 (dbt Labs active support until Jul 15, 2027), 1.11.11 (active support until Dec 18, 2026), and 1.10.15 and 1.9.4, both shown as deprecated by dbt Labs. That is the source of the urgency: if you run dbt Projects on Snowflake on 1.10.15, you are on a version the vendor has already deprecated.
It is also worth reading the page carefully. It says Snowflake itself keeps supporting versions that dbt Labs has deprecated, and it lists no Snowflake decommissioning date for any dbt Core version. So your project does not stop running on a given day. What you lose is upstream fixes. The practical question is whether you take the small step to 1.11 or 1.12 now, or the larger step to Fusion.
We would treat these as two separate decisions. Moving to a supported dbt Core version is a low-risk patch. Moving to Fusion is a behavior change, because the engine validates your project far more strictly. When we read the Snowflake page, it listed only dbt Core versions, so check it again before you plan to run Fusion inside Snowflake's own runtime rather than from the CLI or your orchestrator.
Step 1: Clear deprecations on the version you already run
Fusion's upgrade guide is explicit that you should resolve all deprecation warnings before switching, including those introduced in v1.10. Do this on Core first. Run a full parse and a full build on your current version, collect every deprecation warning into one list, and fix them in small pull requests. This keeps the diff reviewable and lets you roll back one change at a time.
Behavior change flags matter here too. The guide says flags marked 2.0 are always on in Fusion and cannot be disabled in dbt_project.yml. If your project still sets one of those flags to the legacy value, you are depending on behavior that will not exist after the move. Search dbt_project.yml for every flags entry and decide, flag by flag, whether you can switch it to the new behavior today.
Step 2: Run dbt-autofix and read the diff
dbt-autofix is the dbt Labs repository for automated project rewrites, and the Fusion guide recommends it. Run it on a branch, never on main, and treat its output as a proposed change rather than a finished migration. The value is that it handles repetitive, mechanical edits across hundreds of YAML files that nobody wants to do by hand.
Its limit is that it rewrites what it can recognize. In our reading of the tool and the issue that prompted this post, it cannot fix dynamic SQL built with Jinja at runtime, and it cannot reason about custom configs your team invented. A rewrite tool works on structure, not intent. If a macro builds a config key from a variable, there is no static pattern for it to match, so it leaves the code alone and you will find the failure at parse time.
Review the diff with one question: did it change anything that affects materialization, grants or tests? Then rerun the full build and compare row counts for your gold models against the pre-migration run. A passing parse is necessary, but it is not proof that the output is the same.
Step 3: Fix what the tool cannot, using this table
| Area | What Fusion does differently | Who fixes it |
|---|---|---|
| Misspelled or unknown configs | Raise errors instead of being ignored, including unexpected YAML keys and unused dbt_project.yml config paths | dbt-autofix for known keys, you for custom ones |
| Nonexistent macros, generic tests, var() calls | Fail at dbt parse, not dbt compile | You |
| config.get('my_key') reading meta | No longer reads meta; use config.meta_get() and config.meta_require() | You, if the call is inside a macro |
| Code after return() in a macro | Ignored, with warning dbt1508 | You |
| Legacy CLI flags --models, --model, -m | Error; use --select or -s | Search your orchestrator and CI |
| Package version constraints | require-dbt-version must include 2.0.0 | You, plus package upgrades |
| Top-level YAML anchors | Standalone anchors must sit under anchors:; self-referential anchors fail | You |
These rows come straight from the Fusion upgrade guide's list of breaking differences. The pattern is consistent: things that used to be tolerated now fail loudly. That is good for correctness, but it means a project with years of accumulated configuration will surface many errors on the first parse.
The Snowflake-specific checks
On Snowflake, the guide lists supported authentication methods for Fusion: username and password, native OAuth, external OAuth, key pair (PKCS#8) and MFA. If your service accounts use a key format or a method outside that list, change it before the migration, not during it. Authentication failures look like model failures in CI logs, which wastes the first hour of every debugging session.
Threading changes as well. According to the same guide, on Snowflake and Databricks dbt manages parallelism automatically and the threads setting acts only as a cap. If you tuned threads to protect a warehouse queue, rerun your nightly job once and watch warehouse load, because the concurrency profile can change even when the SQL is identical.
Finally, check ordering. Fusion's build runs all unit tests first, then the rest of the DAG. Teams that relied on unit tests running alongside models may see a different timeline in their logs. Nothing is wrong, but your alerting thresholds on job duration may need an update.
Step 4: Stage the rollout with mixed versions
The guide states that Fusion writes manifest v12, which is compatible with dbt Core v1, and that the extra fields are ignored by v1. That means state:modified, --defer and mixed-version runs work. You can use this: keep production on Core, run Fusion in CI against the same manifest, and compare results for a few weeks before you flip the production job.
A sensible order is: CI parse on Fusion, CI build on a clone of production data, shadow run in a staging schema, then cutover for one low-risk project. Keep the rollback to a single config change. When Fusion's strict static analysis is a goal, note the guide says it requires dbt login and that unauthenticated runs fall back to baseline, where findings are warnings.
Where an agent helps, and where it should not act alone
The tedious parts of this migration are inventory and verification: listing every deprecation, finding every macro that reads meta, and comparing outputs across both engines. This is the work our Pipeline Agent is built for, running over the same dbt project through MCP from Claude Code or Cursor. Our OSS edition is read-only by default, so it can produce the findings list and the diff report without changing your repository.
We would keep the merge decision with a person. A fix to dynamic SQL changes what your warehouse executes, and the correct fix depends on intent that is not in the code. Let tools propose and compare; let an engineer approve.
Frequently Asked Questions
Does dbt-autofix migrate my whole project?
No. It handles mechanical rewrites it can recognize, and the Fusion guide describes it as fixing many issues, not all of them. Dynamic SQL and custom configs need review by hand. Treat its output as a first pass on a branch, and run a full parse and build afterward to find what remains.
Do I have to leave dbt Core 1.10 right now?
Not on a fixed day. The Snowflake page lists 1.10.15 as deprecated by dbt Labs but shows no Snowflake decommissioning date. The risk is missing upstream fixes, so moving to 1.11.11 or 1.12.3 is the cheap interim step, and Fusion can follow on your own schedule.
Can I run Fusion and Core side by side while I migrate?
Yes for most workflows. Fusion writes manifest v12, which Core v1 reads, so state:modified and --defer keep working. Run Fusion in CI against production state first, compare results, then switch the production job once the outputs match.