• 27 Aug 2026

SSIS to Microsoft Fabric Migration: Complete Guide for 2026

Quick Summary

SSIS to Microsoft Fabric migration involves assessing existing SSIS packages, deciding whether to retain, integrate, refactor, or rebuild them, mapping each package's components to Fabric services, converting Control Flow to Fabric Pipelines, Data Flow tasks to Dataflow Gen2 or notebooks, and SSIS scheduling to Fabric triggers. Data destinations move to OneLake as Delta tables in a Lakehouse or Fabric Warehouse. Migration is a redesign exercise, not a direct file format conversion. The right approach depends on package complexity, custom code, data source connectivity, and modernization goals.

SSIS to Microsoft Fabric migration moves SQL Server Integration Services workloads from on-premises .dtsx package files to Microsoft Fabric's cloud-native, unified analytics platform. Migration involves assessing existing SSIS packages, choosing the right migration approach for each workload, mapping SSIS components to Fabric equivalents, converting Control Flow to Fabric Pipelines, converting Data Flow to Dataflow Gen2, migrating Script Tasks to notebooks, configuring SSIS to OneLake data ingestion, validating results, and decommissioning legacy SSIS infrastructure. This guide covers what migration involves and how to plan it.

What Is SSIS to Microsoft Fabric Migration?

SQL Server Integration Services (SSIS) is Microsoft's on-premises ETL platform, processing data through .dtsx package files that encode Control Flow logic (sequencing, looping, conditional branching, error handling) and Data Flow pipelines (source adapters, transformations, destination writers). For two decades, SSIS was the default ETL tool for SQL Server environments, and most enterprise data warehouses built before 2018 carry a significant SSIS footprint.

Microsoft Fabric is Microsoft's unified, cloud-native analytics platform. Fabric's data integration layer consists of Fabric Pipelines (handling orchestration and Control Flow logic) and Dataflow Gen2 (a Power Query-based transformation engine handling Data Flow logic). SSIS-to-OneLake data ingestion replaces the destination-write step in legacy SSIS packages, writing data to OneLake as Delta-format Parquet.

SSIS to Microsoft Fabric migration is the structured process of converting SSIS packages- their Control Flow, Data Flow, connection managers, variables, parameters, and schedules- into Fabric components, and retiring the on-premises SSIS infrastructure in favor of a cloud-native ETL modernization architecture.

SSIS to Microsoft Fabric Migration Options

There is no single SSIS-to-Fabric migration approach. Organizations can continue using existing SSIS packages while integrating them with Fabric, adopt a hybrid architecture, or progressively rebuild workloads as Fabric-native pipelines, Dataflows Gen2, and notebooks. The right approach depends on package complexity, business criticality, custom code, connectivity requirements, and modernization goals.

Can Existing SSIS Packages Run in Microsoft Fabric?

Organizations do not necessarily need to rewrite every SSIS package before adopting Fabric. Microsoft has introduced the Invoke SSIS Package Activity in Fabric (currently in Preview) to support execution of existing packages from Fabric Pipelines. This enables a lift-and-shift path where .dtsx files are uploaded to OneLake and orchestrated through Fabric without immediate rewriting, allowing teams to prioritize business-critical workloads, validate Fabric adoption, and gradually replace legacy packages with Fabric-native alternatives.

Whether to reuse existing packages or rebuild them natively depends on the package's complexity, custom code presence, on-premises connectivity requirements, and how long the organization intends to maintain the SSIS runtime infrastructure.

Why Organizations Are Modernizing SSIS Workloads with Microsoft Fabric

Infrastructure elimination: SSIS requires a Windows Server, SQL Server hosting the SSISDB catalog, SQL Agent for scheduling, and network access to every data source. Fabric Pipelines and Dataflow Gen2 are fully managed SaaS services with no infrastructure to provision, patch, or scale.

Consolidated analytics access: data written to OneLake via SSIS is immediately available to Fabric Lakehouse, Fabric Warehouse, Power BI Direct Lake, and Fabric Real-Time Intelligence, none of which are accessible from on-premises SSIS.

Modern governance and monitoring: Fabric provides unified lineage, activity monitoring, access control through Microsoft Entra ID, and sensitivity labels through Microsoft Purview: capabilities that are not native in SSIS.

Reduced technical debt: many SSIS estates carry packages built over a decade or more, often with undocumented business logic, custom components, and single-developer dependency. Migration is an opportunity to modernize and document integration architecture rather than carry it forward indefinitely.

Cloud and hybrid data architecture: organizations consolidating on Azure and Microsoft 365 gain a unified data engineering, warehousing, and BI environment when Fabric-native services replace SSIS.

SSIS vs Azure Data Factory vs Microsoft Fabric

SSIS to Microsoft Fabric Component Mapping

