SQL Server to Microsoft Fabric: T-SQL Compatibility Is Not the Whole Story

Hariharan Arulmozhi, Founder & CEO, 3X Data Engineering
SQL Server to Fabric looks straightforward because both platforms sit in the Microsoft ecosystem. In practice, T-SQL compatibility is only one part of the migration. SSIS packages, SQL Agent jobs, Windows Authentication, CLR objects, linked servers, and on-premises networking all need a separate plan.

Key takeaways

  • T-SQL compatibility is high (around 85 percent) but covers the language only.
  • SSIS packages, SQL Agent jobs, Windows Authentication, and CLR objects do not migrate directly and need redesign.
  • Linked servers and cross-database queries require architectural changes in Fabric.
  • Realistic migration timeline for mid-size estates: 10 to 16 weeks with accelerators, 8 to 18 months manually.

What actually moves cleanly

The easy parts of a SQL Server to Fabric migration are the parts most teams already know how to handle.

  • Standard T-SQL stored procedures, views, and functions using common patterns
  • Tables with standard data types
  • Basic dimensional models and star schemas
  • Simple ETL patterns built in T-SQL or basic Data Factory

What does not migrate directly

These are the items that drive 60 to 80 percent of the actual migration effort.

SSIS packages

SSIS does not run in Fabric. Teams have three options: rebuild in Fabric Data Factory pipelines, lift packages into ADF with SSIS integration runtime as a transitional step, or rewrite the logic in Notebooks. SSIS packages with custom Script Tasks or proprietary control flow components need rebuild. Plan for substantial work here, often the dominant cost of the migration.

SQL Agent jobs

SQL Agent does not exist in Fabric. Scheduled jobs are rebuilt as Fabric Data Factory pipelines with scheduled triggers. Each job needs to be assessed for its actual function (data movement, maintenance, reporting), then mapped to the right Fabric primitive.

Windows Authentication and CLR objects

Fabric uses Entra ID for authentication. Windows Authentication patterns need to be redesigned. CLR objects are not supported. Custom .NET code in CLR functions requires a different implementation, typically in Spark or as external service calls.

Linked servers and cross-database queries

Fabric does not support linked servers in the SQL Server sense. Cross-database queries within Fabric work differently. Patterns that rely on linked servers need to be re-architected as data movement plus local processing, not in-place federation.

On-premises network patterns

Fabric is fully cloud. On-premises integration requires Data Gateway, private endpoints, or alternative connectivity patterns. Network architecture decisions need to be made early in the migration, not at the end.

Where AI acceleration helps

  • Source-connected estate inventory across tables, procedures, jobs, SSIS packages, and dependencies
  • Object-level complexity scoring including SSIS package classification
  • Bulk T-SQL conversion to Fabric-compatible patterns
  • SSIS package analysis identifying which translate cleanly and which need redesign
  • Automated reconciliation comparing source and target outputs

Plan your modernization with a fact-based blueprint

If you are working on a SQL Server to Fabric migration, the next practical step is a fixed-price Modernization Assessment. Source-connected discovery, complexity scoring, target architecture, effort estimation, and bulk-converted sample code, delivered as a Modernization Canvas in 8 business days. No long discovery, no procurement cycle, Director-level signing authority.

Frequently Asked Questions

Answering common questions about 3X Data Engineering to help you get started on your modernization journey.

Around 85 percent at the language level. The remaining 15 percent includes multi-statement TVFs, certain syntax patterns, and data type differences. Every object still needs assessment.
No. SSIS does not run in Fabric directly. Options are rebuild in Fabric Data Factory, lift to ADF with SSIS integration runtime as a transitional path, or rewrite in Notebooks.
They are rebuilt as Fabric Data Factory pipelines with scheduled triggers. Each job needs assessment for its actual function before mapping to the right Fabric primitive.
Pure T-SQL warehouses with minimal SSIS run 8 to 12 weeks. SSIS-heavy estates run 12 to 16 weeks. Complex estates with CLR objects or federated patterns can run 20+ weeks.
Most teams end up with Fabric Warehouse for the analytical layer and Lakehouse for ingestion and Spark-based transformation. Pure-Warehouse architectures are usually a transitional choice, not the end state.

Explore More Blogs

Oracle PL/SQL to Microsoft Fabric T-SQL conversion timeline and architecture map

Oracle to Microsoft Fabric: Why PL/SQL Conversion Drives the Timeline

Oracle to Microsoft Fabric is a rewriting effort, not a simple platform migration. PL/SQL and T-SQL follow different procedural models, and Oracle packages, cursor loops, triggers, sequences, and autonomous transactions require careful redesign. This guide explains why PL/SQL conversion drives the timeline.

May 21, 2026
Teradata BTEQ scripts and FastLoad jobs mapped to a Microsoft Fabric Lakehouse architecture

Teradata to Microsoft Fabric: BTEQ Scripts and the Real Bottlenecks

Teradata to Fabric requires more than SQL translation. BTEQ scripts, FastLoad and MultiLoad jobs, QUALIFY clauses, Teradata-specific functions, and PE/AMP performance assumptions all need analysis or redesign. The biggest hidden risk is often tribal knowledge in undocumented scripts.

May 15, 2026
View All Blogs

Scope your SQL Server to Fabric Modernization Assessment

Assess T-SQL, SSIS, jobs, dependencies, and architecture before committing to a migration timeline.

Request a Demo

Let's talk scale.

Our team of engineering experts and AI architects is ready to help you accelerate your data modernization journey.

Email

Phone / Text

-Select-