advanced 2 min answer

Leadership wants to consolidate a warehouse, a data lake and three departmental marts into a lakehouse. How do you scope and sequence this?

data-platformmigrationlakehousestrategy
Show the full answer Hide the answer

Establish the actual driver

"Consolidate onto a lakehouse" is a solution. The driver is usually one of: cost of maintaining several copies, inconsistency between them, or an inability to serve a workload the current estate cannot. Each implies a different scope.

If the driver is inconsistency, the fix may be a semantic layer rather than a migration. If it is cost, the departmental marts may be the whole problem. Getting this wrong produces a two-year programme that delivers the same numbers on different infrastructure.

Assess by workload, not by platform

List the workloads that must run and their requirements: latency, concurrency, governance, and who runs them. Then ask which are genuinely served by a lakehouse.

The recurring finding is that finance reporting has a concurrency and predictability requirement that a lakehouse serves less well than a warehouse — and if that is not established up front, the outcome is a lakehouse plus a retained warehouse, which is more platforms than you started with.

The lakehouse case is strongest where the alternative is maintaining two copies with a synchronisation job between them, because that job is where the correctness and cost problems live.

Sequence

Wave 0 — the platform: storage layout, table format, catalogue, access control, compute separation per workload class. No data migrated.

Wave 1 — the data lake. Lowest risk, since it is already file-based and its consumers are engineers rather than reports.

Wave 2 — the departmental marts. Usually the largest cost saving and the least contested, because each has one owner.

Wave 3 — the warehouse, and only after the report inventory exists.

The inventory is the critical path

Build it from query logs, not by asking. Typically a third of reports have not run in a year, a small number account for most usage, and a long tail runs monthly or annually and will be missed by any sampling exercise.

Every report not migrated is work avoided, and "this has not run since 2024" makes that conversation short. Migrating everything because nobody would decide is how a two-year programme happens.