SSIS Migration to Azure: Lift and Shift, Fabric or Rebuild?

SQL Server 2016 reached the end of extended support on July 14, 2026, ten years after it shipped, and it is still widely used in enterprise environments. Writing that week, a Microsoft customer engineer listed the blockers that keep surfacing in upgrade assessments: SQL Agent jobs, linked servers, CLR code and legacy SSIS packages. The summary was blunt: “The database is rarely the hardest part.” 

That is the real decision behind any SSIS migration to Azure. Moving the database is well understood. Moving the ETL behind it is where projects either finish in weeks or drag for a year, and every month of delay now sits on paid ESUs that Microsoft back-bills to July 14 for late sign-ups. For CIOs and infrastructure heads, the question is which route each package takes, and how fast. 

This guide sets out the four realistic paths, what each one costs to build and to run, how to judge a migration partner, and a 30-day plan you can start this week. Addend Analytics runs these assessments for Microsoft data teams, and we say plainly below where hiring a partner is not the right call. 

What SQL Server 2016 End of Support Means for SSIS 

SSIS is installed and licensed as part of SQL Server, so your packages, the SSISDB catalog and the SQL Agent jobs that schedule them now sit on an unsupported platform. Nothing stops working on July 15. What stops is the flow of security fixes underneath every package that touches finance, customer or operational data. 

Extended Security Updates (ESUs) are the bridge. Microsoft Learn confirms they cover critical security fixes for up to three years, with no new features, no non-security fixes and support limited to installing the updates themselves. Billing runs hourly per core through Azure Arc, with a four-core minimum per VM, and it needs Software Assurance or pay-as-you-go licensing. ESU year one began on July 14, 2026, and Microsoft confirms that anyone subscribing after that date is back-billed to the start of the current ESU year. 

One assumption from earlier migrations no longer holds. When SQL Server 2014 left support, moving it to an Azure VM brought free ESUs. For 2016 that benefit is gone, as Microsoft Learn now states, so rehosting the same server on an Azure VM does nothing for your ESU bill. Moving the databases to Azure SQL Database or Azure SQL Managed Instance does stop the charges. 

The cost of staying unpatched is not abstract either. IBM’s 2025 report puts the global average cost of a data breach at $4.44 million, and the US average at $10.22 million. An ETL server holds credentials to almost every system you own, which makes it a poor place to accept known, unfixed vulnerabilities. 

Four Paths for SSIS Migration to Azure, Side by Side 

There are four realistic paths. Most estates end up using two of them, because a 300-package estate rarely deserves one treatment for every package. 

Option 1: Upgrade in place to SQL Server 2022 or 2025 

This keeps SSIS on your own servers and resets the support clock. It is the cheapest path when the estate is small and healthy, but it is not a free pass. Microsoft says SQL Server 2025 removes the Attunity CDC components for Oracle, the Microsoft Connector for Oracle and the Hadoop tasks, and deprecates 32-bit mode and the legacy Integration Services Service. Packages built on those pieces need rework even if they never leave the building. 

Option 2: Lift and shift to the Azure-SSIS Integration Runtime 

The Azure-SSIS Integration Runtime is a managed cluster inside Azure Data Factory that runs your existing packages. Microsoft’s migration guide describes two phases: assess packages for blockers, then redeploy them with the tools your team already uses (SSDT, SSMS, dtutil) into SSISDB on Azure SQL Database or Managed Instance, Azure Files or the IR package store. SQL Agent jobs move to the Managed Instance Agent or become Data Factory triggers. 

On-premises sources stay reachable through VNet injection or a self-hosted IR acting as a proxy, and third-party components install through custom setup. The trade-off is honest: you still own SSIS code, you still need SSIS skills, and an IR left running around the clock costs far more than one started and stopped on a schedule. 

Option 3: SSIS to Fabric Data Factory 

Fabric’s Invoke SSIS Package activity runs .dtsx files stored in OneLake inside a Fabric pipeline. Microsoft Learn lists it as preview, with clear limits today: no on-premises sources or destinations, no VNet or private-endpoint resources, and no custom or third-party components. Each workspace gets a fixed 4 vCores, billed at 1.35 CU hours per vCore of uptime, and the runtime stays up for a fixed 30 minutes after the last package finishes. 

