The date moved in March because someone counted tables.
A steering committee had a cutover weekend, a slide with a number on it, and a vendor who said most of the SQL would convert. Six weeks later the number was still the number, and the date was June, then September. The objects that did not convert were not a surprise to the people who lived in that warehouse. They had just never been written down.
That is the usual shape. Conversion is the part the tools are good at. Scope is the part that slips.
What we got wrong the first few times
We used to start with architecture: target catalogue, medallion layers, the ingestion path, a picture of Unity Catalog. It is satisfying work. It does not move a date.
The date moves when a downstream report nobody put on the list still points at a view that was supposed to be retired, or when a stored procedure hides a rule that three teams depend on, or when the security model on the source does not map onto Unity Catalog without a fight. Lakebridge will tell you what the SQL does. It will not tell you which wave that object can safely go in.
So we stopped opening with the target. We open with the estate as it actually is.
The first two weeks
We sell those two weeks on their own now, as the Migration Readiness Sprint. They run on Fabric Airlift, which composes Databricks Lakebridge for profiling, analysis, SQL conversion and reconciliation, then wraps that in a ledger: what was accepted into scope, which tool version produced each artifact, what evidence would prove it ready.
At the end you have:
- Every object dispositioned as in scope, excluded, or owned by a person
- The exclusions written down, so the scope still holds in month four
- A dependency map and a wave plan that respects it
- Parity criteria per object type, agreed before conversion runs
- A hard-object pilot, chosen as the thing most likely to break
- A go or no-go, with the reasoning shown
Some of those sprints say start next month. Some say the licence renewal you are trying to beat is a bad reason to move. We would rather tell you that in week two.
The residue is the work
Lakebridge converts a great deal of SQL. The residue is what a person still has to do, and it is different on every source.
On Snowflake it is Tasks, Streams, shares and the role hierarchy. On Azure Synapse it is dedicated SQL sitting next to Spark pools and an Azure Data Factory graph that does not import. On Teradata it is BTEQ, FastLoad, macros and primary indexes. We have executable playbooks for twenty-seven sources. Those three are the ones we are asked about enough to give them their own page.
If your source is Redshift or Oracle or SAP, the sprint is the same two weeks and the residue list changes. Tell us the source and we will say what the playbook covers today.
Cutover has to reverse
A wave cuts over only when its certificate is issued. The certificate is the gate, ahead of any status field in a tracker. Cutover itself runs as checkpoint, apply, verify, with a path back out of an external change, which is the part a risk function will actually sign. A long weekend with a rollback plan nobody has tested is the alternative, and we have watched that alternative fail.
A year ago this URL carried a five-step framework: assess, choose a pattern, mitigate, go live. All of it was true and none of it told you which of the four thousand objects were in scope. I am going to leave the warehouse-versus-lakehouse argument alone as well. The people who find this page already have a date, or a licence renewal, or a warehouse that has stopped paying for itself. The useful question is what the move contains.
If the source is already a decision, open the page for it. If it is not, start at the sprint. Bring the people who own the objects. The first conversation is with the engineer who will do the work.