• 09 Sep 2026

SQL Server to Microsoft Fabric Migration: Steps, Tools, and Best Practices

Quick Answer

You can migrate SQL Server to Microsoft Fabric using Microsoft's guided migration tools, DACPAC/SqlPackage, Fabric Data Factory pipelines, or Fabric Mirroring, depending on the target Fabric workload. For enterprise analytics, the Fabric Warehouse is typically the closest target to a SQL Server data warehouse because it uses T-SQL. Migration requires compatibility assessment, schema and data movement, ETL and job redesign, validation, and controlled cutover. Because both SQL Server and Fabric Warehouse use T-SQL, SQL Server migration is often lower-friction than migrations from non-Microsoft platforms, though compatibility assessment and rebuild work are still required.

At a Glance

• Source: SQL Server data warehouse (T-SQL, often on-premises)
• Target: Microsoft Fabric Warehouse, Lakehouse, SQL database in Fabric, or Mirroring
• Primary tool: Fabric Migration Assistant, DACPAC/SqlPackage, Fabric pipelines, or Mirroring
• Why it is closer than most: Fabric Warehouse uses T-SQL, like SQL Server, which can reduce SQL conversion effort.
• Still required: Compatibility assessment, schema migration, data movement, ETL redesign, and validation before cutover

Figure 1. Before and after - a SQL Server warehouse rebuilt on Microsoft Fabric, with each component re-created on OneLake and much of the T-SQL carried over.

What Is SQL Server to Microsoft Fabric Migration?

SQL Server to Microsoft Fabric migration is the process of moving a SQL Server data warehouse, its ETL pipelines, reporting, and dependent workloads to Microsoft Fabric. SQL Server holds tables, views, stored procedures, and functions using T-SQL, typically on-premises. Fabric is a cloud analytics platform where the Fabric Warehouse fills the same role; it also uses T-SQL, with data stored in OneLake and reporting served through Power BI.

Because both use T-SQL, SQL Server to Fabric is often lower-friction than cross-platform migrations from Oracle PL/SQL or other dialects. However, you still need a compatibility assessment, schema migration, data movement, ETL redesign, and validation. The migration effort depends on SQL Server version, stored procedure complexity, T-SQL features used, SSIS packages, SQL Agent jobs, SSRS and SSAS dependencies, and security configuration.

Can SQL Server Be Migrated Directly to Microsoft Fabric?

Yes. You can migrate SQL Server to Microsoft Fabric using Microsoft's guided migration tools, DACPAC/SqlPackage, Fabric Data Factory pipelines, Fabric Mirroring, or other supported approaches. The method depends on the target Fabric workload:

• Fabric Migration Assistant: a guided experience that can migrate schema and data into Fabric targets from SQL Server-based sources
• DACPAC and SqlPackage: schema export and deployment tool used in Fabric SQL database migration workflows
• Fabric Data Factory pipelines: for data movement from SQL Server sources into OneLake, Lakehouse, or Fabric Warehouse
• Fabric Mirroring: near-real-time replication of SQL Server data into OneLake for analytical use

Compatibility testing and validation are required regardless of the migration method. No path eliminates the need to assess compatibility, rebuild dependent workloads, and validate business results before cutover.

Which Microsoft Fabric Workload Should SQL Server Migrate To?

Microsoft Fabric provides several workloads that may serve different SQL Server migration scenarios. Choosing the right target is one of the first architectural decisions in a migration.

Most enterprise SQL Server data warehouse migrations target the Fabric Warehouse because it uses T-SQL and serves Power BI from OneLake. However, organizations with significant data engineering workloads may route some data to a Lakehouse, while transactional workloads may suit a SQL database in Fabric. Make the architecture decision before migration begins.

Why Enterprises Migrate from SQL Server to Fabric

• Scale without a hardware refresh: on-premises SQL Server grows by provisioning larger servers; Fabric adds compute on demand through capacity sizing
• A capacity-based cost model: SQL Server carries per-core licensing plus server, storage, and maintenance costs; Fabric is capacity-based and sized to workload requirements
• One platform instead of several tools: a SQL Server estate typically pairs the database with separate tools for ETL (SSIS) and reporting (SSRS); Fabric brings ingestion, the warehouse, and Power BI into one service
• Unified storage in OneLake: Fabric uses OneLake as its unified storage foundation, with Warehouse data stored in Delta format. The exact data movement and target architecture depend on the Fabric workload selected
• T-SQL skills carry over: teams keep the language they already use, which makes Fabric a lower-friction transition than platforms built on a different dialect
• Power BI integration: Power BI can use Direct Lake mode to query Fabric data in OneLake without importing the data into the semantic model, depending on the target architecture