SSIS to Fabric migration is a component mapping and redesign exercise, not a direct file-format conversion. A single SSIS package may become multiple Fabric items: pipelines, Dataflows Gen2, notebooks, Lakehouse tables, and orchestration workflows. The correct Fabric implementation depends on transformation complexity, data volume, and connectivity requirements.

What Cannot Be Automatically Converted from SSIS to Fabric?

The more an SSIS package depends on custom code, proprietary components, Windows infrastructure, or undocumented business logic, the less likely it is to support straightforward automated conversion. Assets that typically require manual redesign include:

• Custom C# and VB.NET Script Tasks: no automated conversion path; must be rewritten in Python
• Third-party SSIS components (CozyRoc, Task Factory, KingswaySoft): no direct Fabric equivalents; require bespoke Python or Power Query implementations
• Windows-specific integrations: COM dependencies, .NET-only libraries, Windows API calls
• Complex SSIS error output behavior: error redirect patterns may produce different results in Dataflow Gen2 and require explicit remediation
• Package configurations and environment variables using SSIS-specific mechanisms
• SQL Agent dependency chains and complex scheduling logic

How to Assess SSIS Packages Before Migration

A complete SSIS package inventory is the non-negotiable first step. Teams that skip it encounter undocumented dependencies, custom components, and downstream consumers mid-migration that delay project timelines. For each package, the inventory should capture:

