I want to be upfront about my bias before I tell you to retire something: I love SSIS. Early in my data career I spent a great deal of time building SQL Server Integration Services packages — the on-premises ETL workhorse that has moved data around Microsoft shops for the better part of two decades — and I got good enough at it to generate them by the hundred rather than click them together by hand. So this isn't a fashionable "on-prem bad, cloud good" take from someone who never ran the thing. It's a blueprint from someone who built a lot of SSIS and has now helped enough organisations move off it to have opinions about how to do it without hurting yourself.

Because SSIS isn't bad. It's aging, in a specific way that's worth being honest about, and the migration is worth doing — carefully, and without pretending it's just a copy.

Why retire it at all, if it works

The honest case for moving isn't that SSIS stopped working. Plenty of SSIS runs fine and will keep running fine for years. The case is about where it lives and what it costs you to keep it there.

  • It's an island. SSIS runs on servers you maintain, on a schedule tied to those servers, disconnected from the cloud-native world your analytics increasingly lives in. Every year, the rest of your stack moves into Fabric and Azure, and the SSIS estate sits there as a separate thing with its own operational burden, its own patching, its own tribal knowledge.
  • The knowledge is thinning. The people who deeply understand your SSIS packages are, statistically, getting rarer and more senior. New talent learns cloud-native tools. The maintenance risk isn't technical decay; it's that fewer and fewer humans can safely touch what you've got.
  • It doesn't compose with the new world. The value of moving isn't a faster copy of the same job. It's that once your data movement lives in Azure Data Factory or Fabric pipelines, it composes with everything else — the lakehouse, the semantic model, the governance — instead of feeding it from the outside through a hatch.

That's the real argument. Not "SSIS is obsolete" — it's "SSIS is increasingly a disconnected island in an estate that's consolidating everywhere else."

The blueprint: how to actually move

Here's the sequence I'd actually follow, learned partly by not following it and regretting it.

  1. Inventory honestly, and rank by value, not by ease. List every package and be ruthless about what each one is genuinely worth. You will find packages that haven't produced anything anyone uses in years. Those don't get migrated — they get retired, full stop. Migration is the best data-estate spring-clean you'll ever get; don't waste it faithfully porting dead jobs.
  2. Lift the genuinely-fine ones the low-effort way, at first. Azure Data Factory can run SSIS packages more or less as-is via its integration runtime. For packages that work and aren't worth rebuilding yet, that's a legitimate first step — get off the on-prem servers without a full rewrite. Just don't mistake that step for the destination, the way I've watched people do.
  3. Rebuild the ones that matter, natively. Your high-value, frequently-changed pipelines deserve to be rebuilt as native ADF or Fabric pipelines, because that's where they gain the composition, the scalability, and the governance integration that justified the move. This is the actual work, and it's worth spending on the pipelines that earn it.
  4. Redesign as you rebuild — don't re-implement. This is the part I care about most, because it's the part everyone skips under deadline pressure.

What not to carry across

The single biggest mistake I see — and I've written before about the more general version of this, the lift-and-shift trap — is migrating SSIS by faithfully recreating its design in a new tool. SSIS packages are shaped by SSIS-era assumptions: on-prem servers with fixed capacity, overnight batch windows because that's when the shared machine was free, "reprocess everything every night" because the hardware was a sunk cost so waste was free. Move that design unchanged into Fabric and you're paying cloud rates to faithfully preserve limitations that no longer exist.

So as you rebuild, actively question the inheritance:

  • The full nightly reload existed because compute was free once you'd bought the box. In the cloud you pay per run, so incremental patterns — the ones I spent years refining in SSIS precisely because they were hard there — are now both easier and directly cost-saving.
  • The rigid overnight window existed because of a shared finite machine. That constraint is gone; cling to it and you're scheduling around a limitation you no longer have.
  • The copy-everything-into-staging reflex made sense when storage and compute were welded together. With OneLake and reference-in-place, a lot of that copying is simply unnecessary.
Retiring SSIS isn't about escaping a bad tool. It's about not carrying a good tool's constraints into a place those constraints stopped applying. Migrate the intent, not the implementation.

Where this leaves you

If you're running on-prem SSIS in 2025, you don't need to panic, and you shouldn't rush a big-bang rewrite either. But you should have a plan, because the island is only going to get more isolated and the knowledge to maintain it only rarer. Inventory honestly and retire the dead weight. Lift the fine-but-boring packages to get off the servers. Rebuild the ones that matter as native pipelines — and when you rebuild, redesign for the world you're moving into instead of faithfully reconstructing the one you're leaving.

I say all this with genuine affection for the tool that taught me how data actually moves. Retiring SSIS well is a way of honouring what it did for you — by carrying its lessons forward and leaving its limitations behind, rather than lovingly rebuilding both in a place that deserved better.