Microsoft Fabric and Power BI architecture

Moving reporting onto Microsoft Fabric is an architecture decision before it is a migration project. The choices that matter are made early: how capacity is sized and shared, how workspaces are laid out, where the lakehouse boundary sits against your existing Clarity extracts, and which semantic models are shared versus owned by one team. Get those right and reports move over one at a time without surprises. Get them wrong and the capacity bill becomes the first thing leadership hears about Fabric.

What it covers

• Capacity and cost. Sizing, what actually consumes capacity units in a reporting workload, scheduling refreshes so they do not collide, and a monthly cost you can defend.
• Lakehouse and warehouse design. The ingestion path from existing extracts, bronze/silver/gold layering that matches how your data is really used, and what stays in the source.
• Semantic models. Shared models with clear ownership, incremental refresh, row-level security that mirrors your access rules, and a reuse strategy so the same measure is not rebuilt in ten reports.
• Workspace structure. Development, test, and production separation; deployment pipelines; naming that survives staff turnover.
• Report migration. Moving existing Power BI, SSRS, and Crystal content in an order that retires the old estate rather than duplicating it.

When to call

• Fabric capacity has been bought and nobody owns the architecture.
• Semantic models have multiplied and refresh windows are colliding.
• A Fabric pilot worked and now it has to become the reporting platform for the whole organization.

What you get

An architecture written down at the level a data architect can build from: capacity plan, workspace map, lakehouse layering, semantic model inventory with owners, and a migration order. The fixed-fee version of this work is Fabric Foundations; the ongoing version is Managed Fabric Administration.