How to Build a Data Lakehouse in 8 Steps (2026 Build Guide)

The programmes I am asked to rescue are rarely wrong about the architecture. They are wrong about the order. Order is the whole discipline: invert two steps and you pay for the same work twice.

This is the build sequence — eight steps, each with an entry condition (what must be true before you start) and an exit condition (what "done" actually means). The sequence is not arbitrary: steps 1 and 5 are the ones most often skipped and the ones that decide whether the programme lands.

Step 1 — name the decision that changes and the metric that proves it. Interview the operating owner, not IT, and write one sentence: "we currently decide X on Y evidence, at Z frequency, and we want better evidence." Done is one page: one decision, one metric, one baseline number, one named owner, one review date. The most common failure is accepting "we need better visibility" as a decision — it cannot be tested, so nothing can ever be declared finished.

Step 2 — inventory the sources and secure real access. Get a real connection to SAP, Business Central, the WMS or the MES, and profile the actual data — Power Query's profiling defaults to the first 1,000 rows, so switch to "based on entire data set" because the first 1,000 rows of a sorted extract lie. Done is, per in-scope table: row count, null rate on join keys, distinct count on the business key, date range, confirmed change-capture method. The failure is access granted on paper only — a ticket says the service account exists; nobody has connected with it.

Step 3 — design the topology before you create a single item. Draw the workspace, domain, environment and role map; choose the Git provider and branching model (each workspace connects to one branch, so parallel development needs parallel workspaces). Done is an approved topology diagram, workspaces created and empty, Git connected, pipeline defined, roles assigned to security groups not individuals. The failure is building in one workspace "for now" — splitting layers later means moving items, reissuing permissions and repointing shortcuts, a fortnight that buys nothing visible.

Step 4 — land Bronze with replayability and source fidelity. Build ingestion and keep the original payload; Bronze holds no business rules, no deduplication, no renamed columns. Done is every source loading on schedule, a replay procedure documented and executed at least once, row counts reconciling to source. The failure is cleaning on the way in — trim whitespace and cast a date in Bronze and you can never prove what the source sent, the first step towards a data swamp with better branding.

Step 5 — resolve master data and agree metric definitions in writing. This is the critical path. Put the four versions of the same customer on a screen in front of the people who own them and agree which record wins; convert the Step 1 metric into a written specification — inclusions, exclusions, grain, time basis. This step needs Bronze loaded, because people concede a definition when looking at their own bad data and not before. Done is a signed specification and a mapping table per conformed entity — signed meaning a name and a date. The failure is deferring it to "the data quality workstream" and building Gold anyway; every measure built before definitions are agreed is rework.

Step 6 — build Silver with data-quality constraints and incremental processing. Apply the Step 5 rules in code: type casting, deduplication, referential integrity, UOM standardisation, master-data conformance — processed incrementally, with constraints declared in the pipeline (ON MISMATCH DROP or FAIL) not checked afterwards in a report. Done is incremental loads inside the schedule window, constraint-violation counts trended, an owner per rule. The failure is one Silver table per report request — that recreates the silo, invisible until the fourteenth table.

Step 7 — model Gold, build the semantic layer, and reconcile. Declare the grain as a sentence ("one row per delivery line per confirmation event") and refuse any measure that does not work at it; build the Direct Lake model and reconcile to the source system for a closed period. Reconciliation is a deliverable, not a test — a variance sheet finance signs, explaining every difference line by line. Where the numbers differ because the old report was wrong, say so. The failure is declaring victory on "close enough" — a 0.4% unexplained variance is not a rounding issue to a CFO, it is a reason to keep the old report.

Step 8 — serve, monitor, and retire the legacy report. Roll out with training, instrument capacity, freshness and adoption, and switch off the report the new one replaces. Retirement is the step that determines whether the programme succeeded. Never retire before the replacement is reconciled — that is how a programme loses its sponsor. Done is the legacy report switched off on a dated decision, usage of the new asset trending up, the Step 1 metric re-measured against its baseline. The failure is that nobody senior will make the retirement call, so both run in parallel indefinitely.

Six weeks is an honest effort range for one decision, one metric and one to two source systems — not a guarantee, and not a full estate.

The caveat: six weeks holds when Step 2 finds working credentials in week one and Step 5 has a decision-maker who will sign. Where a source needs a BASIS change window, or master-data ownership is genuinely contested, the realistic range stretches to 8–12 weeks for the same scope.

Step 5 cannot be compressed by tooling — master-data conformance is an organisational agreement rendered in code. Some decisions are cheap only in Step 4 — change data feed is not retrospective, and mirrored or shortcut data stays read-only. A six-week slice does not size a production capacity — pilot consumption says little about 200 users hitting a Direct Lake model at 08:30 on a Monday.

Step 8 depends on authority you may not have — if the legacy report's owner outranks the programme sponsor, retirement does not happen and the build becomes an expensive second opinion. And this sequence assumes one decision at a time — four parallel first slices to please four departments dilute the same engineers across four Step 5 arguments, and all four slip.

Answer these four this week, in writing:

• Which single operating decision changes if this data arrives daily instead of monthly — and who owns that decision?
• What is the current value of the metric that proves it, measured today, however imperfectly?
• Has anyone actually connected to each in-scope source with the service account, or does a ticket merely say it exists?
• Who has authority to switch off the report this replaces, and will they commit to a date before the build starts?

If the fourth question has no name against it, fix that before writing a line of code. We run these builds on Microsoft Fabric, OneLake and Power BI, with the reconciliation treated as a deliverable, not a test.