SQL Server to Fabric Asset Mapping

SQL Server to Microsoft Fabric Migration Tools

Microsoft provides several migration tools and methods depending on the source SQL Server version and the target Fabric workload:

What Is a DACPAC in SQL Server to Fabric Migration?

A DACPAC (Data-tier Application Component Package) is a file that represents database schema metadata, including tables, views, procedures, functions, and other database objects. In SQL database migration workflows for Fabric, you upload a DACPAC exported from SQL Server or Azure SQL to the Fabric workspace to assess schema compatibility with the target before deployment.

SqlPackage is the command-line tool commonly used to extract DACPACs from SQL Server and deploy them to target environments. Microsoft documents SqlPackage as a supported tool for SQL database migration to Fabric, including DACPAC extraction and publishing. Resolve schema compatibility issues identified through the DACPAC validation step before data copy operations begin.

Can On-Premises SQL Server Be Migrated to Microsoft Fabric?

Yes. On-premises SQL Server is a primary migration source for Microsoft Fabric. Microsoft's current documentation indicates that on-premises SQL Server migration to a SQL database in Fabric requires an on-premises data gateway for copy operations. For Fabric Data Warehouse migration, Fabric pipelines connected through an on-premises data gateway can move data from on-premises SQL Server sources into OneLake.

The on-premises data gateway bridges on-premises sources and Fabric cloud services. Size, install, and test it before configuring data migration pipelines.

How to Migrate SQL Server to Microsoft Fabric

• Assess and inventory: build a complete list of every table, view, stored procedure, SQL Agent job, SSIS package, SSRS report, SSAS model, and dependency. Rank each by business value and identify what migrates, what retires, and what requires redesign.
• Choose the Fabric target: decide whether each workload goes to Fabric Warehouse, Lakehouse, SQL database in Fabric, or Mirroring. Make the architecture decision before any migration work.
• Check compatibility: use the DACPAC/Fabric Migration Assistant to assess schema compatibility. Identify T-SQL features, data types, and functions that need adjustment before you begin the rebuild.
• Migrate schema and objects: re-create tables, views, stored procedures, and functions in the Fabric Warehouse. Adjust any T-SQL that differs between SQL Server and Fabric Warehouse compatibility.
• Move or replicate data: use Fabric Data Factory copy jobs, pipelines, or Mirroring to bring data from SQL Server sources into OneLake. On-premises sources require an on-premises data gateway.
• Rebuild ETL and scheduling: convert SQL Agent jobs to Fabric Data Factory pipelines. Rebuild SSIS packages as Fabric pipelines and Dataflow Gen2. Treat SSIS migration as a separate workstream with its own inventory and validation.
• Migrate reporting and analytics: rebuild SSRS reports as Power BI reports. Assess SSAS models for conversion to Power BI semantic models. Connect Power BI to the Fabric Warehouse using Direct Lake mode where appropriate.
• Validate and cut over: run SQL Server and Fabric in parallel. Compare row counts, query results, KPI values, and report outputs until they match. Cut over only after validation is complete, and document a rollback plan before retiring the SQL Server warehouse.

What Happens to SSIS, SSRS, and SSAS?

Enterprise SQL Server estates rarely consist of the database alone. The associated Microsoft stack is each its own migration workstream:

• SSIS to Fabric: SSIS packages are rebuilt as Fabric Data Factory pipelines and Dataflow Gen2. SSIS migration involves inventorying every package, mapping its Control Flow and Data Flow tasks to Fabric pipeline activities and Power Query transformations, rebuilding Script Tasks in Python, and validating outputs. SSIS to Fabric is typically treated as a separate migration from the core warehouse migration, with its own inventory, complexity classification, and validation phase.
• SSRS to Power BI: We assess SSRS reports and rebuild them as Power BI reports where appropriate. Pixel-perfect SSRS financial and operational reports may map to Power BI paginated reports. DataTerrain's Automated BI reports conversion service can accelerate SSRS report migration at scale.
• SSAS to Power BI semantic models: SSAS Tabular models can be deployed to Fabric and Power BI with connection updates and compatibility adjustments. SSAS Multidimensional cubes require a more significant redesign as Tabular semantic models, with MDX calculations converted to DAX. SSAS migration is its own workstream and should not be assumed to be a simple re-deployment.

SQL Server Mirroring vs Traditional Migration

Traditional migration rebuilds the warehouse schema and logic on Fabric, moves historical data into OneLake, reconnects ETL and reporting, and retires the SQL Server environment after validation.

