Back to Blog

Data Factory vs SSIS - Migration Guide for Australian Businesses

April 27, 2026•11 min read•Michael Ridland

If you are reading this, you probably have a server (or three) running SSIS packages that nobody wants to touch, the original developer left in 2019, and someone in the leadership team has started asking why you are still paying for SQL Server licences just to run ETL.

That is the standard starting point for almost every SSIS to Data Factory conversation we have in Australia. The packages still work. They are just expensive to maintain, hard to monitor, and slowly becoming a hiring problem because the new graduates have never seen a dtsx file in their life.

This guide is for the person who has to make the call. Should you migrate to Azure Data Factory, run a hybrid setup using the SSIS Integration Runtime, or rebuild your pipelines using a newer pattern like Microsoft Fabric Data Factory? I will give you our honest recommendation for each scenario, including when staying on SSIS is genuinely the right call.

What SSIS is actually good at (and where it falls down)

SSIS still has fans, and they are not wrong. For batch-oriented, on-premises SQL Server workloads with complex transformations, SSIS is a mature, capable tool. The Script Task gives you full .NET access, the Data Flow components are well understood, and developers who know it can build pipelines fast.

The problems are usually not technical. They are operational.

SSIS pipelines are tied to a Windows server with a SQL Server licence. Monitoring is fragmented across SQL Server Agent, the SSIS catalogue, and whatever logging you bolted on. Scaling means buying more hardware. Source control is awkward because dtsx files do not diff well. And the talent pool is shrinking. We have done three engagements in the last year where the SSIS environment was effectively unmaintainable because the only person who understood it had retired.

Data Factory is not strictly better at every task. It is better at the operational story: managed service, consumption-based pricing, native integration with Azure storage and SQL services, and a tooling ecosystem that the current generation of data engineers actually wants to work with.

The three migration paths

There are three realistic paths from SSIS to a cloud-native ETL setup. Pick the wrong one and you will spend a year solving the wrong problem.

Path 1 - Lift and shift to SSIS Integration Runtime on Azure Data Factory. Your existing SSIS packages run on a managed Azure VM cluster, orchestrated through Data Factory. Minimal code change, fastest to deliver, but you keep most of the architectural baggage.

Path 2 - Rebuild in Azure Data Factory using copy activities and Mapping Data Flows. You redesign each pipeline using ADF native patterns. Slower, more expensive upfront, but you actually get the operational benefits.

Path 3 - Rebuild in Microsoft Fabric Data Factory. The newest option. If your destination is Fabric anyway (OneLake, Power BI semantic models, Lakehouse), this is the path that pays off long term. We are seeing more clients pick this one in 2026.

I will give you the cost ranges, timelines and decision criteria for each below.

Path 1 - SSIS Integration Runtime (lift and shift)

If your SSIS environment is large, complex, and works fine but is operationally painful, the SSIS Integration Runtime is the lowest-risk way to get off the metal.

You point Data Factory at an SSISDB hosted in Azure SQL or SQL Managed Instance, deploy your existing packages, and orchestrate them with ADF pipelines. The packages run on Azure-managed VMs that you pay for by the hour.

What you get:

  • Existing packages run with minimal change
  • Managed infrastructure (no more patching Windows servers)
  • ADF orchestration on top, which gives you proper monitoring and alerting
  • Hybrid scenarios via the Self-Hosted Integration Runtime if you still need to hit on-premises sources

What you do not get:

  • A modern ETL architecture
  • Significant cost savings (more on this below)
  • Easier hiring (you still need SSIS people)

Indicative cost in AUD: The SSIS IR is priced per node. A small D2 node sits around $0.80 to $1.20 per hour. A typical mid-sized SSIS environment running 8 to 12 hours a day on a D4 or D8 node will land somewhere between $1,200 and $4,500 per month for compute, plus your Azure SQL costs for SSISDB ($400 to $1,500 per month depending on tier). Add development time of $35,000 to $90,000 for the migration itself depending on how many packages you have.

