What Is SQL Server Integration Services (SSIS), and Which Cloud Alternatives Replace It? Azure Data Factory vs. Fivetran vs. Matillion (2026)

SQL Server Integration Services (SSIS) is the ETL tool that comes with SQL Server. It still works in 2026, but SQL Server 2025 removed some of its parts, and Microsoft is putting its new SSIS work into Fabric.

If you run SSIS today and your data is moving to a cloud warehouse, you have two options. You can lift-and-shift the packages to Azure Data Factory or Fabric and keep running them as they are. Or you can rebuild them as ELT with a tool like Fivetran, Matillion or Erathos and do the transforms in the warehouse. Lift-and-shift is faster. Rebuilding costs more up front, but your pipelines end up built for the warehouse you're moving to.

What is SQL Server Integration Services (SSIS)?

SQL Server Integration Services (SSIS) is Microsoft's tool for building ETL jobs (extract, transform, load). It reads data from sources, cleans and reshapes it, and writes it to a database or warehouse. It is part of SQL Server setup and has shipped with SQL Server since 2005, when it replaced the older DTS (Data Transformation Services).

In SSIS you build your jobs as packages, and each package has a control flow and a data flow:

• Control flow sets the order of steps. Tasks run SQL statements, move files over FTP, send email, or start a data flow. Containers loop over files or group tasks together.
• Data flow moves the rows. Sources read data, transformations clean, aggregate, merge or copy it, and destinations write it out.

Developers build packages visually in Visual Studio with the free SQL Server Integration Services Projects 2022+ extension, which works with Visual Studio 2026 and 2022. Visual Studio saves each package as a .dtsx XML file. When a project is ready, you deploy it to the SSIS Catalog, a SQL Server database called SSISDB that holds your packages and runs them. SQL Server Agent can then run them on a schedule.

Here's an overview:

[IMAGE 1: upload gtm-1362-img1.png here]

SSIS has no price of its own. Microsoft treats it as part of SQL Server, so if it runs on the same machine as the database engine, your SQL Server license covers it. A standalone SSIS server needs its own license.

Your SQL Server edition decides which SSIS features you get. Standard edition includes the built-in connectors, tasks and transformations, but you need Enterprise for the following:

• The high-performance Oracle and Teradata connectors.
• The SAP BW source and destination.
• Fuzzy grouping and fuzzy lookup, which match rows that are close but not identical.
• The Scale Out Master, which spreads package runs across several machines.

Is SSIS still supported in 2026?

Yes. SSIS 2025 is generally available and comes with SQL Server 2025, and Microsoft has announced no end-of-life date. But SQL Server 2025 removed several SSIS components, and Microsoft is pointing new SSIS work at Microsoft Fabric.

Microsoft's What's New page lists the SSIS changes in SQL Server 2025 that can break an upgrade:

• Removed: the Change Data Capture (CDC) components by Attunity and the CDC service for Oracle. CDC is how a tool reads only the rows that changed since the last run.
• Removed: the Microsoft Connector for Oracle.
• Moved out: the Hadoop Hive, Hadoop Pig and Hadoop File System tasks.
• Deprecated: 32-bit mode. SQL Server Management Studio 21 and SSIS Projects 2022 now support 64-bit only.
• Breaking change: code that uses the SSIS .NET API has to update its references and rebuild.

If you're on Linux, it's worse. SSIS isn't available for SQL Server 2025 on Linux at all. Even on SQL Server 2022, the Linux build has no SSIS Catalog or SQL Server Agent scheduling, and it can't run third-party components.

So a package that reads from Oracle or uses the Attunity CDC components needs rework before it can move to SQL Server 2025. Staying on SQL Server 2022 buys you time, since its extended support runs to January 11, 2033.

Microsoft announced SSIS 2025 on the Fabric blog at Ignite in November 2025. Fabric also got an activity that runs SSIS packages (still in preview), which we'll cover in the Azure section below.

Why do teams move off SSIS?

Teams move off SSIS because it ties their pipelines to SQL Server machines they have to run and patch themselves, and because its XML package files are hard to manage in Git. This gets worse when the data is moving to a cloud warehouse like BigQuery, Databricks or Snowflake.

• Servers to own. Microsoft is pushing ETL toward Fabric because on-prem SSIS doesn't scale well and takes a lot of work to maintain. To spread runs across more machines you need Scale Out, and the Scale Out Master is Enterprise-only.
• Source control. A .dtsx file stores tasks and layout data in one XML document. A simple rename showed up as eight changed regions in a diff, and two developers who add different packages at the same time both edit the project file and get a merge conflict.
• The ELT model. Cloud warehouses can run transformations themselves, so modern pipelines load raw data first and transform it in SQL inside the warehouse (ELT instead of ETL). An SSIS data flow does the transform step on the SSIS server before loading.

