Converting SSIS and T-SQL to Microsoft Fabric: What Breaks and How to Plan for It
SSIS packages do not all migrate the same way
SSIS packages fall into different migration approaches, and treating them as one bucket is where estimates go wrong. Some packages are straightforward data movement and map reasonably to Fabric Data Factory pipelines. Others carry transformation logic, script tasks, or control flow that is better rebuilt as notebooks. Classify every package by migration approach early, Data Factory translation versus Notebook rebuild, so the effort estimate reflects reality rather than an average.
SQL Agent jobs deserve the same treatment. They are easy to overlook because they sit outside the packages, but they encode scheduling and dependency logic that has to land somewhere in Fabric. Inventory them alongside the packages, not after.
T-SQL conversion is mostly mechanical until it is not
Much of the T-SQL in a typical estate converts cleanly. The cost lives in the exceptions: dynamic SQL, temp table rebuild patterns, cursor logic, and procedure-level constructs that behave differently or are unsupported on Fabric Warehouse. The goal is semantic equivalence, meaning the converted procedure produces the same result, not just code that compiles. That requires a per-object gap analysis flagging where the source and target diverge, and a deliberate plan for each flagged object.
Where business logic hides
The hardest objects are rarely the largest. They are the ones with logic accumulated over years that no one fully remembers. A stored procedure that quietly handles a fiscal-calendar edge case or a downstream report that depends on a nightly temp table rebuild will not announce itself. Source-connected reverse engineering surfaces these dependencies before they become production incidents.
A plan that holds up
A workable conversion plan has four parts. First, a complete inventory of stored procedures, views, SSIS packages, and SQL Agent jobs. Second, complexity scoring against Fabric compatibility, so you know which objects are routine and which need senior attention. Third, an SSIS classification splitting packages into translation versus rebuild. Fourth, a validation approach that reconciles source and target output at the object level rather than checking row counts and hoping.
Conclusion
Converting SSIS and T-SQL to Fabric is achievable and increasingly common. What separates the smooth migrations from the painful ones is whether the surprises were found during assessment or during cutover. Spend the time to find them first.
