# Migration Readiness Sprint

> Most warehouse migrations are estimated off a table count and an optimistic view of how much of the SQL converts cleanly. Two weeks later the scope is the same size and the date has moved twice. This sprint inventories the estate, writes down what is coming and what is being left behind, and hands you a wave plan you can put in front of a steering committee.

For: Teams with a migration approved and a scope nobody can defend yet
Length: Two weeks
Canonical: https://www.techfabric.com/databricks/migration-readiness

---

Know what the migration contains before you commit to a date

## What we inspect

- Every object in the source estate, profiled against the live workload where we can reach it
- Dependencies between objects, and the downstream consumers nobody put on the list
- Which code deterministic conversion will handle, and the residue that will need a person
- Data volumes, and the transfer and catch-up window each one implies
- The security model as it stands today, and what it maps to under Unity Catalog
- Schedules, triggers and external systems that have to move in step with the data

## What you get

- An inventory where every object is dispositioned as in scope, excluded, or owned by a person
- The exclusions written down and agreed, so the scope still holds when someone questions it in month four
- A dependency map and a wave plan that respects it
- A named owner against every workload surface
- Parity criteria per object type, agreed before any conversion runs
- A hard-object pilot, chosen as the thing most likely to break
- A go or no-go recommendation with the reasoning shown

## Questions

### Which source platforms does this cover?

Twenty-seven, each with an executable playbook rather than a general approach. Snowflake, Azure Synapse and Teradata have their own pages at /databricks/from-snowflake, /databricks/from-synapse and /databricks/from-teradata. Redshift, Oracle, SQL Server, BigQuery, Netezza, Greenplum, Vertica, Hadoop, SAP and Db2 are the ones we are asked about next. Kafka, Event Hubs and Kinesis are covered where streaming has to move with the estate.

### We already have a migration plan. What does this add?

Usually the dependency map and the exclusions. Plans tend to be strong on the target architecture and thin on which of the four thousand objects are genuinely in scope, who owns them, and what happens to the ones that will never convert. That is the part that moves dates.

### How is this different from running Lakebridge ourselves?

Lakebridge does the profiling, analysis and conversion, and we run it rather than replacing it. What the sprint adds is the ledger around it: a record of what was accepted into scope, which version of which tool produced each artifact, and what evidence would prove it ready. Lakebridge tells you what your SQL does. It does not tell you which wave it can safely go in.

### Does the sprint commit us to the migration?

No. It is fixed fee and it ends with a recommendation. Some of them say the estate is smaller than you feared and you should start next month. Some say the licence renewal you are trying to beat is not a good enough reason to move an estate this tangled, and we would rather tell you that in week two.

### Who from your side is in it?

A senior data engineer who has run migrations off your source platform, and an architect. They are in the first conversation because they are doing the work, and they are the ones who present the findings.