That makes it a strong fit for packages that already read and write cloud sources, in organisations that have committed to Fabric. It is not yet a landing zone for an estate that pulls from on-premises ERP or uses Oracle CDC. 

Option 4: Rebuild as native Data Factory or Fabric pipelines 

Rebuilding replaces packages with copy activities, Dataflows Gen2, notebooks or stored procedures. It removes the SSIS dependency entirely and gives the best long-term fit with a lakehouse or Fabric warehouse. It is also the slowest and most expensive path, because C# script tasks need rewriting and business rules buried in data flows have to be rediscovered and retested. 

The four paths compared on the factors that drive the decision; timelines reflect Addend’s experience with mid-size estates and should be confirmed in an assessment. 

Pricing of Moving SSIS and SQL Server to Azure 

Build cost is driven by package count, how many distinct sources the packages touch, and how much custom code they hide. The ranges below come from Addend’s work with mid-size estates of roughly 50 to 300 packages. They exclude Azure consumption and licences. 

Indicative build costs for SSIS estates of 50 to 300 packages, based on Addend engagements; your assessment sets the real figure. 

Run Costs After the Move 

The Azure-SSIS IR is billed per second per node, and the SSISDB database is billed separately. The single biggest saving is scheduling the IR to start before the nightly batch and stop after it. Azure Hybrid Benefit lowers the licence portion if you hold Software Assurance. Model your own node size in the Azure pricing calculator. 

Fabric is easier to reason about than it looks. A nightly batch that keeps the SSIS runtime busy for two hours, plus the 30-minute idle window, uses about 13.5 CU hours a day (2.5 hours x 4 vCores x 1.35). An F2 capacity provides 48 CU hours a day, so the batch alone uses a little over a quarter of it before pipeline and storage meters. Our Fabric pricing guide covers capacity sizing in more depth. 

The ESU line in the business case 

ESU pricing rises each year, it is billed per core, and it is back-billed for late sign-ups. Ask your Microsoft account team for a written quote covering years two and three, then put it next to the migration budget. In most cases we see, two years of ESU on a busy ETL server costs as much as a lift and shift, and leaves you with nothing to show for it. 

7 Criteria for Picking an SSIS Modernization Partner 

Rank these criteria in order. A partner that fails the first two should not reach the shortlist. 

1. They inventory before they quote. A fixed price without a package count, source list and script-task count is a guess. 

2. They give a per-package decision. Retire, rehost or rebuild, package by package, rather than one approach for the whole estate. 

3. They can show the network design. Ask how the IR reaches your on-premises sources: VNet injection, self-hosted IR proxy, and how Windows authentication is handled. 

4. They define done with data. Row counts, checksums and a parallel run period that both teams sign off. 

5. They price the run, not just the build. IR scheduling, node size, and Fabric capacity usage should appear in the proposal. 

6. They are straight about preview features. Anything in the plan that depends on Fabric’s SSIS preview should be labelled as such. 

7. They leave you able to run it. Documentation, runbooks and handover sessions are scoped, not promised. 

Questions to Bring to the First Vendor Meeting 

• How many of our packages do you expect to retire, rehost and rebuild, and how will you decide? 

• Which of our packages use script tasks, custom components or 32-bit drivers, and what happens to each? 

• How will packages reach our on-premises sources once they run in Azure? 

• What does the parallel run look like, and what evidence proves a package is finished? 

• What will the new setup cost to run each month, and who owns the IR schedule? 

• Which parts of your plan depend on preview features? 

Common SSIS Migration Risks 

Most stalled SSIS projects we are asked to rescue fail for one of three reasons. 

1. Inventory surprises. Packages that read from file shares, Excel workbooks or linked servers nobody documented surface in week six, not week one. 

2. Network and identity gaps. Packages that used Windows authentication on the domain cannot reach the same sources from Azure until the network and credentials are redesigned. 

3. No agreed definition of done. Without reconciliation rules, the parallel run drags on because nobody is willing to switch off the old server. 

“Can’t we just buy ESUs and decide next year?” 

You can, and ESUs exist for exactly this. But they are back-billed to July 14, 2026, they cost more each year, they cover security fixes only, and they end in 2029. Use the first ESU year to migrate, not to postpone the decision. 

“Won’t moving SSIS to Azure take a year?” 

A lift and shift of a well-organised SSISDB estate takes weeks, not months, because packages redeploy with the same tools your team uses today. Timelines stretch when everything is rebuilt at once, which is why we phase rebuilds behind the move. 

