Home / Data Platform / Databricks & Spark

Data PlatformRunbookAdvanced

Databricks tenant migration cutover runbook: final sync, switch, validate and decommission

The cutover steps for one migration wave from a source Databricks workspace to the target tenant. Covers pre-checks, freezing the source, final data sync, enabling target jobs, switching consumers, validation, rollback and decommissioning the source.

Deepak Bhardwaj3 min read

Applies toAzure Databricks and Databricks on AWS/GCP tenant or account migrations

T-minus checklist

When Task
T-14 Parallel run passing: target jobs on copied data, outputs match within tolerance
T-7 Identities, grants and secrets verified in target; consumer list confirmed
T-3 Data copy rehearsal timed; rollback plan signed off
T-1 Change freeze on the wave's code; comms to users and consumers

Cutover steps

  1. Pause source jobs and pipelines for the wave (keep a list):
for id in $(cat wave3_job_ids.txt); do
  databricks jobs get $id -p src --output json | jq '.settings.schedule.pause_status = "PAUSED" | {job_id: .job_id, new_settings: .settings}' > /tmp/j.json
  databricks jobs reset --json @/tmp/j.json -p src
done

Also stop streaming queries and DLT continuous pipelines cleanly.

  1. Freeze writes: confirm no running jobs (databricks jobs list-runs --active-only), revoke MODIFY on the wave's schemas in the source.
  2. Final data sync: incremental copy / MERGE (see the data migration post); record the end time.
  3. Validate counts and hashes on every table in the wave.
  4. Streaming: start target streams from the right point (new checkpoints; use startingVersion/startingTimestamp or source offsets — never copy checkpoints between workspaces).
  5. Unpause target jobs (Asset Bundles target with schedules enabled):
databricks bundle deploy -t prod -p tgt --var="pause_status=UNPAUSED"

(pause_status is a bundle variable you define and use in each job's schedule.pause_status, deployed as PAUSED until this step.)

  1. Switch consumers: Power BI datasets and gateways to the new SQL warehouse hostname/HTTP path; ADF linked services; APIs; Delta Sharing recipients (new shares from the target); ODBC/JDBC DSNs.
  2. Smoke tests: one run of each critical job; key dashboards refresh; data freshness checks.

Go/no-go

Point No-go if
After final sync Any critical table mismatch
After first target job runs Critical job fails and can't be fixed in the window
After consumer switch Executive dashboards or regulatory feeds broken

Rollback

Until the first target job writes, rollback = unpause source jobs and re-grant MODIFY. After target writes, rollback requires syncing changes back — decide the point of no return in advance.

Hypercare (1–2 weeks)

  • Daily: job failures, SLA misses, PERMISSION_DENIED in system.access.audit, cost per day vs source.
  • Office hours for users; a channel for issues.

Decommission the source

  1. Keep source read-only for the agreed period (for example 30 days).
  2. Export what must be retained: audit logs, job run history, lineage (system.* tables) to storage.
  3. Delete or revoke: jobs, clusters, warehouses, tokens, service principals, secret scopes, Delta Sharing recipients.
  4. Delete the workspace; remove storage only after data-retention sign-off.
  5. Remove network peering, private endpoints and DNS records.

Tip

Cut over by domain or team, not all at once. Small waves keep the rollback simple, and each wave makes the next one faster.