Common Microsoft Fabric Implementation Mistakes (and How to Avoid Them)

The capacity is provisioned, the first lakehouse exists, a pipeline lands sales orders, and the first report looks better than the thing it replaced. It surfaces in month four: two people quote different revenue numbers in a management meeting; a report that was fast in the demo crawls at full data volume; nobody can name what is being done differently.

None of those are technology failures. They are decisions not taken in week two, surfacing as operational symptoms in month four. This is what goes wrong inside an implementation, and the week-two decision that prevents each.

Swapping the licence and keeping the model looks efficient — Power BI Premium becomes a Fabric F SKU, the workspaces move across, the semantic models come unchanged. It bites at the first invoice review, and again on licences: below F64, every consuming user still needs a Pro or PPU licence to view content. The correction: name one thing the estate can do after the move that it could not before — same-day OTIF by customer, scrap by shift within the hour. If you cannot name it, you are buying compute, not capability.

Starting with the platform, not the decision, is subtler and more expensive. Chartering the programme as "implement Microsoft Fabric" gives it no acceptance criterion, so it runs until the budget does. The correction: scope the first slice around a decision with a named owner, a cadence and a current failure mode — "the weekly S&OP meeting spends 40 minutes reconciling two demand numbers before it discusses anything" is a scope.

Copying the schema into the lakehouse: the SAP extract has 400 tables, so the lakehouse now has 400 Delta tables with the same names. Landing raw is correct for Bronze; carrying it into Silver and Gold is not — Microsoft's guidance favours star schemas, because snowflaked designs load more tables and traverse longer filter-propagation chains. The correction: scope Silver and Gold by artefact count (conformed dimensions and fact tables), not by source-table count.

A Gold table per report starts as helpfulness — a regional manager wants a slightly different view, so an analyst builds gold_sales_emea_v2 — and bites at the first board pack where two slides disagree. The correction: make Gold a governed layer with a named owner, where any new Gold table requires a rejected extension of an existing one; report-specific shaping belongs in the semantic model. And skipping metric definitions is the one that determines trust: if OTIF means requested date to three departments and confirmed date to a fourth, the platform faithfully produces four correct answers to four different questions. The correction: write the definitions before the pipelines — for each top-ten metric, numerator, denominator, exclusions, grain, owner and the date agreed.

No workspace and domain design: workspace creation can be open to the whole organisation, so by month four there are forty workspaces, a third abandoned. Two facts shape the design — a workspace belongs to only one domain at a time, and OneLake security's table/row/column roles are overridden by workspace Admin, Member and Contributor roles, which grant write access and therefore full read. So anyone made a Contributor to be helpful has full read on the data. The correction: restrict workspace creation to named security groups on day one, design the topology by layer and function (each medallion lakehouse in its own workspace), then map domains to business areas.

No environment separation, and no way back: everything built directly in the service, in one workspace, with no development copy. Fabric supports Git integration with Azure DevOps, GitHub and GitHub Enterprise at workspace level — but unsupported items in a connected workspace are not synced, so check your item types. The correction: connect Git before the second pipeline is built, not after the first Friday-afternoon incident, and stand up development, test and production workspaces at the start — three workspaces cost nothing to create and are painful to introduce once reports have live consumers.

Direct Lake designed without checking the conditions: the demo runs on six months of data and is fast; production runs on four years and is not. The unsupported list catches mature Power BI estates every time — calculated columns and tables that reference Direct Lake tables, user-defined hierarchies and aggregations, binary and GUID types. Direct Lake on SQL falls back to DirectQuery on SQL views and SQL-based access control; Direct Lake on OneLake fails rather than falls back once a guardrail is crossed. The correction: before signature, count the semantic models containing calculated columns, calculated tables, user-defined hierarchies or aggregations — that count is the rework estimate.

Capacity monitoring that starts at the first throttling incident: Fabric smooths (interactive over a minimum of five minutes, background over 24 hours), then throttles in stages, so reports get slower, then some fail, then everything fails — usually at month-end when load peaks. The correction: name a capacity owner with a weekly review before go-live, and set surge-protection thresholds so background rejection triggers before deep throttling and workspace-level CU ceilings so one workspace cannot monopolise the capacity.

The source-of-truth mistake is not technical: nobody switches off the old report because nobody has authority to tell finance to stop using it, so two numbers circulate indefinitely. The correction: make decommissioning a dated deliverable with an evidence test — typically one reconciled monthly close — and a named person who signs it off. Without that signature the migration has not finished, whatever the burndown chart says.

Master data has the same shape: the cleanse happens once during the build, three spellings of one supplier are merged, everyone moves on, and within a quarter there are three again because nothing changed at the point of entry. The correction: name an owner per domain — supplier, customer, material, plant — with a monthly duplicate report and authority to merge. It is an operating routine, not a project task.

Avoiding every mistake here does not make the programme succeed — these are failure modes, not a method. Several corrections are only cheap before you need them: workspace topology, Git and environment separation cost days at the start and weeks in month six, because moving items between workspaces breaks downstream references. Metric definitions cannot be settled by the data team — if the Commercial Director and the CFO genuinely disagree about what a sale is, no workshop resolves it.

Direct Lake guardrails move — row and memory limits are per-SKU and Microsoft revises them, so check them at design time. Capacity discipline does not fix an inefficient Silver layer — surge protection contains the symptom, not the cause. And none of this survives an absent sponsor: every correction needs someone with authority to say no — to a new Gold table, to an open workspace, to keeping the legacy report.

Five questions to answer this week:

• Which single operational decision will be made differently once this is live, and who makes it today? If nobody can answer, the scope is a platform, not an outcome
• How many workspaces exist right now, and can you name an owner for each? Over about fifteen with no owner list means topology work before more build
• Is anything connected to Git, and could you restore last Tuesday's version of your most important pipeline in ten minutes?
• How many semantic models contain calculated columns, calculated tables, user-defined hierarchies or aggregations? That number is your Direct Lake rework estimate
• Which three metric definitions are currently disputed between departments, and who has authority to settle each?

We run Fabric implementations on a fixed-scope basis after a short paid discovery, largely so these decisions are forced into week one where they are cheap.