Microsoft Fabric: the build-or-wait decision, with the cases where the answer is wait

Microsoft Fabric is a real platform improvement and a real way to spend money quickly. Which of those you experience is decided in the first fortnight, by whether anyone profiled the workloads before the capacity was purchased.

We have recommended Fabric and we have recommended against it, in roughly equal measure. This is the framework we use.

The five conditions

Fabric earns its place when several of these are true at once. One alone is rarely enough.

1. Data volumes strain an import model. Not "the model is 400 MB and refresh takes twenty minutes". That is fine. This means refresh no longer fits the window even with incremental refresh properly partitioned.
2. You need both SQL and notebook access to the same data. Analysts in T-SQL and data scientists in Python, over one copy, without a nightly export between them. This is the thing Fabric genuinely does better than the alternatives.
3. Several teams need governed self-service. Domains, workspace boundaries and shared gold tables are easier to manage inside one platform than across a warehouse, a lake and a reporting tool with three security models.
4. Retention obligations measured in years at event grain. Keeping three years of event data in Delta on cheap storage costs a fraction of keeping it in a semantic model, and some sectors have no choice.
5. You already pay for Premium capacity. The commercial step to Fabric is then small, and the features arrive with it.

If you read that list and recognise nothing, the honest recommendation is to stay where you are and revisit in a year. We put that in writing, because it is the recommendation most likely to be doubted.

Where the answer is specifically "wait"

Medallion architecture that actually works

Assuming the answer is yes, the architecture is unglamorous and the discipline is everything. The medallion pattern (bronze, silver, gold) is routinely implemented badly: a bronze layer that already lost fidelity, a silver layer with no testable rules, and a gold layer that is the silver layer with different column names.

Bronze holds raw extracts at source grain with ingestion metadata, append-only and replayable for any date. No business logic. Retention set against your actual obligation rather than kept forever by default. The test of a good bronze layer: you can reproduce yesterday's gold tables from it after a source system backfills.

Silver holds conformed, deduplicated, type-safe entities with agreed business keys. Every transformation testable, with data quality assertions that block promotion on failure rather than logging a warning nobody reads.

Gold holds dimensional models ready for analytics: one definition per measure, documented, with changes going through review.

Semantic is the Direct Lake or import model serving reports. The rule we enforce: no business logic in the semantic layer that is not also in gold. Otherwise the gold layer stops being authoritative and you have rebuilt the problem you were escaping.

The layer contract matters more than the technology choice. Who may write to silver, who approves a new gold table, who is on call when a pipeline fails at 04:00, write those three answers down before the estate grows, because Fabric makes it trivial for anyone with a workspace to create anything.

Direct Lake, honestly

Direct Lake lets a semantic model read Delta files in OneLake directly: no import refresh, no DirectQuery round trip. On large, frequently landing tables it is genuinely excellent.

The catch is fallback. Certain constructs are unsupported in Direct Lake mode, and when the engine meets one it falls back to DirectQuery against the SQL endpoint. Performance then depends on that endpoint rather than on the in-memory engine, and you have Direct Lake expectations with DirectQuery behaviour, which is worse than having chosen DirectQuery deliberately.

So: test it. Build the same model both ways on your own data, measure both, and choose on the numbers. In our experience Direct Lake wins on large fact tables that land frequently, and import still wins on smaller models with heavy DAX. A vendor benchmark tells you nothing about your model.

Two operational details that get missed:

• V-Order and framing. Delta tables benefit from V-Order write optimisation, and Direct Lake models reframe when underlying files change. Understand when reframing happens, or users will see data appear at times you did not predict.
• Table maintenance. OPTIMIZE and VACUUM on a schedule, not for the first time when queries have already degraded. Small-file proliferation is the most common cause of a lakehouse getting slower for no apparent reason.

Capacity sizing from measurement, not headcount

Capacity units are consumed by interactive queries and by background operations such as refresh, and Fabric smooths and bursts consumption over time. The practical consequence: a capacity can look comfortable for weeks and then throttle at month end, when every finance user opens the close pack within the same hour.

How we size:

1. Catalogue each workload with volume, latency requirement, concurrency and consumer type.
2. Classify compute shape: background refresh versus interactive query, and when each peaks.
3. Validate on a short-lived trial capacity with real data, watching the Capacity Metrics app.
4. Produce a sizing model stating utilisation at launch, at double the readers, and the specific point at which the next SKU becomes necessary.

