1. Code: prefer Git
- Code already in Git folders (Repos): create Git folders in the target pointing at the same repositories (with a Git credential owned by a target identity). Nothing to copy.
- Code only in the workspace: commit it to Git first if possible; otherwise export/import:
databricks workspace export-dir /Workspace/Shared/etl ./export/etl -p src
databricks workspace import-dir ./export/etl /Workspace/Shared/etl -p tgt --overwrite
Exports keep notebook formats (source files); outputs and revision history are not migrated.
2. Jobs and pipelines → Asset Bundles
Generate bundle configuration from existing jobs and pipelines in the source:
databricks bundle init default-python -p src # once, creates a bundle project
databricks bundle generate job --existing-job-id 123456 -p src
databricks bundle generate pipeline --existing-pipeline-id abcd-... -p src
Then edit the YAML for the target:
- Replace cluster specs with job compute using target node types / policies.
- Replace
run_aswith a target service principal. - Replace paths (
/Users/old.user@contoso.com/...) and storage URIs. - Parameterise catalog names (
${var.catalog}).
databricks bundle deploy -t prod -p tgt
3. Everything else → Terraform exporter
The Databricks Terraform provider's exporter generates .tf files from a live workspace:
export DATABRICKS_HOST=https://adb-111.11.azuredatabricks.net DATABRICKS_TOKEN=...
./terraform-provider-databricks exporter -skip-interactive \
-services=jobs,compute,policies,pools,sql-endpoints,sql-queries,sql-dashboards,sql-alerts,secrets,access,notebooks,wsfiles,repos \
-listing=jobs,compute,policies,sql-endpoints -directory=./tf-export
(Service names vary by provider version; run with -help to list them.) Review the generated code, remove anything not needed, fix identities and paths, then terraform apply against the target. Commit it — from now on IaC is the source of truth.
4. Cluster policies, pools, warehouses
Recreate with Terraform from the export, adjusting node types and tags for the target subscription and region. Check quotas in the target subscription (vCPU per VM family) before deploying.
5. SQL queries, dashboards, alerts
- AI/BI (Lakeview) dashboards: export as
.lvdash.jsonfrom the UI or API and import in the target; or manage them in Asset Bundles (dashboardsresource). - Legacy dashboards and queries: migrate to AI/BI dashboards during the move (there's a built-in conversion), then export.
- Update the warehouse and catalog references.
6. ML assets
| Asset | Approach |
|---|---|
| UC registered models | Re-log or copy model versions into the target UC (download artifacts, mlflow.register_model in target) |
| Workspace model registry (legacy) | Migrate to UC models first, or use the open-source mlflow-export-import tool |
| Experiments and runs | mlflow-export-import (runs, params, metrics, artifacts) |
| Model serving endpoints | Recreate via API/Terraform after models exist |
| Feature tables (UC) | Migrate as normal tables, then re-create feature specs |
7. Validate
- Deploy to the target, run each job against copied test data, compare row counts and outputs with the source.
- Keep target jobs paused until the wave's cutover.
Tip
Don't migrate personal folders wholesale. Ask users to move what they need into Git or a shared folder; abandoned notebooks in
/Users/are usually 50% or more of the workspace.