A year of ADF in production. Time to give you the actual decision framework — not "it depends," but specific criteria that determine which tool belongs on which workload. I've used both in real client engagements in 2015. Here's what I know.
Start With Where the Data Lives
This is the most deterministic factor in the ADF vs. SSIS decision. Not your team size, not your budget, not your preference — where the data lives.
If your primary sources and targets are Azure services (Blob Storage, Azure SQL Database, Azure SQL Data Warehouse, ADLS, Salesforce), ADF is the right choice. The native integration, the absence of connector middleware, the Azure-native authentication — these are genuine advantages you don't have to fight for.
If your primary sources are on-premises (SQL Server, Oracle, file shares, mainframe extracts) or non-Azure SaaS systems with no ADF connector, SSIS is the right choice. The Data Management Gateway works, but every on-premises source adds operational complexity. A factory with 15 on-premises sources via DMG is harder to maintain than 15 SSIS packages with connection managers pointing to the same sources directly.
The ADF Checklist
Choose ADF when all of the following are true:
- Primary data sources are Azure-native or have a stable ADF connector
- Transformation logic can live in SQL stored procedures (you have SQL-fluent developers)
- Team is 1-2 engineers on the factory (git discipline is manageable at this scale)
- No existing SSIS investment in the same problem domain
- Infrastructure elimination is a hard requirement (no server budget, no ops team)
- Workload is batch-oriented, not streaming or micro-batch
- Cloud-to-cloud data movement is the primary pattern
The SSIS Checklist
Stay with SSIS when any of the following are true:
- Primary sources are on-premises or in non-Azure systems without stable ADF connectors
- Transformation requirements include complex in-flight logic (fuzzy lookups, row-by-row conditional transforms, multi-source joins in the data flow)
- Team is 3+ engineers who need true git-based collaboration (ADF's manual git discipline doesn't scale to teams)
- Existing SSIS investment is substantial — the rebuild cost in ADF exceeds the SSIS operational cost
- Local development and debugging without cloud dependency is required
- Compliance requires full execution audit trail with SSISDB-level detail
The Git Question
I want to call this out separately because it matters more than the feature comparison. ADF still has no git integration in late 2015. For a team of 2+ engineers on the same factory, the manual git discipline — git repo for JSON, PowerShell deployment script, never edit the portal directly — carries real overhead and is prone to discipline failures.
The real operational cost of no git integration: time spent reconciling factory state with git state after discipline failures, confusion during onboarding of new engineers, inability to run a meaningful PR review process before production deploys. I've watched a client team with 3 engineers spend four hours recovering from an environment drift incident that would not have been possible with native git integration.
If your team is larger than 2 engineers, price in this overhead explicitly. It may tip the decision toward SSIS for workloads that could technically run in either tool.
Cost Model
ADF charges per activity run and per data movement volume. SSIS on a server charges a fixed infrastructure cost regardless of workload.
The math favors ADF when: workloads are sparse (pipelines run a few times per day), data volumes are variable with frequent low-volume runs, and infrastructure operational overhead has a cost (managed server, Windows licensing, DBA time for SSISDB maintenance).
The math favors SSIS when: pipelines run frequently (dozens per hour) with consistent volumes, server infrastructure is already in place and amortized, and the team already manages SQL Server for other workloads.
Do the actual math for your workload. Rule of thumb: if your activity runs exceed 100,000 per month with consistent volume, model the SSIS server cost. Below that threshold, ADF's economics are typically better.
The Migration Story Is Not Ready
There is no SSIS-to-ADF migration tool. There is no automated translation from .dtsx packages to ADF pipeline JSON. Migration is a rebuild, not a translation. Every package requires analysis, redesign for ADF's idiom (stored procedures for transforms, slice model for scheduling, DMG for on-premises sources), and testing from scratch.
For any organization with meaningful SSIS investment — packages that took years to build, business logic embedded in data flows, complex control flow with error handling — the migration cost is high and the risk is real. Don't migrate because ADF is new and interesting. Migrate when the migration TCO is lower than the SSIS maintenance cost, which for most mature SSIS implementations it is not in 2015.
The 2015 Verdict
ADF and SSIS are complementary tools, not competitors. Greenfield cloud-first teams with Azure-native sources should use ADF — the infrastructure elimination and native integration are real advantages. Teams with existing SSIS investment, complex transformation requirements, or large engineering teams should keep SSIS and not migrate yet.
The tool I'm watching: ADF V2, which is on the roadmap with parameterization, better authoring, and allegedly git integration. If those features ship, the calculus shifts. I'll be evaluating V2 as soon as it's available and will update this framework accordingly.
For now: right tool for the right workload. If you're making this decision for a real project and want to pressure-test the framework against your specific situation, I'm here to help.