That last point is what lets a finance director approve the purchase, because it converts an open-ended commitment into a known step function. On the licensing arithmetic itself, including why F64 is the SKU that matters, see Power BI licensing in 2026.

Migration without a flag day

Almost nobody starts from nothing, and big-bang cutovers are the pattern that produces the rollbacks we get called in to repair. Two routes work:

Serving-layer-first. Fabric takes the gold layer and reporting; existing engineering stays where it is, with shortcuts or mirroring giving Fabric read access in place. Lowest risk, fastest value, and it defers the harder decision until you have evidence.

Domain-by-domain. One business domain moved end to end at a time, with the old platform retained until that domain is validated. Slower, but appropriate where the existing platform is genuinely at end of life.

Either way: landing zone and standards first (workspaces, domains, capacities, security groups, naming, deployment approach), then one reference pipeline taken end to end as the pattern everything copies, then scale-out. Standards retro-fitted in month four cost more than they would have in week one.

What goes wrong, in order of frequency

1. Capacity bought before workloads were profiled, then throttling at month end with no headroom analysis to point at.
2. Aggregation at ingestion to save storage, destroying the ability to investigate the specific event someone will eventually ask about.
3. Delta maintenance never scheduled.
4. No ownership contract between layers, so duplicate gold tables accumulate and nothing can be retired.
5. Direct Lake adopted without testing fallback behaviour.
6. Retention set by default rather than by obligation, expensive where rules require years of history, wasteful where they do not.

Every one of those is avoidable in the first fortnight and expensive afterwards.

The two-week test

If you are genuinely unsure, a workload assessment answers it with evidence in two to three weeks: every candidate workload catalogued, compute shape profiled, costs modelled both ways, and a written recommendation that may well be to wait. It is a fixed fee, and the document is yours whatever you decide.

Workspaces, domains and the layout you will live with

The tenancy layout is the decision you cannot easily reverse once a few hundred items exist, and it is usually made in the first week by whoever created the first workspace.

What we settle before anything is built:

• Domains mapped to business areas, not to IT teams. A domain called "Finance" survives a reorganisation; one called "BI Team 2" does not.
• Workspace per environment per domain (Finance Dev, Finance Test, Finance Prod) with deployment pipelines connecting them. Mixing environments in one workspace means production changes happen by accident.
• A separate workspace for shared gold artefacts that several domains consume, with tighter write access than read access.
• Naming conventions written down before the first item, including what goes in an item description. Retro-fitting names across 400 items is a week nobody budgets for.
• Capacity assignment per workspace, so a development workload cannot consume the production capacity. This is the control that prevents a notebook from throttling the board pack.

Who operates it afterwards

Fabric makes it trivial for anyone with a workspace to create a pipeline, a lakehouse or a warehouse. That is a genuine productivity gain and a genuine governance problem, and the difference is whether operational ownership was defined before the estate grew.

Three questions, answered in writing:

1. Who may promote to production? A named role, enforced through deployment pipeline permissions rather than convention.
2. Who is on call? Pipeline failures happen overnight. Either someone is accountable for the 04:00 failure or users are the monitoring system.
3. Who approves a new gold table? Without this, the gold layer accumulates near-duplicates and nothing can ever be retired, which is the lakehouse version of the report sprawl everyone migrated to escape.

The objections we hear, answered

"We will lose flexibility compared with Databricks." For heavy engineering, possibly. That is why serving-layer-first adoption exists: keep Databricks for engineering, use Fabric for the governed serving layer, and revisit on evidence rather than on principle.

"Our data is too sensitive for a shared capacity." Capacity is compute, not a shared data boundary. Security is governed by workspace permissions, row-level security and sensitivity labels, which apply the same way regardless of SKU. What matters instead is residency and processor chain, which is a per-region, per-service answer, covered on the locations pages.

"We just bought Synapse." Then keep it. A dedicated pool with tuned distributions and stable costs is an asset, and re-platforming it to tidy an architecture diagram is not a business case. Surface it through Power BI or Fabric and spend the money on something that changes a decision.

"Fabric changes too fast to build on." It does change fast, and that is a real operational cost: an architecture decision from last year may now be wrong. We handle it with a quarterly architecture review rather than by waiting, because waiting for a Microsoft platform to stop changing is waiting forever.

That is what we would do before spending five figures a year on a capacity, and it is what we would want someone to do for us. Book a technical review if you want it done on your estate.