SQL Server 2016 End of Support
The server has a deadline. Your packages do not.
SQL Server 2016 left extended support on 14 July 2026, per Microsoft's published lifecycle dates. After that date the options are Extended Security Updates, which are paid and time-limited, or moving.
Almost every one of those instances carries an SSIS estate and a set of SQL Agent jobs with it. So the server decision immediately becomes an ETL decision — and the two get conflated, usually in the direction of a much larger project than anyone needed.
What the date actually forces
It forces the instance to move. To a supported SQL Server version, to SQL Managed Instance, or onto Extended Security Updates while you decide.
It does not force an ETL rewrite. SSIS still ships inside SQL Server. Microsoft has not announced an end date for SSIS itself, and the Azure-SSIS integration runtime has been generally available for years. Your packages have a destination that does not involve rebuilding them.
This distinction is the whole point of this page. A server deadline is being used across the market as the argument for a platform rewrite, and it is not an argument for one.
The three routes, and who each suits
Move the instance, keep the packages. Upgrade to a supported SQL Server version, or move to SQL Managed Instance with the SSISDB catalog and an Azure-SSIS integration runtime. The packages run as they do today. This is the shortest path and, for most estates, the right one.
Move the instance, rewrite the packages that earn it. Everything above, plus a rebuild of the specific loads that fail often, block the batch window, or change every quarter — as Data Factory or Microsoft Fabric pipelines. The rest stay on SSIS.
Pay for Extended Security Updates and decide next year. A legitimate choice, and sometimes the correct one if a bigger platform decision is genuinely in flight. It is a cost with an end date attached, so it should be a decision rather than a drift.
What to work out before choosing
- What is actually on the instance. How many packages, how many SQL Agent jobs, and which of them still have consumers. In most estates a meaningful share of the load is feeding tables nothing has read in a year.
- What blocks a move. Third-party or custom components, 32-bit-only providers such as the Access Database Engine driver behind an Excel source, on-premises sources with no network path from the destination, and packages encrypted with a departed user's key.
- Whether the SSISDB catalog can travel. A backup-and-restore of SSISDB keeps your environments, parameter values and execution history — but only if the catalog's database master key password can still be found. If it cannot, you are redeploying the projects and rebuilding the environments by hand. This one is worth checking today; it changes the plan.
- Which jobs overlap. SQL Agent will not start a job that is already running. Data Factory schedule triggers will. Find the jobs whose run time exceeds their interval before, not after, the cutover.
Those four answers are the first week of an estate assessment, and they are the difference between a plan and an estimate.
If the date has already passed
It has, and that is a common position rather than an emergency. Unsupported is a risk posture, not an outage: the instance keeps running. What changes is that there are no security updates without paying for them, and the decision no longer has a comfortable amount of runway.
The useful next step is the inventory, because every route above starts with it and it is the part you can begin without committing to anything.
Tell us what you are running — roughly how many packages, which SQL Server version, and what is prompting the move.