SSIS project/solution conversion between Visual Studio editions

Question

We have multiple SSIS packages we run which have been built using BIDS and Visual Studio 2010 over the years.

If I open an older BIDS solution using VS2010 and convert it, what happens? Will it then become unusable with BIDS? Is there any chance of corruption or similar negative impact? I'm fairly certain some of these older solutions won't even open in VS2017.

With newer improved Visual Studio versions, is there any reason NOT to upgrade all these packages and have everyone use VS2017 or similar onward?

At the moment multiple versions of VS are required which aren't always installed then installation is restricted for various security reasons and on and on. Upgrading everything and having everyone run the same version of the software seems much more efficient and less time-wasting.

The packages currently run on SQL Server 2012.

Answer 1

With SSIS, it is recommended that you use the version of Visual Studio/Bids that was made to work with your version of SQL Server.

For SQL Server 2012, you should use Visual Studio 2010.

Answer 2

If I open an older BIDS solution using VS2010 and convert it, what happens? Will it then become unusable with BIDS? Is there any chance of corruption or similar negative impact?

Yes, it will be upgrade to the version format of whatever you use to open it (i.e. open package developed in BIDS with SSDT ’12, which is VS2010 shell, and it’s automatically upgrade). There are ways to downgrade it, but it’s a crazy manual XML manipulation process. That being said, where’s your source control, man!

*With newer improved Visual Studio versions, is there any reason NOT to upgrade all these packages and have everyone use VS2017 or similar onward?

I use VS2015, and the conversion process was not fun; interesting fact: when you install VS2015 on the same machine as SSDT or BIDS some of the lower versions registry entries get overwritten by the highest version’s, making some of your configure SSIS tasks(i.e. OLEDB destinations) unreadable in the designer!

There are a couple, at least that I’ve experienced:

1. Connection providers for data flow sources or destinations might not be supported (i.e. <SQLNCLI11.1) for older components.

2. Converting from package to project deployment can be a massive headache.

3. Ensuring everyone editing the SSIS projects has the same version and patch is a nightmare in large organizations.

But… you should be on the latest and greatest if you can. Definitely update those DTSX packages developed in BIDS! Lastly, if you haven’t set up Integration Services Catalog, then do it! There are untold riches to be found for logging and security.