MicrosoftMicrosoft
MicrosoftJensDamm Our recommendation would be that the DBA team file an exception for the version of SSMS that's needed to support the organization's legacy SSIS connections. We have no plans to change the support policy for SSMS. SSIS introduced use of the SSIS catalog (SSISDB) in SQL Server 2012, and I recognize that legacy integrations can time to modernize, but that's a worthwhile investment to make before an organization may be forced to do so.
erinstellato We would need to wait or the vendor (a Microsoft partner) to update their software to support SSISDB (or migrate away from SSIS)...
Just to be sure, because the support policy is hard to read/understand or is conflicting with the information from that blog entry:
There will be no security updates for earlier SSMS versions (before v21) anymore?
And a feature which is existing in the supported SQL Server version is basically not fully working anymore because the software to maintain it, is not supported anymore?
MicrosoftJensDamm I don't know what "a feature which is existing in the supported SQL Server version is basically not fully working anymore because the software to maintain it, is not supported anymore" means. Do you have an example? In terms of the version of SSMS that is required for legacy SSIS services, that is documented (link I shared previously). If there is a critical/high severity security issue with a previous release of SSMS, and customers require that version to access legacy SSIS services, then we would be required to update that release.
