dbt drops v1.3 to v1.7 from its platform on January 31, 2027: get pinned jobs onto a release track before they're deleted

On January 31, 2027, dbt Labs removes dbt v1.3 through v1.7 from the dbt platform. Any environment or job still pinned to one of those versions gets cleaned up once they're retired, and for most legacy environments that means deletion. Find your pinned environments this week and move them to a release track, ideally v2 Stable, before the holidays eat December. dbt says your code and history stay accessible while you migrate, but it also warns that projects not moved by then lose access. Don't wait to find out which applies to you.

Nothing breaks in your warehouse on February 1. The tables dbt already built are still there. What stops is the rebuild, so the numbers on the dashboards quietly freeze at the last good run, and the first person to notice is often someone in finance asking why yesterday's sales are missing.

These versions aren't patched anymore. v1.7 came out in November 2023, and dbt supports a minor version for one year, so every one of them has gone without bug fixes or security patches for a while. The deadline turns an old risk into a hard date with a real consequence: if nobody acts, jobs disappear.

For engineers: dbt decides what to migrate by each job's effective versiondefinitionThe dbt version a job actually runs: its own override if one is set, otherwise the version of the environment it belongs to.. That's the version pinned on the job if it has an override, and the environment's version if it doesn't. So a supported environment can still hold one forgotten job with a v1.6 override, and that job is the one that vanishes.

The platform is moving everyone onto release tracks. A release trackdefinitionA dbt platform setting that keeps an environment on a supported dbt version automatically, on a chosen cadence, instead of a pinned version number. is a setting that keeps you on a supported dbt automatically, on a cadence you choose. You stop pinning old version numbers. dbt Labs' own guide calls v2 the recommended target and a v1 release track the minimum to keep jobs running.

Your choice of target matters more than the switch itself. On v1 Latest you get every change continuously. v1 Compatible follows the open-source v1 releases once a month, and v1 Extended runs a month behind that. Enterprise+ adds a Fallback track one month further back, for emergencies. The v2 tracks follow the same pattern with Nightly, Stable, Extended and Fallback.

If you're touching every environment anyway, dbt Labs says go straight to v2. There's a catch, though. The v2 upgrade assistant only works once a project is already on the v1 Latest track, and v2 won't accept any deprecated code at all. In practice the path for an old project usually runs through v1 Latest first, even when v2 is the goal.

Pick by adapter and by deadline. A Snowflake or Databricks project with current packages and few warnings is a good candidate to go straight to v2. A project on an adapter that's still in preview for v2, or one with years of old syntax and abandoned packages, should land on v1 Latest first and plan v2 for the spring. Both options meet the deadline.

Running both engines side by side is less risky than it sounds. dbt v2 writes a v12 manifest that v1 can read, so state:modified, --defer and cross-environment docs keep working when dev is on v2 and production is still on v1. You can move one environment at a time.

dbt promises that minor versions don't break documented behaviour, but four years of minors add up. dbt's upgrade pages list the edge cases that bite projects coming from v1.3 to v1.6, and the community forum fills in the rest.

The flags are the quiet one. A project jumping from v1.7 to v1 Latest skips the releases where those flags were optional, so it lands with most of the new behaviour already switched on. Read the behaviour-change table and set any flag you need to keep in the flags block of dbt_project.yml. v2 removes several of them for good, so keeping an old behaviour only works on v1.

If you also run dbt Core on laptops or CI runners, check the network. One team on the dbt forum reported dbt deps failing with handshake errors after moving from 1.7 to 1.8, until hub.getdbt.com was allowed through the firewall.

# List every deprecation, not just the first of each kind
$ dbt parse --no-partial-parse --show-all-deprecations
# Let dbt-autofix fix what it can. It edits files, so stay on a branch
$ uvx dbt-autofix deprecations
$ uvx dbt-autofix jobs
# Prove the build works without reading real data
$ dbt build --empty
# Then open a run's System Logs: the first line, 'Running with dbt=', shows the version it used

This deadline is painful because the projects sat still for years. The fixes that keep it from happening again are mostly about cadence and visibility.

These are illustrations of common setups, not Cohash client stories. Your own project will mix them.

We take inventory of dbt platform accounts, find the effective version of every job, and move projects onto release tracks with your team. We clear deprecations, rehearse production jobs and compare results before cutover, and plan the v2 move where it makes sense. See our dbt practice, hire dbt engineers, or start with a readiness assessment.