Databricks is switching off the Terraform deployment engine for bundles in new releases of the CLI this month. If you deploy Declarative Automation Bundles, the migration to the direct engine has probably already happened to you, automatically, on a deploy you ran in the last week. This is what changed, how to tell which engine you are on, and the specific failure modes worth checking before the opt-out disappears.
What is actually happening
Bundles have had two deployment engines. The original one shells out to Terraform and keeps Terraform state. The direct engine talks to the Databricks APIs itself and keeps its own state in resources.json. Databricks has been moving everyone to the second one all year, and the last step is scheduled for this month.
The line that matters is on the "What's coming" page, identically worded on AWS and Azure: "The Terraform deployment engine will be disabled in new releases of the Databricks CLI in September 2026." That is not a deprecation warning. It is the removal.
| Release | What changed |
|---|---|
| v1.6.0 2 Jul | After a Terraform deploy the CLI began dry-running a migration to the direct engine, writing nothing locally or remotely, and reporting the outcome by telemetry. This is where Databricks started measuring how many bundles would convert cleanly. |
| v1.8.0 15 Jul | Auto-migration for anyone who had opted in with bundle.engine: direct, provided the post-deploy dry run came back clean. |
| 24 Jul | Workspaces began defaulting to the direct engine, which triggers an automatic migration for bundles in the workspace still on Terraform. |
| v1.11.0 6 Aug | The Terraform engine is formally deprecated. Setting bundle.engine: terraform now emits a deprecation warning. |
| v1.13.0 20 Aug | Resources only the direct engine supports, such as instance pools and catalogs, are skipped by the migrating deploy rather than failing it, and created on the next one. |
| v1.14.0 26 Aug | The big one. Bundles still on Terraform state are migrated automatically after any deploy whose dry-run conversion is clean. No opt-in required. |
| v1.15.0 3 Sep | Before committing that automatic migration, the CLI now runs a deployment plan against the converted state, and abandons the migration if the plan fails. |
| Sep 2026 | The Terraform engine is disabled in new CLI releases. |
Read that sequence and the shape of it is clear. Databricks shipped a silent dry run first, watched the telemetry, then turned on automatic migration once the numbers were good enough, and then, one release later, added a guard because automatic migration was committing conversions that did not work.
The v1.15.0 note is the tell. A plan check added a week after auto-migration went live, with the migration abandoned when the plan fails, means some bundles were being migrated into a state that could not deploy. If you upgraded the CLI between 26 August and 3 September and deployed in that window, you are the cohort that ran without that guard.
Which engine are you on right now
The direct engine keeps its state in resources.json in your bundle's workspace state path. Since v1.12.0 that file records the CLI version that last wrote it, in cli_version, which is more useful than it sounds: it tells you which of the fixes below your current state was written under, not just which CLI you happen to have installed.
The quickest check is a plan. On a bundle that has already migrated, databricks bundle plan should report no changes on a target you have not touched. If it wants to update fields you never edited, that is drift introduced by the conversion, and it is worth reading before you let a deploy apply it.
What actually breaks
The interesting content of this migration is not the mechanics, it is the list of things the direct engine got wrong and has been fixing at a rate of several per release. Each of these was a real bundle that stopped converging. If your configuration contains one of these shapes, check it explicitly rather than trusting a clean plan.
| Symptom | Shape that triggers it | Fixed in |
|---|---|---|
Edits silently ignored. The plan says 0 to change and the change is never applied. | Duration and timestamp fields, for example a Lakebase endpoint's suspend_timeout_duration. | v1.15.0 |
Deploy fails with invalid dependency. | $${...} used to escape a literal ${...}. | v1.15.0 |
| Job never converges. Every plan reports the same pending change. | A job with a table_update trigger. | v1.15.0 |
| Deploy fails parsing a resource reference. | ${resources...} pointing at a key that starts with an underscore, such as _my_job, combined with permissions or grants. | v1.14.1 |
Nothing to update, or a reported change that was never applied. | A field removed from the configuration of a schema, catalog, volume, registered model or external location. | v1.14.0 |
Permanent unconvergeable update on securable_kind. | A Unity Catalog TABLE securable declared under an app's resources. | v1.14.0 |
Spurious create on every plan. | An empty grants: [] list. Terraform recorded no resource for it, so the first plan after migrating invented one. | v1.11.0 |
| Pipeline never converges. | allow_duplicate_names: true. The API accepts it on write and never returns it, so every plan saw a difference. | v1.11.0 |
| Grants drift on every plan. | A principal granted ALL_PRIVILEGES where the backend also reports the concrete privileges. | v1.10.0 |
Two patterns run through that list. The first is fields the API accepts but never returns, which makes every subsequent plan see a difference and try again forever. The second is the empty and absent cases, where Terraform recorded nothing and the direct engine expects something. Neither is exotic. Both are the sort of thing you only find by deploying.
Worth noting separately: v1.10.0 turned two grant mistakes from warnings into errors. A grant missing a principal, or carrying an empty privileges list, now fails validation instead of deploying. That is the right call, but it means a bundle that deployed happily for months can start failing on an upgrade with no configuration change of your own.
Opting out, and why it is a stay of execution
You can still pin the old engine. Set engine: terraform under bundle in your configuration, or set DATABRICKS_BUNDLE_ENGINE=terraform in the environment. Either one stops the automatic migration.
Both have been emitting a deprecation warning since v1.11.0, and neither survives the September removal, because the engine they select will not be in the new CLI. Pinning buys you the time to test on your own schedule. It does not buy you a different outcome, and it stops working the moment someone on your team upgrades the CLI. If you pin, pin the CLI version too, or you have pinned nothing.
What to do this week
The useful version of this is short.
Run databricks bundle plan against production on your current CLI and read it properly, before any deploy. On an untouched target it should be empty. Anything it wants to change is either drift from a conversion that already happened or a difference the direct engine sees that Terraform did not.
Then check your configuration against the table above. The duration fields and the empty grants: [] case are the two most likely to be sitting in a real bundle without anyone noticing, because both fail silently rather than loudly: one applies nothing, the other adds a phantom resource to every plan.
Upgrade to at least v1.15.0 before you deploy anything you care about. That is the release that plans the converted state before committing to it, and it is the difference between a migration that fails safe and one that lands you in a state that cannot deploy.
Finally, if you have a bundle you have not deployed since August, deploy it somewhere disposable first. The auto-migration triggers on deploy, so an untouched bundle is an unexploded one. Better to find out on staging.
On the name. Databricks now calls these Declarative Automation Bundles. You will still see Databricks Asset Bundles and DAB in most of the tooling, the docs URLs and every blog post written before this summer. They are the same thing, and the CLI command is still databricks bundle.