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

[axlrn]

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!

[Asmita_27 · Accepted solution]

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

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

1. Complexity scoring — Score each package (transformations, joins, SQL lines) to classify: low → automate conversion, medium → semi-auto + review, high → redesign for Lakehouse.

2. Dependency mapping — Map connections, variables, and stored procedures together. This drives migration wave sequencing.

3. 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.

4. 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.

[v-anbandari]

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.

[rizalard0684 · Accepted solution]

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:

1. 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-Micro...
   
2. Refactor / transform (for packages with SQL‑heavy logic)
   
   To rework into Fabric Data Pipelines for orchestration or notebooks for transformations
3. 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.

[Asmita_27 · Accepted solution]

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

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

1. Complexity scoring — Score each package (transformations, joins, SQL lines) to classify: low → automate conversion, medium → semi-auto + review, high → redesign for Lakehouse.

2. Dependency mapping — Map connections, variables, and stored procedures together. This drives migration wave sequencing.

3. 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.

4. 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.

[axlrn]

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

[axlrn]

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