“Is Fabric ready to run our SSIS packages in production?” 

For most estates, not yet. The activity is in preview and cannot reach on-premises sources, private endpoints or custom components. Pilot it with cloud-only packages and keep the rest on the Azure-SSIS IR until it reaches general availability. 

“What if packages break after the move?” 

The assessment flags migration blockers before anything is redeployed, and the parallel run compares outputs row by row. The old server stays live until both teams sign off, so the business never depends on an untested package. 

From Inventory to Pilot: Your First 30 Days of Migration 

1. Week 1: settle the ESU and compliance position. Confirm whether you are covered, get a written quote for years two and three, and ask security and compliance for a written view on running unsupported software. 

2. Weeks 2 and 3: inventory and assess. Catalogue every package, source, script task and job. Run an assessment for blockers and tag each package retire, rehost or rebuild. 

3. Week 4: pilot and decide. Move five to ten representative packages to the Azure-SSIS IR, or to Fabric if they are cloud-only. Measure run cost and runtime, then commit to a path for each group. 

Making the Call 

You now have what you need to choose between upgrading in place, lifting and shifting to the Azure-SSIS IR, piloting Fabric, and rebuilding, and to see which mix fits your estate. The decision deserves a proper inventory first, and taking a few weeks to get that right is reasonable. Waiting a year is not, because ESU costs climb while the risk stays the same. 

If you want a clear picture quickly, Addend’s migration assessment gives every package a decision and a cost range within three weeks. Once SSIS is off SQL Server 2016, your team can spend its time on new pipelines and reporting instead of patch schedules. 

Addend’s Approach to SSIS Modernization 

Addend Analytics is a Microsoft-focused data engineering and analytics consultancy, and SSIS estates sit at the centre of most of the modernisation work we take on. We work across the full route described in this post, so the recommendation for each package is not tied to one tool or one engagement type. Here is where we usually come in. 

• Migration assessment. We inventory every package, connection, script task and SQL Agent job, run blocker checks, and give each package a retire, rehost or rebuild decision with a cost range. Most assessments finish in two to three weeks. 

• Lift and shift to Azure. We set up the Azure-SSIS Integration Runtime, move SSISDB to Azure SQL Database or Managed Instance, design VNet or self-hosted IR access to your on-premises sources, and convert SQL Agent schedules into Data Factory triggers. 

• Fabric pilots. For teams committed to Fabric, we move a first set of cloud-only packages onto the Invoke SSIS Package activity and measure capacity use before anything larger is planned. 

• Phased rebuilds. We rebuild the packages that cost you the most time as Data Factory or Fabric pipelines, with notebooks or SQL for transformation, behind a parallel run that both teams sign off. 

• Run-cost tuning and handover. We schedule the IR, size nodes and Fabric capacity, and hand over runbooks and documentation so your team can run the new setup without us. 

Our delivery model combines Microsoft-certified engineers with an offshore team, which keeps build costs within the ranges shown above without cutting testing or reconciliation. You can read more about our data engineering services or see results in our customer stories. 

Key Takeaways 

• SQL Server 2016 extended support ended on July 14, 2026. Packages still run, but security fixes now come only through paid, back-billed ESUs. 

• ESUs for 2016 are no longer free on Azure VMs. Moving databases to Azure SQL stops the charges. 

• Lift and shift to the Azure-SSIS Integration Runtime is the fastest low-risk exit for most estates, typically 6 to 12 weeks. 

• Fabric can run SSIS packages, but only in preview and without on-premises access, so use it for cloud-only pilots. 

• Rebuild in Data Factory or Fabric selectively, starting with the packages that are slow, fragile or expensive to maintain. 

• Choose a partner that inventories before quoting, decides per package, defines done with reconciled data, and prices the run as well as the build. 

Author By

Gaurav Lakhotia

Manager - Data Analytics & Engineering at Addend Analytics | gaurav.l@addendanalytics.com

Gaurav holds an MBA in Business Analytics. As a data geek and avid learner, he has earned accolades including Microsoft Certified Data Analyst, Microsoft Certified Azure Administrator, and active Power BI Community contributor. He is also a Microsoft Certified Trainer. With critical thinking and project delivery skills, he strives to achieve customer delight in Data Analytics projects. Gaurav loves travelling with friends when he is not busy working on data.