A year ago I wrote the initial mapping of ADF concepts to SSIS equivalents. After a year of production experience, I know which mappings hold and which ones break down badly enough to cause real problems. Let's revisit this with calibrated expectations.
Mappings That Hold
Linked Service = Connection Manager. This one is solid. Both define where a data store lives and how to authenticate to it. Both are referenced by multiple pipelines/packages. The key difference is scope: Connection Managers live inside a package (or at project level in the 2012 model), Linked Services live at the factory level and are shared across all pipelines. The factory-level scope is actually better for maintainability — one linked service to update when a connection string changes, not N packages.
Dataset = Source/Destination metadata. Mostly holds. In SSIS, source and destination components carry the schema, column definitions, and connection information. In ADF, datasets carry the location, structure, and availability metadata for a data store. The partition and slice concepts in ADF datasets have no SSIS equivalent, but the metadata-container role maps well enough.
Copy Activity = Simple Data Flow Task. Holds for straightforward source-to-sink movement with column mapping. Copy Activity with SqlSink and a stored procedure for upsert maps well to a Data Flow Task with OLE DB Source and OLE DB Destination in bulk load mode, followed by an Execute SQL Task. The critical difference: no in-flight transformation in Copy Activity. If your Data Flow Task has any transforms between source and destination, this mapping breaks immediately.
Mappings That Break Down
Pipeline is not a Package. This is the one that causes the most migration confusion. An SSIS package is a self-contained artifact — it knows its own connection managers, variables, tasks, and data flows. You can export a package, deploy it independently, run it on any SSIS server with the right connections configured. An ADF pipeline references external objects (linked services, datasets) that must exist independently in the factory. The pipeline is not self-contained. You cannot export a pipeline and run it on another factory without also exporting all its referenced datasets and linked services.
Practically: SSIS packages are portable units. ADF pipelines are components of a factory. The migration unit in ADF is the factory, not the pipeline. Plan accordingly.
ADF Scheduling is not SQL Agent. SQL Agent fires a job at a scheduled time. Simple. If the server is up and the agent is running, the job runs. ADF's slice model is data-driven, not purely time-driven. A slice runs when its input dataset's slice is Ready, not simply when the clock hits the scheduled time. This means ADF dependencies are data dependencies, not just time dependencies.
The slice model is more resilient — missed runs backfill automatically, dependencies are tracked and enforced. It is also harder to reason about for simple "run this every morning at 6 AM" requirements. You have to understand why a slice is in Waiting state (upstream not Ready? dependency not met? concurrent slice running?) rather than simply asking "did the job run at 6 AM?"
Activity Dependencies are not Precedence Constraints. SSIS's Precedence Constraints let you build explicit multi-path flows: on success go here, on failure go here, on completion always go there, combine multiple constraints with AND or OR logic. ADF's inputs/outputs dependency model says: Activity B starts when Activity A's output dataset has a Ready slice. Period. There is no on-failure path, no OR-dependency, no conditional branching.
Building error handling in ADF requires a different pattern: separate pipelines for success and failure paths, triggered by different output dataset states. It works but it's less expressive and more verbose than SSIS precedence constraints for complex control flow scenarios.
Concepts With No SSIS Analog
Slice state tracking. Every output dataset slice has state (Waiting, Ready, In Progress, Succeeded, Failed, Skipped) that persists across runs. ADF knows the history of every slice — when it ran, how long it took, what its current state is. SSIS has execution logs in SSISDB, but they're execution records, not state machines. The slice state model is what enables automatic backfill and dependency enforcement between pipelines.
The Data Management Gateway pattern. SSIS runs on a server in your network that has direct network access to source systems. ADF runs in Azure. The DMG bridges this gap — it's an outbound-only tunnel agent that enables ADF to reach on-premises sources without requiring inbound firewall rules. SSIS has no equivalent concept because it doesn't need one: the SSIS server is already on the network.
On-demand HDInsight clusters. ADF can provision a Hadoop cluster for a job and tear it down when done. This is a cloud-native pattern with no on-premises SSIS analog — SSIS can submit jobs to existing Hadoop clusters via connectors, but it doesn't provision and manage cluster lifecycle.
The Practical Implication
Don't expect one-for-one migration from SSIS to ADF. The surface concepts map loosely, but the execution models are different enough that a "translate each package to a pipeline" approach will produce ADF pipelines that fight the tool's grain. Build ADF pipelines in ADF's idiom: lean on datasets and slice dependencies for sequencing, use stored procedures for transformation logic, design for backfill resilience from the start.
If you're planning an SSIS-to-ADF migration and want to think through the mapping for your specific workloads, I'm here to help.