Databricks Migration Assessment Checklist

Moving a warehouse, Hadoop estate, or legacy Spark farm onto Databricks is a conversion program. The assessment is the part that prevents you from copying every stored procedure into a more expensive runtime.

1. Inventory what actually runs

• Jobs, stored procedures, ETL packages, notebooks, and SaaS extracts—with last-run evidence, not wiki pages.
• Tables and files with row counts, grain, and a suspected owner.
• Reports and applications that consume them, including the unofficial ones.

2. Classify, do not just list

Every workload should land in one of: convert as-is, redesign, retire, or park. “Park” is for things you cannot yet prove are unused. “Convert as-is” should be rare. Legacy logic often encodes business rules that should be made explicit in silver or gold rather than translated line-for-line.

3. Map dependencies and cutover risk

A table is easy. The overnight process that waits on it, the vendor extract that lands beside it, and the finance file that still joins on an old key are the migration. Draw those edges before you schedule wave one.

4. Define the target contracts

Name the Unity Catalog layout, environment strategy, and the bronze/silver/gold (or equivalent) contracts the converted workloads must obey. If the target is “a workspace with Delta tables,” you have a landing zone, not an architecture.

5. Agree validation before conversion

• Row counts and amounts at agreed grains.
• Late-arriving and restatement behavior.
• NULL, duplicate, and timezone handling.
• Who signs that a domain can cut over—and who can roll back.

6. Plan retirement explicitly

Dual-running forever is how you pay for two platforms. Each wave should include the date the source job is turned off, the owner of that decision, and the evidence required.

If nobody will own a report after cutover, it is a retirement candidate. Migrating orphaned content is how lakehouses inherit the last decade's clutter.