We use this path when the client has 50 plus packages, limited budget for a rewrite, and a board that needs to see progress within 90 days. It is the practical answer, not the elegant one.

Path 2 - Native Azure Data Factory rebuild

This is the rebuild path. You take each SSIS package and redesign it using ADF Copy Activities, Mapping Data Flows, Stored Procedures, and where appropriate, Azure Functions or Databricks notebooks.

When done well, the result is operationally cheaper, easier to monitor, and far easier to hand over to a new team member. When done badly (and we have seen this), you end up with a fragile chain of activities that nobody understands and that costs more to run than the original SSIS environment.

The traps:

  • Mapping Data Flows are expensive. They spin up a Spark cluster every time they run. If you treat them as a drop-in replacement for SSIS Data Flow tasks you will be shocked by the bill.
  • Activity counts add up. ADF charges per activity execution, and naive translations of SSIS package structure tend to produce hundreds of small activities.
  • Parameter handling is different. SSIS configuration patterns do not translate directly. You need to redesign for ADF's parameter and global parameter model.

Indicative cost in AUD: Native ADF rebuild for a mid-sized SSIS environment (30 to 60 packages) typically runs $80,000 to $180,000 in consulting time over 4 to 8 months. Ongoing run cost varies wildly with workload, but for batch ETL of 50 to 200 GB per day we usually see $800 to $2,500 per month all in.

The good news: once it is done, the run cost is often 40 to 60 percent lower than the original SSIS environment, and the operational story is dramatically better.

We use this path when the client has a clear cloud-first strategy, the budget for a proper rebuild, and the workload will live in Azure SQL or Synapse rather than moving on to Fabric. If you want to go deeper on this approach, our Microsoft Data Factory consultants page has more on the rebuild pattern.

Path 3 - Rebuild in Microsoft Fabric Data Factory

If your end state is Fabric (Lakehouse, OneLake, Power BI Premium semantic models), skip ADF and go straight to Fabric Data Factory.

Fabric Data Factory has the same Pipeline model as ADF, plus Dataflow Gen2, which is the spiritual successor to Power Query and is genuinely good for the common "pull data from system X, clean it, land it in the Lakehouse" pattern.

The pricing model is different. Fabric capacity is a fixed monthly cost (capacity-based, not per-activity), which makes budgeting easier but means you are paying whether you use it or not. For an Australian mid-market business, an F8 capacity sits around $1,800 to $2,200 per month list. F32 is closer to $7,500. You can pause non-production capacities to save money, but production is usually 24/7.

Where Fabric Data Factory wins:

  • Native integration with Lakehouse and OneLake
  • Power Query inside Dataflow Gen2 (a real productivity boost for analysts)
  • Single billing model across data pipelines, Power BI, and analytics
  • The Fabric ecosystem is where Microsoft is investing in 2026

Where it does not:

  • Some advanced ADF features are still maturing in Fabric
  • Self-Hosted Integration Runtime maps to On-Premises Data Gateway, which has gateway-specific quirks
  • You are committing to the Fabric pricing model, which only makes sense if Power BI and analytics live there too

Indicative cost in AUD: Migration cost is similar to ADF rebuild ($80,000 to $200,000 depending on complexity). Run cost is dominated by your Fabric capacity choice. We have a separate piece on Microsoft Fabric pricing and licensing in Australia if you want the detail.

Decision framework - which path is right for you

Here is the rough decision tree we use in scoping calls.

If your situation is... Recommended path
Large SSIS estate, tight timeline, limited budget Path 1 (SSIS IR)
Cloud-first strategy, Azure SQL or Synapse destination Path 2 (ADF rebuild)
Fabric is the analytics destination already chosen Path 3 (Fabric rebuild)
Mix of on-prem sources, Azure destinations, batch workloads Path 2 with Self-Hosted IR
Real-time or near-real-time requirements Path 2 plus Event Hubs or Stream Analytics
Workload is genuinely small (under 10 packages, low volume) Probably stay on SSIS until next refresh

