Most of the companies I work with run on SQL Server, SSIS and Power BI, and they ask the same question about Microsoft Fabric: is this a migration we have to do, or a product we can ignore? The honest answer is neither. Fabric reorganizes the pieces you already have around one storage layer. The skills carry over. The decisions about what to move, in what order, and what it will cost in capacity are where the work is.
What Fabric actually is
Microsoft describes Fabric as a software-as-a-service analytics platform that unifies data movement, data engineering, data science, real-time analytics, warehousing and business intelligence on a shared storage layer called OneLake [1]. For a SQL Server team the mental model is: OneLake is the single storage account; a lakehouse is a Delta-table folder you query with Spark or T-SQL; a warehouse is a T-SQL-first relational store on the same lake; Data Factory is the pipeline tool; and Power BI is the same Power BI, with a new storage mode.
| You have today | Fabric equivalent | What changes |
|---|---|---|
| SQL Server data warehouse | Fabric Warehouse or Lakehouse (gold) | Storage is Delta/Parquet in OneLake; T-SQL stays [2] |
| SSIS packages | Data Factory pipelines and Dataflow Gen2 | Same control-flow ideas; Power Query for transforms [3] |
| Nightly full extracts from the ERP | Mirroring | Continuous replication of SQL Server tables into OneLake as Delta [4] |
| Power BI Import models | Direct Lake models | Model reads Delta tables from OneLake into memory on demand; no scheduled import [5] |
| SQL Agent jobs and alerts | Pipelines schedules and Activator | Event-driven alerts on data conditions [6] |
Lakehouse or warehouse?
A lakehouse combines data-lake storage with SQL querying: structured and unstructured data in one place as Delta tables, analyzed with Spark and T-SQL through a SQL analytics endpoint [7]. A Fabric Warehouse is an enterprise-scale relational warehouse on the same lake foundation, with full T-SQL including multi-table transactions [2]. The practical rule for a SQL Server team: if your transformation logic is T-SQL stored procedures and your team does not write Python or Spark, start with the Warehouse for silver and gold and let the lakehouse hold bronze. If you have notebook skills or need semi-structured data, the lakehouse can carry all three layers.
The medallion design, with a SQL Server accent
Microsoft’s medallion guidance organizes data into bronze (raw, as received), silver (validated, deduplicated, conformed types) and gold (modeled for consumption, typically a star schema) [8]. For a SQL Server shop this maps cleanly:
- Bronze: mirrored ERP tables and landed files. No transformation; retention as audit evidence.
- Silver: the staging schema you already have, rewritten as T-SQL in the warehouse or as notebooks: type casting, key resolution, deduplication, data-quality flags.
- Gold: the dimensional model (see dimensional modeling in 2026), with surrogate keys and slowly changing dimensions, stored as Delta tables the semantic model reads directly.
Direct Lake: the reason Power BI teams care
Direct Lake is a storage mode in which a Power BI semantic model loads Delta table data from OneLake into memory on demand, giving import-like interactive performance without an import refresh and without the query-per-visual latency of DirectQuery [5]. Two consequences matter. First, the refresh window problem (the overnight import that takes four hours and fails at 5 a.m.) goes away; the model reflects the gold layer when the gold layer changes. Second, Direct Lake has guardrails: row counts and file counts per table, and operations that fall back to DirectQuery when a table exceeds them [5]. Keep gold tables tidy (compacted, partitioned sensibly, V-Order where appropriate) and the fallback never triggers.
Mirroring SQL Server: the lowest-risk first step
Mirroring continuously replicates data from external databases into OneLake as analytics-ready Delta tables, with the replicated storage not counted against capacity in the way compute is [4]. For a team that currently runs nightly extracts from SQL Server, mirroring the operational tables into bronze is the smallest change with the largest effect: the ERP stops being queried for reports, the lake has near-current data, and the existing SSIS logic can be ported one package at a time against the mirrored copy. Check the supported platforms and prerequisites for your SQL Server version before promising this; the mirroring documentation lists them [4].
The traps
- Capacity is the budget. Fabric is licensed by capacity units, and every workload (pipelines, Spark, warehouse queries, Direct Lake loads) consumes them. Size a trial on a real workload, watch the capacity metrics app, and plan for bursts at month-end. A free trial requires a work or school account; some features (data agents, for example) require paid capacities above a minimum size [9].
- Lifting SSIS as-is. Packages that do row-by-row lookups will be slow and expensive in any lake. Rewrite as set-based T-SQL or Dataflow Gen2 with staged merges.
- No gold layer. Pointing Power BI at silver tables “for now” is how a lakehouse becomes a swamp. Model gold before the first report ships.
- Security assumptions. OneLake security, workspace roles and semantic-model RLS are three different layers. Design which one enforces what, then test as a viewer, not as an admin [10].
- Preview features in production plans. Fabric ships fast and many features are preview at any time. Build the critical path on generally available features and keep a list of the previews you depend on.
A 90-day adoption plan for a SQL Server team
- Weeks 1–2: trial capacity, one workspace, mirror the three most-reported ERP tables into a bronze lakehouse. Measure capacity consumption daily.
- Weeks 3–6: port one subject area’s staging logic to a Fabric Warehouse (silver), build its gold star, and reconcile it to the existing SQL Server warehouse to the dollar.
- Weeks 7–10: re-point one Power BI report to a Direct Lake model on that gold layer. Run both for a month-end. Compare refresh failures, query performance and capacity cost.
- Weeks 11–13: write the decision memo: cost per month, operational savings, what moves next, what stays on SQL Server indefinitely. Some things should stay.
Fabric rewards exactly the discipline that made SQL Server warehouses work: clear layers, a modeled gold schema and reconciled numbers. Teams that bring that discipline find the platform familiar within a quarter. Teams that treat it as a place to dump tables find the same swamp, with a larger bill.
References
- Microsoft Learn, “What is Microsoft Fabric?” learn.microsoft.com/en-us/fabric/fundamentals/microsoft-fabric-overview (accessed 9 Oct 2026).
- Microsoft Learn, “What is Fabric Data Warehouse?” learn.microsoft.com/en-us/fabric/data-warehouse/data-warehousing (accessed 9 Oct 2026).
- Microsoft Learn, “What is Dataflow Gen2?” learn.microsoft.com/en-us/fabric/data-factory/dataflows-gen2-overview (accessed 9 Oct 2026).
- Microsoft Learn, “What is Mirroring in Fabric?” learn.microsoft.com/en-us/fabric/mirroring/overview (accessed 9 Oct 2026).
- Microsoft Learn, “Direct Lake overview,” learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview (accessed 9 Oct 2026).
- Microsoft Learn, “What is Fabric Activator?” learn.microsoft.com/en-us/fabric/real-time-intelligence/data-activator/activator-introduction (accessed 9 Oct 2026).
- Microsoft Learn, “What is a lakehouse in Microsoft Fabric?” learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-overview (accessed 9 Oct 2026).
- Microsoft Learn, “Implement medallion lakehouse architecture in Fabric,” learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture (accessed 9 Oct 2026).
- Microsoft Learn, “Fabric data agent concepts,” learn.microsoft.com/en-us/fabric/data-science/concept-data-agent (accessed 9 Oct 2026).
- Microsoft Learn, “Governance and compliance in Microsoft Fabric,” learn.microsoft.com/en-us/fabric/governance/governance-compliance-overview (accessed 9 Oct 2026).
