I've been doing SSIS development since SQL Server 2005. I know where every body is buried: the Data Flow's memory pressure at scale, the deployment model improvements in the 2012 project model, the debugger with data viewer that saves hours of "what is actually in this pipeline" investigations. ADF is not going to erase that ten years of muscle memory. But it doesn't need to replace SSIS to be worth using. Let me give you the honest comparison.
Where SSIS Wins, Clearly
Transformation Depth
SSIS's Data Flow Task is a full transformation engine. Derived Column, Lookup, Conditional Split, Merge Join, Aggregate, Pivot, Unpivot, Fuzzy Lookup, Data Conversion — these are all built in and debuggable with live data flowing through them. ADF's Copy Activity moves data from A to B. That's it. If you need to clean, reshape, join, or aggregate data mid-pipeline, you're writing SQL in a stored procedure and running it as a separate activity. That works, but it's not a transformation engine.
The Debugger
SSIS gives you a debugger with a data viewer. You set a breakpoint on a data flow path, run the package, and watch rows flow through the component. You see exactly what's in the buffer at that point. This is invaluable for diagnosing data quality problems. ADF gives you green and red status icons after the fact. Debugging a failed ADF activity means reading truncated error messages and digging into gateway logs. The development experience gap is significant.
Local Development
SSIS packages run locally in Visual Studio. You can develop, debug, and test without touching Azure. ADF requires a live Azure connection — you're developing against a deployed factory in the browser. There is no local ADF runtime, no emulator, no offline mode. Every change goes directly to the cloud.
Git Integration (or: Files Are Versioned by Definition)
An SSIS project is a folder of .dtsx files and a .dtproj file. Drop it in a git repo and you're done — every package is versioned, diffable, and reviewable. ADF's artifacts are JSON that lives in Azure, edited through a browser. There is no git integration in 2014. Manual workarounds exist and I'll cover them, but this is a real operational cost for any team larger than one developer.
Connector Maturity
SSIS has been connecting to everything for fifteen years. The built-in adapters plus Attunity connectors for Oracle and Teradata cover the vast majority of enterprise source systems. ADF's connector list in 2014 is short: Azure Blob, Azure SQL, Azure SQL Data Warehouse, SQL Server via gateway, Oracle via gateway, MySQL. If your source isn't there, you're writing custom code.
Where ADF Wins, Clearly
No Infrastructure
This one is straightforward. No server to provision, no runtime to install, no Windows Service to monitor, no SSIS catalog database to maintain, no DTC configuration to debug. ADF runs in Azure's managed fabric. For greenfield cloud projects, eliminating this operational overhead is a genuine win.
Scale-Out Compute
Copy Activity uses Azure's cloud data movement infrastructure — it scales horizontally without you touching anything. Moving a terabyte? ADF throws more compute at it. SSIS on a fixed server is bounded by the server's resources. For large-volume cloud-to-cloud transfers, ADF's throughput ceiling is substantially higher than a single SSIS server.
Native Azure Integration
Azure Blob, Azure SQL Database, Azure SQL Data Warehouse, Azure Data Lake Store, HDInsight — these are first-class in ADF. Authentication flows through the Azure fabric. No ODBC driver installs, no connection string gymnastics, no firewall rules between Azure services. SSIS treats Azure services as external sources requiring connectors; ADF treats them as home.
Infrastructure as Code from Day One
ADF's pipeline definitions are JSON files. They are deployable artifacts. You can template them for dev/test/prod with environment-specific linked services, check the templates into source control, and deploy with a PowerShell command. SSIS packages are deployable as ISPACs in the 2012 model, but the configuration management story for environment-specific settings is more complex.
Pay-Per-Run Economics
ADF charges per activity run plus data movement volume. For workloads that run infrequently or with variable volume, this is cheaper than keeping an SSIS server running around the clock. For high-frequency workloads, do the math — fixed infrastructure may win at scale.
The Honest Decision Framework
ADF is the right choice when: your data lives primarily in Azure services, you're building a greenfield pipeline without existing SSIS investment, your transformation logic lives in SQL stored procedures, and you have one developer (no git collaboration pain yet).
SSIS is the right choice when: your data sources are predominantly on-premises or non-Azure cloud, you need complex in-flight transformations (lookups, fuzzy matching, row-by-row conditional logic), you have a team of developers who need git-based collaboration, or you have an existing SSIS investment that would take months to rebuild.
The verdict in mid-2014: ADF supplements SSIS, it does not replace it. Use ADF for cloud-native Azure workloads. Keep SSIS for on-premises ETL, complex transforms, and team development scenarios. The right answer for most shops is both tools, deployed where each excels.
Next post I'll cover the practical setup — what Azure expects from you before you write your first JSON. If you're trying to make this decision for a real project and want to talk through the specifics, I'm here to help.