Moving a data warehouse to Databricks: what a one-week migration scan decides
The cost of leaving Oracle or SQL Server sits in code and dependencies, not table counts. What a migration scan measures, and why it allows a fixed price.
When someone asks what it costs to move an Oracle or SQL Server warehouse to Databricks, the quick answer is usually based on the number of tables and the volume of data. Both are easy to get and rarely decide the cost. The effort sits elsewhere: thousands of stored procedures, ETL jobs written in each database’s own SQL dialect, reports and applications that depend on one another, and the need to prove that the numbers after migration match the numbers before.
A one-week migration scan exists to measure those parts before anyone commits a budget. This article explains what the scan measures, which questions the tools cannot answer, and how the result is used.
What the tools measure
Databricks provides Lakebridge, a free toolset for warehouse migrations. It was launched in June 2025 and covers assessment, code conversion and reconciliation. Two components are used in the scan: the Profiler and the Analyzer. The other tools, for code conversion, data movement and reconciliation, are mapped in Databricks migration accelerators.
The Profiler runs against the source system and collects structure: schemas, table and object definitions, and operational data such as query execution times and resource utilisation. The operational data makes it possible to estimate Databricks running costs from the actual workload rather than from the current server configuration.
The Analyzer reads the SQL and ETL code exported from the source and produces a report in three parts:
- A complete inventory of jobs, procedures, views and reports.
- A complexity score for each object, used to estimate conversion effort.
- Dependencies across systems: which job reads which table, which report relies on which job.
The dependencies matter most. They decide the order of migration: a group of tables can only move when every job that writes to them and every report that reads from them moves at the same time or is handled in the interim.
The questions the tools do not answer
The tools measure code, not the organisation’s goals and constraints. The groups of questions that have to be answered in interviews are:
- The goal of the migration and the problem behind it: licence cost, performance, or analytics and AI needs the old system cannot meet.
- Which workloads move: ETL, BI reporting, ingestion, or all of them.
- Where data comes from, how often and how much per day, whether any sources are real-time, and how change data capture (CDC) is handled today.
- The preferred target data model, and how data currently flows through its layers.
- Acceptance: beyond unit tests, how long the two systems must run in parallel, 30, 60 or 90 days.
The last question is often skipped and has a large effect on cost. A 90-day parallel run means paying for both platforms for three months, with the team maintaining two data flows at once.
The result: a plan in waves, and a method per object
From the inventory, complexity scores and dependencies, the scan produces a plan split into waves. Each wave is a group of workloads that can be moved and put into production on its own, starting with those of high value and low risk.
For each group of objects, the plan sets the method:
- SQL and ETL code: automated conversion with rule-based converters, conversion with an LLM-based converter, or manual rewrite for code too specific to convert. The mix of the three drives most of the effort.
- Historical and ongoing data: Lakeflow Connect offers two kinds of connector, CDC-based to replicate changes continuously, and query-based where the source does not support CDC.
- Reconciliation: match criteria are agreed up front, covering schema, keys and how closely data must match (exactly, in aggregate, or within a tolerance). The reconciliation tool classifies differences as missing in source, missing in target, or mismatched, so acceptance rests on a report rather than a feeling.
Agreeing the reconciliation criteria during the scan is what makes each wave quick to accept. If the criteria are only discussed at the end, every small difference can turn into a debate.
Why a fixed price becomes possible
Once the number of objects, the complexity of each, the conversion method and the acceptance criteria are known, the effort for each wave can be estimated closely enough to quote a fixed price. What risk remains goes into a risk register, with how it will be handled if it occurs.
Without these measurements, the uncertainty has to be priced in some other way, for example by time and materials or with a contingency. Each is a reasonable way to price an unknown scope; the scan reduces the unknown before that choice is made.
Where Sancire comes in
Sancire’s Migration Scan takes one week and starts at $2,500. It delivers an inventory of objects ranked by migration effort, a plan in waves, a risk register and a fixed-price quote per wave. The fee is credited in full against a migration contract signed within 90 days. The migration itself sits in the Modernize stage.
Sources: Lakebridge documentation and Databricks migration solutions page, read on 28 September 2026. Lakebridge is changing quickly; check the current documentation for supported sources and converters before planning.