Fixed fee · Two weeks · A scope you can defend
Know what the migration contains before you commit to a date
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.
- Length
- Two weeks
- Who it is for
- Teams with a migration approved and a scope nobody can defend yet
- Bench
- 80 Databricks-certified engineers
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
- 01An inventory where every object is dispositioned as in scope, excluded, or owned by a person
- 02The exclusions written down and agreed, so the scope still holds when someone questions it in month four
- 03A dependency map and a wave plan that respects it
- 04A named owner against every workload surface
- 05Parity criteria per object type, agreed before any conversion runs
- 06A hard-object pilot, chosen as the thing most likely to break
- 07A go or no-go recommendation with the reasoning shown
What makes it faster
Fabric Airlift
The sprint runs on Airlift, our migration factory. The inventory, exclusions, readiness matrix and wave board it produces are the same ledger the migration itself runs on afterwards, so the two weeks are the first two weeks of the project rather than a document that gets rewritten.
FAQ
Questions about the Migration Readiness Sprint
Which source platforms does this cover?
Twenty-seven, each with an executable playbook rather than a general approach. Snowflake, Azure Synapse, Amazon Redshift, Oracle, Teradata, SQL Server, BigQuery, Netezza, Greenplum, Vertica, Hadoop, SAP and Db2 are the ones we are asked about most. 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.