topic Re: How are you approaching SSIS → Microsoft Fabric migration in practice? in Data Engineering

How are you approaching SSIS → Microsoft Fabric migration in practice?

axlrn — Wed, 29 Apr 2026 01:04:50 GMT

I’m currently looking into a real scenario involving SSIS environments and planning a potential migration to Microsoft Fabric.

One of the first challenges I’m facing is something quite basic, but critical:

👉 lack of visibility into the existing SSIS environment

In many cases, it’s not clear:

how packages are structured
what dependencies exist (connections, variables, SQL logic)
which components are actually critical

🔎 My current approach (first step)

Before even thinking about migration, I started by focusing on:

mapping SSIS project structure
extracting metadata from .dtsx / .ispac files
identifying dependencies and embedded SQL

To support this, I put together a small approach/tool to help generate this inventory automatically.

👉 The idea is simple:
understand first → migrate later

🤔 Open question

For those who have already gone through this (or are planning to):

👉 After building an inventory of the SSIS environment,
what would you consider the next step?

Some possibilities I’ve been thinking about:

classification of pipelines (keep / refactor / retire)
mapping to Fabric Data Pipelines or Lakehouse architecture
identifying candidates for redesign vs lift-and-shift

💬 Looking for real-world experience

I’d really appreciate hearing:

how you structured your migration approach
what worked (and what didn’t)
any tools or frameworks you found useful

Happy to share more details of what I’m testing if useful.

Thanks in advance!

Re: How are you approaching SSIS → Microsoft Fabric migration in practice?

Asmita_27 — Wed, 29 Apr 2026 05:25:18 GMT

Hi @axlrn
Totally agree, understand first, migrate later.

After the inventory, here's what worked for us:

Complexity scoring — Score each package (transformations, joins, SQL lines) to classify: low → automate conversion, medium → semi-auto + review, high → redesign for Lakehouse.
Dependency mapping — Map connections, variables, and stored procedures together. This drives migration wave sequencing.
Don't 1:1 lift-and-shift complex packages — SSIS control flow patterns (ForEach loops, reconciliation, SCD logic) need rethinking for Fabric, not just translating.
Don't forget stored procedures — Embedded SQL in Execute SQL Tasks is part of the logic and needs to migrate too.

We built a tool that parses .dtsx/.conmgr XML, scores complexity, auto-generates Fabric Notebooks (PySpark), validates output, and deploys to Fabric via API. Automating the boring parts freed us to focus on the packages that actually need redesign.

Re: How are you approaching SSIS → Microsoft Fabric migration in practice?

rizalard0684 — Fri, 01 May 2026 07:23:10 GMT

Hi @axlrn

Your starting point is spot on. In fact, across some of my projects (not necessarily SSIS migration), I’ve learned that inventory and visibility is a "must have", not a “nice to have”.

The very next thing that I would do (before we do classification) is to compare:

What exists vs
What is actually needed

I call this "rationalization" of future target architecture in MSFT Fabric.

Then, after this we would classify pipelines what existed into:

True lift and shift (if we want something fast / quick win)
https://community.fabric.microsoft.com/t5/Fabric-Updates-Blogs/Invoke-SSIS-Package-Activity-in-Microsoft-Fabric-Preview/ba-p/5172121
Refactor / transform (for packages with SQL‑heavy logic)
To rework into Fabric Data Pipelines for orchestration or notebooks for transformations
Not keep / retire (for duplicate pipelines or legacy stuff that are no longer consumed)

One lessons learnt I'd like to share is to separate orchestration from transformation, in SSIS there are control flow, data movement and business logic all often live in the same package.

In Fabric, I strongly recommends to split into:

Fabric Data Pipelines → orchestration only
Lakehouse + Spark / SQL → transformations & business rules

In short, however, Your “understand first → migrate later” principle is aligned to what I would approach in practice.

Re: How are you approaching SSIS → Microsoft Fabric migration in practice?

v-anbandari — Mon, 04 May 2026 12:15:24 GMT

Hi @axlrn ,

Thank you for posting your query in the Microsoft Fabric Community Forum and Thanks to @rizalard0684 , @Asmita_27 for sharing valuable insights.

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

Thank You.

Re: How are you approaching SSIS → Microsoft Fabric migration in practice?

axlrn — Tue, 05 May 2026 16:08:02 GMT

Hi @v-anbandari ,

I would like to thank @Asmita_27 and @rizalard0684 for the valuable insights and for taking the time to share their approaches — this discussion was extremely helpful.

I really appreciated the different perspectives on migrating SSIS workloads to Microsoft Fabric. It’s interesting to see how each team is balancing modernization with existing investments.

Based on the suggestions, I’ll move forward with testing the new capability that allows running .dtsx packages within Fabric. This seems like a promising step to better understand how we can bridge our current SSIS-based architecture with the Fabric ecosystem.

I’ll share my findings here as soon as I have some concrete results — especially regarding performance, limitations, and integration with pipelines.

Thanks again for the collaboration!

Best regards,
Renan

Re: How are you approaching SSIS → Microsoft Fabric migration in practice?

axlrn — Tue, 05 May 2026 19:15:41 GMT

Hi @Asmita_27 ,

Thanks for sharing your approach — especially the complexity scoring and dependency mapping strategy, that makes a lot of sense.

For the inventory step, I actually developed a Python-based solution to analyze SSIS packages (.dtsx/.conmgr) and made it available as an open-source project:
https://github.com/sql-server-toolkit/ssis-inventory

The tool extracts connections, variables, and SQL objects, helping to better understand dependencies and support migration planning.

I found your mention of a tool that parses XML, scores complexity, generates Fabric Notebooks (PySpark), and deploys via API really interesting.

Is this solution publicly available, or could you share more details about how it works?

I’d love to understand more about your approach.

Best regards,

Renan