# Legacy Data Warehouse to Lakehouse Migration: What Actually Changes
A legacy-warehouse-to-lakehouse migration changes three things at once: where data physically lives (open file formats like Delta or Parquet on cloud storage instead of a proprietary warehouse engine), how compute is billed (separated from storage and scaled independently, instead of bundled), and who can use the data (both SQL analysts and ML workloads read the same tables, instead of maintaining a separate warehouse and data lake). It is not a lift-and-shift of existing tables into a new engine.
## Why organizations make this move
A traditional warehouse forces a choice: structured, governed, fast for BI — but a poor fit for unstructured data, ML training sets, or anything that doesn't fit rows and columns cleanly. A data lake solves the second problem but usually loses the governance and query performance of the warehouse. A lakehouse (Delta Lake on Databricks, or the OneLake model in Microsoft Fabric) is the attempt to keep both properties on one copy of the data.
The practical trigger is usually one of:
- BI and ML teams maintaining separate, drifting copies of the same data
- Warehouse compute costs scaling faster than actual query volume, because compute and storage are bundled
- A new AI or analytics initiative that needs governed access to data currently locked in a warehouse-only schema
## What changes architecturally
| Layer | Legacy warehouse | Lakehouse |
|---|---|---|
| Storage format | Proprietary, warehouse-native | Open (Delta / Parquet) on cloud object storage |
| Compute | Bundled with storage, scales together | Decoupled — scale compute independently, pause when idle |
| Schema enforcement | Enforced at write, rigid | Enforced at write with schema evolution support |
| Consumers | SQL/BI tools only | SQL/BI, notebooks, and ML training in the same layer |
| Access pattern | Table-level | File- and table-level, versioned (time travel) |
## Sequencing the migration without downtime
The riskiest way to do this migration is a single cutover weekend. The pattern that actually works runs the source system live until the target reconciles:
1. **Land raw data in the lakehouse alongside the existing warehouse** — no source system changes yet, this is additive.
2. **Rebuild transformations against the new layer**, validating output against the existing warehouse tables row-for-row on a sample, then in full.
3. **Dual-run reporting** — point a subset of dashboards at the new layer while the warehouse stays authoritative, and compare outputs over a real business cycle (a full month-end close, not a day).
4. **Cut over consumers incrementally**, starting with the lowest-risk reports, only after reconciliation holds.
5. **Decommission the legacy warehouse** once nothing reads from it — verified by access logs, not assumption.
## The part most migrations get wrong
Teams underestimate governance re-platforming: row-level security, column masking, and audit logging that existed in the warehouse engine natively often need to be rebuilt explicitly in the lakehouse (via Unity Catalog on Databricks, or OneLake security in Fabric). Skipping this step is how a migration ships technically complete but fails a compliance review months later — this is precisely where DPDP-relevant access controls have to be re-verified, not assumed to carry over.
Migrate the governance model deliberately, not as an afterthought to the data movement.
Frequently Asked Questions
Is a lakehouse migration a lift-and-shift?
No. It changes storage format (open formats like Delta/Parquet instead of a proprietary warehouse engine), compute billing (decoupled from storage instead of bundled), and who can read the data (SQL and ML workloads on the same tables). Treating it as a lift-and-shift is the most common way these migrations fail.
Can the migration happen without downtime?
Yes, by running the legacy warehouse live while the lakehouse is built and reconciled in parallel, dual-running reports for a full business cycle before cutover, and decommissioning only once access logs confirm nothing still reads from the old system.
Ready to transform your data infrastructure?
Let's discuss how these insights apply to your organization and create a roadmap for your data transformation journey.