Azure Synapse Pipelines vs Standalone ADF

You open Synapse Studio, select Integrate, and find yourself looking at something very familiar: a canvas, an activities pane, a Copy activity. It looks like Azure Data Factory because it is Azure Data Factory, in a different home. The question that follows, whether to build pipelines here or in a standalone factory, turns on a short list of real differences.

The same engine

Microsoft's documentation is plain about the relationship. In Azure Synapse Analytics, the data integration capabilities such as Synapse pipelines and data flows are based upon those of Azure Data Factory (Microsoft Learn: differences from Azure Data Factory). The Synapse overview says the service contains the same data integration engine and experiences (Microsoft Learn: what is Azure Synapse Analytics).

So these transfer without change:

• Pipelines, activities and control flow.
• The Copy activity and its connectors.
• Mapping data flows.
• Triggers: schedule, tumbling window and event.
• Parameters, variables and the expression language.
• Linked services and datasets, which Synapse calls integration datasets.
• The self-hosted integration runtime for private networks.

A pipeline's JSON looks the same in both. Skills learned in one apply in the other.

The documented differences

Microsoft publishes a feature table. Its contents, at the time of writing:

The SSIS row needs a note, because Microsoft's pages do not agree. The integration runtime documentation states that Synapse pipelines currently support only Azure or self-hosted runtimes (Microsoft Learn: integration runtime), and the Synapse FAQ says SSIS runtimes are not supported at this time. The page for provisioning the SSIS runtime, on the other hand, mentions Synapse pipelines, with limitations (Microsoft Learn: create an Azure-SSIS integration runtime). If SSIS inside a workspace matters to you, confirm the current position before planning around either statement.

What each difference means in practice

No sharing of a self-hosted runtime. In Data Factory, one self-hosted runtime can be shared with other factories in the same tenant, so a single set of machines inside the network serves many factories. A Synapse workspace does not support sharing, and only one runtime instance can be installed per machine (Microsoft Learn: self-hosted integration runtime). Each workspace that reaches on-premises data therefore needs machines of its own. For an organisation with several workspaces, that is real infrastructure. Integration runtimes in ADF covers the runtime types.

SSIS belongs in Data Factory. Given the conflicting statements above, Data Factory is the dependable home for SSIS packages. If SSIS is part of the estate, plan to keep that part there. See ADF vs SSIS.

No global parameters. In Data Factory, a value such as an environment name is defined once and read by every pipeline. In Synapse the same effect needs pipeline parameters passed down from a parent, or a small configuration table read by a Lookup. Global parameters and variables covers the Data Factory feature.

No Power Query activity. Data preparation in the Power Query editor exists in Data Factory only. The gap matters less than it looks: Microsoft's comparison of Data Factory with Fabric lists that activity as deprecated on the Azure side (Microsoft Learn: differences between Data Factory in Fabric and Azure).

Deployment works differently. A data factory is promoted between environments as one ARM template. A Synapse workspace is promoted in two parts: an ARM template for the workspace and its pools, then the Synapse Workspace Deployment tools for the artifacts, pipelines, datasets, notebooks and SQL scripts (Microsoft Learn: Synapse CI/CD). Neither is harder; they are different release pipelines, and a team running both maintains both. CI/CD for Azure Data Factory covers the factory side.

Monitoring of data flow Spark jobs is the one row in Synapse's favour.

What Synapse adds

The table lists features. The larger difference is context: Synapse pipelines live beside the engines they orchestrate.

• Notebooks, Spark job definitions and SQL scripts are in the same workspace as the pipeline that runs them, in the same repository, deployed together.
• One studio and one access model for the pipeline, the Spark pool and the SQL pool.
• A notebook can be added to a pipeline from the notebook's own editor, and the notebook activity runs on the Spark pool selected in the notebook unless another is chosen.

This is convenience, not capability. Data Factory can do the same work from outside. It has a Synapse notebook activity that runs a notebook in a workspace through a linked service (Microsoft Learn: Synapse notebook activity in Data Factory):

{
  "name": "RunCleanSales",
  "type": "SynapseNotebook",
  "typeProperties": {
    "notebook": {
      "referenceName": { "value": "clean_sales", "type": "Expression" },
      "type": "NotebookReference"
    },
    "parameters": {
      "runDate": { "value": "2026-10-02", "type": "string" }
    },
    "sparkPool": {
      "referenceName": { "value": "sparkmedium", "type": "Expression" },
      "type": "BigDataPoolReference"
    }
  },
  "linkedServiceName": { "referenceName": "SynapseWorkspaceProd", "type": "LinkedServiceReference" }
}

Moving between them

There is no migration tool. Microsoft's Synapse FAQ says that to move pipelines from Data Factory into a workspace you must recreate them, by exporting the JSON of each pipeline and its related artifacts and importing it (Microsoft Learn: Synapse FAQ). The JSON is compatible; the work is manual, and anything using a feature from the table above has to be redesigned.

Treat the choice as a decision, not a default you can cheaply reverse.

How to choose

Many organisations end up with both, and that is a sound arrangement when the boundary is clear. Data Factory is the enterprise integration layer: it brings data from source systems into the lake. Synapse pipelines orchestrate what happens inside the workspace from there. The mistake is the unclear version, where the same kind of job is built in either place depending on who wrote it.

A note on what comes next

Both have the same successor. Microsoft describes Data Factory in Microsoft Fabric as the next generation of Azure Data Factory, and its Synapse SQL documentation points newcomers to Fabric as well. For a new project the comparison worth making may be with Fabric, not between these two. For existing estates, the differences above are the ones that matter today.

For the workspace as a whole, see Azure Synapse Analytics explained; for the broader product comparison, Azure Synapse vs Azure Data Factory.

Azure Data Factory and Azure Synapse are covered in the Data Engineering course.

Sources

• Differences from Azure Data Factory (Microsoft Learn) — Microsoft Learn
• What is Azure Synapse Analytics? (Microsoft Learn) — Microsoft Learn
• Integration runtime in Azure Data Factory (Microsoft Learn) — Microsoft Learn
• Create a self-hosted integration runtime (Microsoft Learn) — Microsoft Learn
• Create an Azure-SSIS integration runtime in Azure Data Factory (Microsoft Learn) — Microsoft Learn
• Continuous integration and delivery for an Azure Synapse Analytics workspace (Microsoft Learn) — Microsoft Learn
• Azure Synapse Analytics frequently asked questions (Microsoft Learn) — Microsoft Learn
• Differences between Data Factory in Fabric and Azure (Microsoft Learn) — Microsoft Learn
• Transform data with Synapse Notebook (Microsoft Learn) — Microsoft Learn