That last row matters. Not every SSIS environment needs to move. If you have a stable, low-volume, well-documented SSIS setup that nobody is complaining about, the right answer might be "leave it alone and use the money somewhere else."

Common objections we hear

"Our SSIS packages have business logic embedded that nobody wants to touch."

Fair, but this is exactly the maintenance debt that makes the migration valuable. We typically run a discovery phase that documents the actual data flows (not the SSIS visual diagrams) before any code is written. About 30 percent of packages in a typical estate turn out to be redundant or duplicating logic elsewhere.

"We tried Mapping Data Flows and the bill blew out."

We have seen this too. Mapping Data Flows have their place but they are not a default. For a lot of transformations, a Copy Activity into a staging table plus a stored procedure is dramatically cheaper and just as effective. Architecture choice matters more than tooling choice.

"Can we just use the SSIS IR forever?"

Technically yes. We have a few clients who have done exactly that for three years. The risk is you keep paying for SSIS-shaped problems (licensing, talent, monitoring) without getting the modern benefits. It is a valid stopping point, but plan for the next move within 18 to 24 months.

"What about source systems that are still on-premises?"

The Self-Hosted Integration Runtime handles this. You install a lightweight agent in your network, it tunnels out to ADF, and your pipelines can read from on-prem SQL Server, Oracle, file shares, SAP and so on. We use this in almost every Australian engagement because somebody always has a legacy ERP that is not going anywhere.

What a typical migration project actually looks like

For a mid-market Australian business with 40 SSIS packages, mixed sources (SQL Server on-prem, Dynamics, a few SaaS APIs), and a Fabric destination, a typical engagement runs like this:

  1. Discovery (2 to 3 weeks) - We map every package, classify by complexity, identify duplicates and dead code. Output is a migration plan with effort estimates per package.
  2. Foundation (3 to 4 weeks) - Set up Fabric capacity, on-premises gateway, source control, deployment pipelines, monitoring. Build one reference pipeline end to end.
  3. Migration waves (8 to 16 weeks) - Packages migrated in batches of 5 to 10, each wave includes development, testing against parallel running, and cutover.
  4. Cutover and decommission (2 to 3 weeks per wave) - Parallel run for two weeks, then cut SSIS off and decommission the SQL Server licences (this is usually the moment the CFO smiles).

Total elapsed time is typically 4 to 7 months. We resist the temptation to compress this. Parallel running is non-negotiable, and rushing the testing phase is how you end up with reporting numbers that do not match.

If you want to see how we have approached this with other Australian organisations, our case studies page has a few examples worth a look.

When to call us

Engage a consultant before you start the migration if any of these apply:

  • You have more than 20 SSIS packages
  • Your source systems are mixed (cloud and on-prem)
  • You are also considering Fabric or other cloud analytics platforms
  • The current SSIS environment has limited documentation
  • You need to avoid downtime during cutover

These are the situations where a few weeks of upfront discovery saves months of rework. We typically do a fixed-price assessment that gives you a migration plan, a cost estimate within plus or minus 20 percent, and a recommended path. From there you can decide whether to engage us for delivery or take the plan to your internal team.

If you want to talk through your specific situation, get in touch. We are happy to do a 30 minute call to work out whether your environment needs a full migration or just a few targeted fixes. Sometimes the right answer is "do nothing for 12 months" and we are happy to tell you that too.

Team 400 is an Australian AI and data consulting firm. We work with mid-market and enterprise businesses across Sydney, Melbourne, Brisbane and the Sunshine Coast on Azure data platform migrations, including the SSIS to Data Factory pattern described above. More on our broader Microsoft data work on the Microsoft Fabric consultants and Microsoft AI consultants pages.