I have a dev environment with SQL Server 2008 R2 and SSIS (10.0) installed.
I have a number of SSIS packages built with SQL Server 2008 R2 BIDS and these have been deployed to a Prod server running SQL Server 2017 and SSIS (14.0). The legacy SSIS packages run fine on Prod's SQL Server 2017.
I recently installed SQL Server 2017 & SSIS onto my Dev environment. The plan being to upgrade the SSIS packages in the future. Therefore in my dev environment, I have SQL Server 2008 R2 with SSIS 10.0 and also SQL Server 2017 with SSIS 14.0. Everything seems to co-exist fine.
The reason for my question is that in my dev environment, when I run the 2008 R2 SSIS packages from anywhere (BIDS / SQL Server 2008 R2 / SQL Server 2017) it requires the 'SQL Server Integration Services 10.0' Windows service to be running. If I run the same package on the Prod server which only has SQL Server 2017 and SSIS 14.0 installed it requires the 'SQL Server Integration Services 14.0' Windows service to be running.
Why in Dev is it falling back to use the older SSIS 10.0 Windows service, even when launched from SQL Server 2017? The package is deployed in an identical way onto the Dev SQL Server 2017 and prod SQL Server 2017, yet the Dev install uses SSIS 10.0 and Prod uses 14.0. Is this to be expected? I don't have a huge issue with this, but with Dev using a different SSIS runtime to Prod, I am not guaranteeing a similar SSIS environment for testing.
Is this behaviour to be expected?
Many thanks in advance.