If you're reading this, chances are your organisation runs SSIS packages built 5, 10, or even 15 years ago. And you're asking the question every CIO eventually asks: do we continue, do we migrate, or is there a middle ground?
The short answer: it depends. The long answer fills the rest of this article.
Status overview: SSIS in 2026
SSIS is not end-of-life in the strict sense. It is still shipped with SQL Server 2022 and will continue to be as long as SQL Server exists. Microsoft has announced no deprecation. You can even run SSIS packages in Azure via the Azure-SSIS Integration Runtime in ADF.
But “not end-of-life” does not mean “healthy.” The real problem is elsewhere: SSIS is no longer receiving significant functional investment from Microsoft. Innovation is going to Fabric, Dataflow Gen2, Synapse Pipelines.
And above all: the job market is drying up. SSIS developers are increasingly rare because new data professionals are training on Python, DBT, Spark — not on a graphical tool from 2005. Recruiting an SSIS expert in 2026 is like recruiting a COBOL developer in 2010.
The three scenarios
Scenario 1: Maintain as-is
If your SSIS environment is stable, well-documented, with manageable technical debt (score below 30), and you still have internal skills or a reliable maintenance provider, there is no urgency to migrate. SSIS will continue to work for years.
This scenario is viable in the short and medium term (3-5 years). The long-term risk is increasing dependency on scarce skills and a growing gap with modern practices (CI/CD, automated testing, documentation as code).
Indicators for this scenario: fewer than 200 packages, low technical debt, competent in-house team, no performance issues, no budget pressure on infrastructure.
Scenario 2: Full cloud migration
This is the scenario cloud providers push — and for good reason, it’s in their commercial interest. A full migration to Snowflake/DBT or Fabric makes sense when the SSIS estate is large (500+ packages), technical debt is high, and the organisation has already invested in cloud infrastructure.
The classic trap of this scenario is underestimating the validation effort. Converting the code, even automatically, is 50-60% of the work. The remaining 40-50% is validating that the new system produces exactly the same results as the old one.
The lift-and-shift trap: reproducing SSIS logic identically in the cloud means creating cloud code that thinks like on-premise. SSIS packages execute sequentially. Snowflake and Fabric are designed for parallelisation. If you don’t re-architect, you’re paying cloud prices for on-premise performance.
Scenario 3: The hybrid approach
This is the scenario we recommend most often, and the one cloud integrators will never propose — because it generates less revenue than a full migration.
The principle: migrate components with high technical debt or high business value (critical flows, performance issues), while keeping components that work well and for which migration brings no measurable gain.
Specifically, the estate audit classifies each package into one of four categories:
Migrate first: critical packages with high technical debt or performance issues. They will benefit most from cloud re-architecture.
Migrate later: functional packages that would benefit from modernisation. No immediate risk, but a worthwhile investment in medium term.
Keep: simple, stable, well-documented packages. The migration cost exceeds the gain. They’ll stay on SSIS as long as SQL Server is supported.
Decommission: obsolete packages — fed by deactivated sources, producing tables nobody queries. This is often 15-25% of the estate. Removing them costs nothing and immediately reduces the maintenance surface.
debt
debt
How to decide: the decision matrix
Rather than choosing by intuition, we use a two-axis matrix: the component’s business value (is it critical to operations?) and its level of technical debt (is it fragile, slow, poorly documented?).
A component with high business value and high technical debt is an obvious candidate for priority migration — it is an active operational risk. A low-value component with low debt can stay in maintenance mode indefinitely.
This matrix doesn’t come from a PowerPoint — it’s fed by automated audit data. The technical debt score is calculated objectively by the scanner. Business value is validated with client teams in a qualification workshop.
The most common mistakes
Having supported dozens of projects like this, we see three recurring mistakes.
The first is deciding without auditing. Many organisations decide to migrate (or not) based on impressions rather than data. “We have a lot of packages” means nothing until you know how many are active, how many are obsolete, and how many are critical.
The second is migrating without re-architecting. Reproducing SSIS logic identically in DBT means keeping legacy problems with cloud costs. If an SSIS package makes 15 sequential calls to stored procedures to build a single table, the DBT model should not do the same.
The third is neglecting the decommissioning phase. Obsolete packages don’t harm anyone as long as they run without errors. But they consume compute, generate phantom alerts, and cloud understanding of the system. Removing them is always the right first step.
Our recommendation
Start with an audit. Not a 6-week audit by a firm that sends 4 junior consultants. An automated audit that scans your source code in 48 hours and gives you an objective view of your estate: what’s active, what’s obsolete, what’s critical.
From there, the decision is made with data, not convictions. And in most cases, the answer is neither “migrate everything” nor “touch nothing” — it’s a structured plan that treats each component according to its risk and value profile.
Next step: discover our audit methodology or request a free audit of your SSIS estate.