SQL Server to Fabric Warehouse

Overview and challenges

Migrating from SQL Server to Microsoft Fabric Warehouse introduces a number of technical challenges stemming from fundamental differences between the two platforms.

SQL Server is a traditional single-machine relational database system optimized for transactional workloads and local consistency.

In contrast, Fabric Warehouse is a modern, massively distributed cloud data warehouse that stores data in open formats (such as Parquet) and is optimized for high-throughput analytical workloads.

Because of this shift in architecture, many assumptions that SQL Server code relies on — including session-specific behavior, case-insensitive object handling, and certain advanced SQL Server features — do not translate directly into Fabric Warehouse.

To preserve business logic and minimize manual migration effort, SQL Tran automatically rewrites and emulates key features that are unsupported or behave differently in Fabric Warehouse.

The main challenges in migrating from SQL Server to Fabric Warehouse include:

• Data types: Certain SQL Server types, such as NVARCHAR, do not exist natively in Fabric Warehouse and require type mapping adjustments. (See: Data types page)

• Case sensitivity: Fabric Warehouse enforces case-sensitive object names, while SQL Server is typically case-insensitive. SQL Tran adjusts object name casing automatically during migration. (See: Case sensitivity page)

• Cursors: SQL Server cursors, used for row-by-row processing, must be refactored into set-based loops and operations suitable for distributed execution. (See: Cursors page)

• Named procedure parameters: Fabric Warehouse does not support named parameters in procedure execution; SQL Tran rewrites them into positional parameters. (See: Named procedure parameters page)

• Result set limiting: Fabric Warehouse does not honor SET ROWCOUNT for limiting result sets; SQL Tran transforms affected statements by injecting TOP clauses where possible. (See: Result set limiting page)

• MERGE statements: Fabric Warehouse lacks full support for MERGE; SQL Tran splits MERGE into combinations of DELETE, UPDATE, and INSERT statements. (See: MERGE statements page)

• Computed columns: Tables with computed columns must be split into a base table (storing the data) and a view (adding the computed expressions), with all references updated accordingly. (See: Computed columns page)

• External tables: Fabric Warehouse does not support external tables. SQL Tran replaces them with standard tables, requiring external data loading to be handled separately. (See: External tables page)

• Materialized views: Fabric Warehouse does not support materialized views; SQL Tran emulates them by converting them into standard views, commenting out unsupported options. (See: Materialized views page)

• Identity columns: Auto-incrementing identity columns are not natively supported; SQL Tran generates monotonically increasing values to emulate identity behavior. (See: Identity columns page)

• Unsupported system objects: Some SQL Server-specific system objects (such as sys.sequences, XML methods, and scalar functions) are not available in Fabric Warehouse and are flagged during migration. (See: Unsupported system objects page)

These architectural and feature differences make direct migration impossible without significant adjustments.

SQL Tran addresses these gaps through a combination of automated translation, targeted emulation strategies, and limitation detection, allowing users to achieve a high degree of migration automation with minimal manual rewrites.

---

Emulation strategies

Due to the significant architectural differences between SQL Server and Microsoft Fabric Warehouse, a direct translation of database code is often impossible.

Features that rely on single-node assumptions, specific T-SQL constructs, or unsupported object types must be restructured to function correctly in the distributed, cloud-based Fabric environment.

To address these gaps, SQL Tran automatically emulates critical SQL Server functionality. Rather than simply flagging unsupported features, SQL Tran rewrites code to preserve the original business logic as closely as possible.

Where direct feature equivalents do not exist in Fabric Warehouse, SQL Tran reconstructs behavior using alternative, Fabric-compatible SQL patterns.

Each type of emulation is carefully designed to:

• Maintain compatibility with Fabric's distributed execution model.

• Minimize manual adjustments by users.

• Preserve the readability and maintainability of the translated code.

The following sections explain each emulation strategy in detail, including:

• How SQL Tran transforms the original SQL Server constructs.

• Code examples demonstrating the transformation process.

• Important limitations or special considerations.