Fabric Mirroring continuously replicates SQL Server changes into OneLake and converts them to Parquet format for analytics, giving near-real-time analytical access to SQL Server data in Fabric without immediately rebuilding the warehouse.

An important distinction: mirroring moves or replicates data, but it does not automatically migrate the complete warehouse architecture, SSIS ETL logic, SSRS reports, SSAS models, SQL Agent jobs, or other dependent workloads. Mirroring can be a useful component of a broader migration strategy, for example, enabling analytics on Fabric while the full warehouse migration is in progress, but it is not a substitute for a complete migration when full modernization is the goal.

Common SQL Server Migration Challenges

• T-SQL compatibility: not every SQL Server T-SQL feature behaves identically in Fabric Warehouse. Compatibility assessment should identify differences before the rebuild begins
• Data types and collation: review data types, precision, string behavior, and collation assumptions to avoid precision or format changes in the migrated data
• On-premises connectivity: data held on-premises requires a correctly sized and tested on-premises data gateway before migration pipelines can run
• SQL Agent dependencies: scheduling logic and job dependencies may require redesign rather than direct reproduction in Fabric pipelines
• Indexing and performance: Fabric manages storage as Delta rather than SQL Server indexes. Performance is re-tuned for the new platform rather than assuming SQL Server indexing strategies apply
• Security model: database roles, permissions, user identities, and row-level security must be reviewed and rebuilt for the Fabric security model and Microsoft Entra ID
• Application dependencies: applications that directly query SQL Server need connection string updates and downstream compatibility testing before cutover
• SSIS, SSRS, and SSAS scope: the full scope of a SQL Server estate often extends to SSIS, SSRS, and SSAS, each of which carries its own migration effort

SQL Server Migration Best Practices

• Inventory first: a complete list of objects and dependencies prevents scope surprises mid-project
• Choose the right Fabric target before starting: the architecture decision (Warehouse vs Lakehouse vs SQL database vs Mirroring) shapes every subsequent migration step
• Migrate by business intent: rebuild what each object achieves and adjust T-SQL where Fabric differs, rather than attempting a literal copy
• Start with a representative sample: validate the approach on a representative set of tables, procedures, and reports before scaling to the full warehouse
• Treat SSIS, SSRS, and SSAS as separate workstreams: each has its own inventory, migration approach, and validation requirements
• Validate in parallel: run SQL Server and Fabric together and reconcile results before switching over
• Involve an internal owner: someone who understands the current warehouse should confirm that the rebuilt logic produces correct business results

How Long Does SQL Server to Fabric Migration Take?

Migration effort depends on the number of databases and tables, data volume, stored procedure complexity, T-SQL feature usage, SSIS package count, SQL Agent job complexity, SSRS and SSAS dependencies, security requirements, on-premises gateway setup, and validation requirements. A single database with standard T-SQL and minimal SSIS can be migrated faster than a multi-database SQL Server estate with complex stored procedures, extensive SSIS ETL, SSRS report libraries, and SSAS cubes. The most reliable way to estimate effort is to complete the inventory and classify objects by complexity before scoping the project.

Key Takeaways

• SQL Server to Fabric requires rebuilding and validation, not a simple transfer.
• Fabric Warehouse uses T-SQL, reducing conversion effort.
• Choose the right Fabric target: Warehouse, Lakehouse, SQL database, or Mirroring.
• Use the right migration tools, including Migration Assistant, DACPAC/SqlPackage, and Data Factory.
• SSIS, SSRS, and SSAS require separate migration workstreams.
• On-premises SQL Server requires a data gateway.
• Validate in parallel before cutover to ensure data and business results match.

Conclusion

SQL Server to Microsoft Fabric migration is a structured modernization that spans schema migration, data movement, ETL rebuilding, reporting migration, security mapping, and validation. The shared T-SQL foundation between SQL Server and Fabric Warehouse reduces some conversion complexity compared to cross-platform migrations, but the migration scope extends well beyond the database itself to include SSIS, SSRS, SSAS, and SQL Agent workloads. A thorough inventory, the right Fabric target architecture, Microsoft's guided migration tooling, and parallel validation are the foundations of a reliable migration. Contact DataTerrain for a free SQL Server to Microsoft Fabric migration assessment.

Related Articles

• SSIS to Microsoft Fabric Migration: Complete Guide
• SSAS to Microsoft Fabric Migration: Complete Enterprise Guide
• Cognos to Microsoft Fabric Migration: A Practical Guide
• Microsoft Fabric vs Amazon Redshift: Which Fits Your Stack?

Frequently Asked Questions