Staying on SSIS is a fair choice for some teams. For a mid-size company with stable ETL into on-prem SQL Server, the platform works fine. As SSIS trainer Andy Leonard says, "most SSIS pain doesn't come from the platform itself. It comes from lifecycle gaps," like weak change tracking and low confidence in deployments.

We think moving pays off when your target changes. If your warehouse moves to the cloud, rebuilding the pipelines for it costs less over time than keeping a Windows server alive just to feed it.

Can you run SSIS packages in Azure Data Factory or Fabric?

Yes. Azure Data Factory (ADF) can run your existing SSIS packages on the Azure-SSIS Integration Runtime, with little or no change to the packages. Fabric Data Factory can run them too, using its Invoke SSIS Package activity, but that activity is still in preview and blocks on-prem sources.

This is called lift-and-shift. You keep the same .dtsx files and only change where they run.

Azure Data Factory and the Azure-SSIS Integration Runtime

The Azure-SSIS Integration Runtime is a fully managed cluster of Azure VMs that only runs SSIS packages. You bring an Azure SQL Database or SQL Managed Instance to host SSISDB, and you deploy from Visual Studio and SQL Server Management Studio the same way you do on-prem. You pick a node size to scale up and a node count to scale out. To keep the bill down, you stop the cluster when nothing is running.

Here's what that looks like:

[IMAGE 2: upload gtm-1362-img2.png here]

Microsoft charges for each node by the hour. These are the East US list prices with the SQL Server license included. The last column is what you pay if you bring your own licenses through Azure Hybrid Benefit:

One D2 V2 Standard node left on all month costs $0.795 × 730 hours, about $580. You pay for the SSISDB database separately in Azure SQL. ADF also charges for orchestration at $1 per 1,000 activity runs on the Azure runtime.

Azure-SSIS runtimes don't work in Synapse pipelines. Microsoft also calls Fabric Data Factory the next generation of ADF and points new users there.

Fabric Data Factory and the Invoke SSIS Package activity

Fabric's Invoke SSIS Package activity runs .dtsx files stored in OneLake. Fabric bills it at 1.35 capacity unit (CU) hours per vCore for as long as SSIS is up. The runtime stays up for 30 minutes after the last activity, and during the preview each workspace gets a fixed 4 vCores.

The preview also has some limits:

• Packages must live in OneLake.
• Packages can't read from or write to on-premises sources and destinations.
• Private network endpoints aren't supported.
• Custom and third-party components don't run.

So a package that reads from an on-prem SQL Server, or uses a third-party add-in, can't run on Fabric today. For now, those packages stay on SQL Server or move to ADF's Azure-SSIS runtime.

Lift-and-shift is a good way to get off your own servers fast. But your packages are still SSIS packages built as ETL, and the XML files still cause merge conflicts. You've moved the problem to Azure without fixing it.

Which ELT tools replace SSIS?

Fivetran, Matillion, Informatica and Erathos replace SSIS by rebuilding the work as ELT. A managed tool copies SQL Server tables into a cloud warehouse, and SQL inside the warehouse does the transforms. None of them can run .dtsx files, so on this path you rebuild each package.

Fivetran

Fivetran is a managed ELT service with 750+ source connectors. Its SQL Server connector supports SQL Server 2012 to 2025 and can sync only new changes with Change Tracking, CDC, Binary Log Reader or Teleport Sync:

• Change Tracking is light, but it can't sync tables without a primary key.
• CDC tracks every change, with or without a primary key, but costs the database more processing and storage. New tables or columns need a new CDC instance.
• Binary Log Reader reads the transaction log, only on self-hosted SQL Server 2016 to 2025.
• Teleport Sync compares row hashes between syncs, so it works even when change tracking is off on the database. It stops at 800 tables and 75 million rows per table.

Fivetran prices by monthly active rows (MAR), billed per million. Each connection is priced separately, the rate per million drops as that connection's volume grows, and every standard connection with any usage has a $5 base charge. The Free plan covers 500,000 MAR. Fivetran doesn't publish its dollar rate per million rows:

[IMAGE 3: upload gtm-1362-img3.png here]

Fivetran is a strong fit for global companies with many sources and strict compliance needs like PCI DSS Level 1 and HIPAA. The bill grows with each connection's rows, so if you have many busy SQL Server tables, it's worth modeling the cost before you commit.

Matillion

Matillion's Data Productivity Cloud is a visual pipeline designer that runs transformations inside the warehouse. For teams that like drag-and-drop, it feels the closest to SSIS. Matillion's own Maia agent claims to convert SSIS logic into Matillion pipelines.

