I built a Claude Skill that inventories legacy SSIS packages before a Fabric migration

Bayrem Hamrouni — Mon, 28 Sep 2026 11:48:29 +0000

If you've ever inherited a folder of .dtsx files with zero documentation, you know the drill. Before you can migrate anything to Microsoft Fabric, you first have to answer a much less exciting question: what is actually in these packages?
I built ssis-fabric-migration-assistant, a Claude Skill that automates the "inventory and classify" phase of an SSIS → Fabric migration, so teams stop burning consulting hours just to find out what's safe to touch.
The problem
A typical legacy SSIS estate looks like this: 50–300 .dtsx packages, built over a decade, by people who are long gone, doing who-knows-what. Before any migration work starts, someone has to manually open every package in SSDT and answer:

What does this package actually do?
Which components map cleanly to Fabric, and which don't have a direct equivalent?
Is this safe to auto-convert, or does it need a full rewrite?
Where do we even start?

That triage work doesn't require creativity, it requires patience and a mapping table. Which makes it a good fit for a Claude Skill: deterministic parsing + a fixed reference table + judgment calls Claude is actually good at (writing the plain-language summary, deciding how the risk factors combine).
How it's structured
A Claude Skill is just a folder Claude loads on demand — instructions, reference data, and optionally a bundled script:

ssis-fabric-migration-assistant/
├── SKILL.md # workflow, hard rules, trigger phrases
├── references/
│ ├── ssis-fabric-mapping.md # full SSIS→Fabric equivalence table + risk heuristics
│ └── report-template.md # exact report shape
├── scripts/
│ └── parse_dtsx.py # stdlib-only XML parser, zero dependencies
└── assets/sample_dtsx/ # a synthetic test package + example output

The parsing itself is plain Python, not an LLM guessing at XML structure. parse_dtsx.py walks the .dtsx XML tree and pulls out control flow tasks, data flow components, connection managers, variables, and precedence constraints into structured JSON, plus a precomputed signals block (script task count, fuzzy lookup presence, container nesting depth, dynamic connection strings) that drives risk scoring downstream:

python3 scripts/parse_dtsx.py MyPackage.dtsx
python3 scripts/parse_dtsx.py ./packages/ --out portfolio.json # batch mode

Real .dtsx files are messy, so the parser is built to never crash. A malformed or partial file still returns a result, with parse_status: "failed" or "partial" and a plain-English explanation, instead of an unhandled exception halfway through a 200-package batch.
Risk scoring
Each package starts at Low and escalates based on concrete signals: a Script Task pushes it to Medium; a Fuzzy Lookup, an SCD Wizard, or a deprecated CDC/Attunity component sends it straight to High. The full heuristic table lives in references/ssis-fabric-mapping.md so the reasoning is inspectable and tunable, not baked into a black-box score.

What it deliberately doesn't do yet
Phase 1 is inventory and classification only. Phase 2 — drafting actual Fabric pipeline JSON or Dataflow Gen2 skeletons for the Low/Medium risk packages — is scoped in the SKILL.md but gated behind a human reviewing the Phase 1 output first. And every artifact Phase 2 eventually produces will carry a DRAFT / NEEDS REVIEW label. I'd rather ship something honest about its limits than something that quietly overclaims.
Try it
Repo's on GitHub [https://github.com/HBBH11/ssis-fabric-migration-assistant] — includes a synthetic sample .dtsx and a full example report generated from it, so you can see the output shape before running it against your own packages. Feedback on the risk heuristics against real-world packages would be genuinely useful; I calibrated them from experience, not a formal study.

DEV Community: Bayrem Hamrouni

I built a Claude Skill that inventories legacy SSIS packages before a Fabric migration