• Package name, Control Flow complexity (task count, loop depth, branches)
• Data Flow row volumes and transformation types
• Connection manager types and whether sources are cloud-accessible or on-premises
• Script Task presence and language (C# or VB.NET)
• Schedule frequency and downstream consumers
• Business owner and last execution date

After inventory, classify each package using a four-category framework: Retire (no business value, no recent usage), Reuse (valid package, defer migration with Fabric integration), Refactor (rebuild using Fabric-native services with redesign), or Rebuild (complex package requiring full Fabric-native reimplementation). This classification drives migration sequencing and effort estimation.

Step-by-Step SSIS to Microsoft Fabric Migration Process

• Step 1: SSIS package inventory. Run a complete inventory across all SSISDB catalogs and file-system .dtsx files. Document package name, Control Flow complexity, Data Flow row volumes, connection manager types, Script Task presence, schedule frequency, and downstream consumers. Apply the Retire/Reuse/Refactor/Rebuild classification to each package.
• Step 2: Environment and connectivity setup. Provision the Fabric capacity (F-SKU) and workspace. Configure on-premises data gateways for data sources the cloud cannot reach. Set up connections and the OneLake folder structure for SSIS-to-OneLake data ingestion output. Complete this infrastructure work before validating any DTSX conversion end-to-end.
• Step 3: Control Flow conversion. Convert each package's Control Flow to a Fabric Pipeline. Most standard patterns- Execute SQL Task, Foreach Loop, precedence constraints- map to Fabric Pipeline activities. Replace SQL Agent job schedules with SSIS scheduling to Fabric triggers: time-based, event-based, or pipeline-chained.
• Step 4: Data Flow conversion. Convert each Data Flow Task to a Dataflow Gen2 using Power Query Online to replicate transformation logic. Standard transformations: merge joins, derived columns, conditional splits, aggregate transforms, and lookups have Power Query M equivalents. For transformations that exceed Power Query's capability, use a Fabric Notebook as the transformation engine called from the Fabric Pipeline.
• Step 5: Script Task migration. Script Tasks in C# or VB.NET require manual rewriting as Fabric Notebooks in Python. There is no automated DTSX conversion path for scripts. Each Script Task must be read, understood, and rewritten. Script Tasks performing file manipulation, FTP operations, or API calls can use Python library equivalents directly.
• Step 6: Validation and UAT. Run the Fabric pipeline and the original SSIS package against the same source data. Compare output row counts, column values, and data types. Build a test harness that captures SSIS output to a staging table and Fabric output to a parallel staging table, then runs an automated comparison. Investigate and resolve any discrepancy before promoting the Fabric pipeline to production.
• Step 7: Cutover and decommission. After production validation cycles with matching output, turn off the SQL Agent job, archive the .dtsx file to source control, and remove the package from the SSISDB catalog. Once all packages are migrated, decommission the SSIS server and catalog.

Migration Challenges

• Script Tasks in C# and VB.NET: the single largest source of migration effort. Each script must be read, understood, and rewritten in Python. Scripts calling Windows APIs, COM objects, or .NET-only libraries require particular care during migration.
• Custom SSIS components: third-party components with no Fabric equivalent require a bespoke Python or Power Query implementation per component, effort that is difficult to estimate without a full package inventory.
• On-premises data source connectivity: SSIS runs inside the corporate network and reaches on-premises systems without additional configuration. Fabric cloud migration must route these connections through an on-premises data gateway. Gateway capacity, availability, and latency become new operational concerns.
• Data Flow execution semantics: SSIS Data Flow runs in a single-server, in-memory, row-by-row streaming model. Data Flow Gen2 runs on a distributed Power Query engine. Transformation results that rely on implicit row ordering or SSIS-specific error redirect behavior may produce different results and require explicit remediation.
• Scope discovery: SSIS estates that grew organically over a decade often contain packages not deployed to SSISDB, packages with undocumented dependencies, and downstream consumers that only surface at cutover. A thorough inventory prevents these from becoming blockers.

Can SSIS to Fabric Migration Be Automated?

Automation can accelerate assessment and conversion, but most enterprise migrations still require engineering review and validation. Automated tools are best used to reduce repetitive discovery and mapping work rather than eliminate migration design decisions.

Automation can assist with metadata extraction and DTSX parsing; standard Control Flow activity mapping; pipeline JSON generation for standard patterns; mapping documentation; and validation comparison queries. What still requires manual redesign: Script Tasks in C# or VB; custom SSIS components; complex transformation business logic; security architecture; and error handling patterns. The most effective approach combines automated discovery and standard-component conversion with expert engineering for complex packages.

Best Practices

• Complete the SSIS package inventory before writing a single line of Fabric code: undiscovered packages mid-migration delay cutovers significantly.
• Migrate in waves by complexity classification: simple packages first, Script Task-heavy packages last.
• Establish a shared Fabric workspace, naming conventions, and OneLake folder structure before migration begins.
• Build a reusable test harness for SSIS versus Fabric output comparison using automated row count, column hash, and null count diffs.
• Do not attempt automated Script Task conversion: read and understand each script before rewriting in Python.
• Plan gateway capacity from day one: under-provisioned gateways become the bottleneck for the entire migrated pipeline fleet.
• Use Fabric's Git integration from the start: this provides the version control that SSIS's .dtsx file format never had.

Illustrative Example: SSIS to Fabric Migration

The following is an illustrative scenario based on the types of SSIS estates DataTerrain typically encounters. It is not an account of a specific customer engagement.

Consider a financial services organization with a 15-year SSIS footprint operating approximately 140 packages across three SQL Server instances covering nightly warehouse loads, regulatory reporting feeds, position calculations, and finance reconciliations. A complete package inventory identifies a proportion of packages that have not executed in over 18 months; these are decommissioned without migration, reducing active scope. Packages are classified into simple (standard SQL tasks and OLE DB loads), medium (multi-source joins, conditional logic), and complex (including those containing C# Script Tasks). Simple packages migrate first to establish the pipeline template and validation harness. Medium packages follow, with SSIS Data Flow to Dataflow Gen2 conversion as the primary effort. Complex Script Task packages are the most effort-intensive and are handled as dedicated workstreams with senior Python developers. The organization retires on-premises Windows Servers and SQL Server licenses on completion and gains unified monitoring through the Fabric Monitor hub with Microsoft Purview lineage tracking.

Final Thoughts on SSIS to Microsoft Fabric Migration

SSIS to Microsoft Fabric migration is not a one-size-fits-all DTSX conversion project. Organizations can reuse existing SSIS workloads, adopt a hybrid architecture, or progressively rebuild ETL processes using Fabric-native services. The right migration strategy depends on package complexity, custom code, data source connectivity, business criticality, and long-term analytics goals. The organizations that execute best invest in a thorough inventory before scoping, classify packages by migration approach rather than treating the estate as uniform, and build a validation harness that confirms output parity at each stage before retiring any SSIS workload. Contact DataTerrain to discuss your SSIS estate and begin with a representative proof of concept on your actual packages.

Key Takeaways

• Migration is a redesign, not a file conversion. SSIS packages become Pipelines, Dataflow Gen2 queries, notebooks, and Fabric triggers: rebuilt natively, not imported.
• Multiple migration approaches exist. Reuse, hybrid, rebuild, or automation-assisted: the right choice depends on workload complexity and modernization goals.
• Script Tasks are the highest-effort component. C# and VB.NET Script Tasks have no automated conversion path and must be manually rewritten in Python.
• Inventory before scoping. Undiscovered packages, undocumented dependencies, and downstream consumers found mid-migration can significantly delay cutovers.
• SSIS-to-OneLake data ingestion unlocks Fabric analytics. Delta-format data in OneLake is immediately available to Lakehouse, Warehouse, and Power BI Direct Lake.
• Gateway planning is essential. On-premises data sources must be accessible through Fabric's data gateway from day one of the migration.

Related Articles

• Informatica to Microsoft Fabric Migration: A Complete Guide
• Microsoft Fabric vs Informatica: Platform Comparison
• ETL Migration Solutions
• Alteryx to Python Migration: A Complete Guide
• BI Modernization Checklist: A Step-by-Step Guide

Frequently Asked Questions