For SQL Server, Matillion's CDC uses agents that you host yourself. Each agent writes changes as files to cloud storage, and each pipeline needs its own agent. Matillion then loads that data into Snowflake, Databricks, Redshift or BigQuery.

Matillion prices in credits. You spend credits on task hours (the combined run time of pipeline tasks) and on developer users beyond your plan's limit. Matillion doesn't publish a price per credit, and streaming CDC is listed on the Scale plan:

[IMAGE 4: upload gtm-1362-img4.png here]

Matillion is great when most of an SSIS package's value is in its transformation logic and your team wants to keep building visually.

Informatica

Informatica's cloud platform, IDMC (Intelligent Data Management Cloud), became part of Salesforce when the acquisition closed on November 18, 2025. It prices in Informatica Processing Units (IPUs), a single pool of units you can spend on any of its cloud services, and you have to ask for a quote instead of seeing a list price. It suits large companies that want many Informatica cloud services under one contract.

Erathos

Erathos is a managed ingestion platform. It copies SQL Server tables into BigQuery, Databricks, Redshift, PostgreSQL, ClickHouse, Azure SQL or S3 Iceberg, and you transform the data with SQL or dbt in the warehouse. You can sync SQL Server with CDC, partial syncs or a full refresh:

• CDC takes a first full snapshot, then streams changes from SQL Server's CDC tables.
• Partial syncs pull only rows past a date or datetime cursor, which needs a primary key and a date column (sync types).
• Full refresh reloads the whole table.

You set each table's schedule anywhere from every 5 minutes to daily. Erathos flags schema changes and sends alerts to Slack, Discord or email, and it plugs into dbt Cloud, Airflow and Prefect for orchestration.

Here's how one table moves through a rebuild:

[IMAGE 5: upload gtm-1362-img5.png here]

Erathos charges for the rows it writes to your warehouse each month, and paid plans include unlimited connectors:

Erathos is a good fit when you need SQL Server data in BigQuery, Databricks or Redshift at a price you can read off a page. It only rebuilds pipelines (it can't run .dtsx packages), and it doesn't support Snowflake as a destination today.

Every CDC-based tool runs into the same SQL Server limit. SQL Server's cleanup job deletes captured changes after 3 days by default, so if a connection is paused for longer than that, it needs a fresh full snapshot. You can avoid this by raising the retention period on the database.

How do the SSIS alternatives compare?

The SSIS alternatives fall into two groups: tools that run your existing packages (ADF and Fabric) and tools that replace them with ELT (Fivetran, Matillion, Informatica, Erathos). Here's how they compare:

A lift-and-shift tool makes sense when you need to leave your servers this quarter. An ELT tool makes more sense when the target is a cloud warehouse you plan to keep for years.

How do you migrate off SSIS?

Moving off SSIS starts with a list of every package and what it depends on. Then you map each SSIS part to its modern equivalent and decide, package by package, whether to lift-and-shift or rebuild. Moving to Fabric or anywhere else is "a project, not a setting".

1. Inventory your packages

For each package, you want to know:

• Where is it deployed: the SSIS Catalog, msdb, or the file system?
• Does it use the Oracle connector, CDC components or 32-bit components that SQL Server 2025 removed?
• Does it use third-party components, which Fabric's preview can't run?
• Does it read from or write to on-prem systems, which Fabric's preview also blocks?
• Do any automation scripts call the SSIS .NET API?

Each package also holds rules nobody wrote down, like implicit type casts and default values. An ELT rebuild has to repeat those rules in SQL, so it helps to write them down during the inventory:

[IMAGE 6: upload gtm-1362-img6.png here]

2. Map each SSIS part to its replacement

Here's what replaces each SSIS part on each path:

And here are the tools on each path:

[IMAGE 7: upload gtm-1362-img7.png here]

3. Decide per package

The right path can be different for each package. Here's how we'd handle the common cases:

• Has to leave your servers soon: ADF's Azure-SSIS runtime gets it running in Azure with the fewest changes.
• Uses on-prem sources or third-party components: it stays on SQL Server or the Azure-SSIS runtime for now, since Fabric's preview can't run it.
• Cloud-only, and your company already runs on Fabric: the Invoke SSIS Package activity works, as long as the preview limits are fine for you.
• Mostly copies SQL Server tables into a warehouse: a managed ingestion tool such as Erathos replaces the copy step, and the logic moves into SQL models.
• Heavy transformation logic your team wants to keep building visually: Matillion is the closest match.

A rebuild also fixes the Git problem. SQL and dbt models are plain text files, so when you rename something, Git only shows the lines you edited.