SSIS to Azure Data Factory Migration Guide
"Migrate SSIS to ADF" isn't one project — it's a decision between two genuinely different paths, and picking the wrong one for your package portfolio is where most of these migrations lose time.
1. The two real paths
- Lift-and-shift via Azure-SSIS Integration Runtime — your existing .dtsx packages run largely unchanged, hosted in an Azure-SSIS IR that's provisioned and managed through Azure Data Factory. Minimal rework, fastest path to "running in Azure."
- Native rebuild in ADF — pipelines are recreated using ADF's own activities (Copy Activity, Mapping Data Flows, and orchestration), replacing SSIS constructs rather than hosting them. More upfront work, but cloud-native monitoring, scaling, and long-term maintainability.
2. When lift-and-shift is the right call
Favor Azure-SSIS IR when packages are complex (heavy use of Script Tasks, custom components, or intricate control flow), the timeline is tight, or the goal is simply getting out of an on-premises SSIS server without a full re-engineering project. It's also a reasonable intermediate step — get running in Azure first, rebuild the highest-value pipelines natively later, on your own schedule.
3. When a native rebuild is the right call
Favor rebuilding in ADF when packages are relatively simple, you want to take advantage of ADF's broader connector ecosystem and native monitoring/alerting, or the long-term plan is to move away from SSIS entirely rather than carry it forward indefinitely. Native pipelines are also easier to hand off to a team that doesn't have deep SSIS background, since ADF's authoring model is more approachable.
4. Component mapping — the practical cheat sheet
| SSIS component | ADF equivalent |
|---|---|
| Data Flow Task | Copy Activity (simple movement) or Mapping Data Flow (complex transformations) |
| Control Flow (Sequence, For Each Loop, etc.) | Pipeline activities: ForEach, If Condition, Execute Pipeline |
| SSIS variables and parameters | ADF pipeline and dataset parameters |
| Package Configurations / connection strings | Linked Services, ideally backed by Azure Key Vault |
| Execute SQL Task | Stored Procedure Activity or Script Activity |
| Script Task / custom .NET components | No direct equivalent — typically an Azure Function, Databricks notebook, or custom activity |
5. What commonly breaks or gets missed
- Custom Script Tasks and third-party components — these have no drop-in ADF equivalent and usually require rebuilding the logic as an Azure Function or, for heavier transformation logic, a Databricks notebook.
- SSISDB-based logging and reporting habits — teams used to querying SSISDB for execution history need to rebuild that reporting against ADF's own monitoring and Azure Monitor integration; it doesn't map one-to-one.
- Error handling patterns — SSIS's event handlers and precedence constraints don't translate directly; ADF's retry policies and activity dependency conditions (Succeeded/Failed/Completed/Skipped) need to be deliberately rebuilt, not assumed equivalent.
- Performance characteristics — a package that was tuned for an on-premises SSIS server's memory and I/O profile may behave differently under Azure-SSIS IR sizing, and Mapping Data Flows have their own (Spark-based) performance tuning considerations separate from either.
6. Test in parallel before cutover
Run the old and new pipeline against the same source data and compare outputs row-for-row (or at minimum, aggregate-level) before retiring the original. This catches silent logic differences — a transformation that "looks right" in ADF but handles a null, a data type conversion, or an edge case differently than the original SSIS package did.
7. Start with an inventory, not a migration plan
Before committing to one path for the whole estate, inventory your packages by actual complexity — number of components, use of custom code, data volume. It's common to lift-and-shift the complex, high-risk packages first (to get off on-premises infrastructure quickly) and rebuild the simpler, high-value ones natively where the ADF investment pays off fastest.
The migrations that go badly aren't usually the technically hard ones — they're the ones where nobody decided up front which packages get lifted and which get rebuilt, and the approach gets picked package by package under deadline pressure.
Sitting on a pile of SSIS packages and not sure where to start?
Free 20-minute fit call — bring your package inventory, get a straight read on lift-and-shift vs. rebuild.
Book a free fit call