我们运行多个 SSIS 包，这些包多年来都是使用 BIDS 和 Visual Studio 2010 构建的。
如果我使用 VS2010 打开旧的 BIDS 解决方案并进行转换，会发生什么？那么它会变得无法使用 BIDS 吗？是否存在腐败或类似负面影响的可能性？我相当确定其中一些旧解决方案甚至无法在 VS2017 中打开。
有了更新的改进的 Visual Studio 版本，是否有任何理由不升级所有这些软件包并让每个人都使用 VS2017 或类似版本？
目前需要多个版本的 VS，但并不总是安装这些版本，然后由于各种安全原因，安装受到限制等等。升级所有内容并让每个人都运行相同版本的软件似乎更高效且更少浪费时间。
这些包当前在 SQL Server 2012 上运行。
对于 SSIS，建议您使用与您的 SQL Server 版本配合使用的 Visual Studio/Bids 版本。
对于 SQL Server 2012，您应该使用 Visual Studio 2010。
如果我使用 VS2010 打开旧的 BIDS 解决方案并进行转换，会发生什么？那么它会变得无法使用 BIDS 吗？是否有可能出现腐败或类似的负面影响？
是的，它会升级到你打开它的版本格式（即在BIDS中使用SSDT’12开发的打开包，即VS2010 shell，并且会自动升级）。有多种方法可以降级它，但这是一个疯狂的手动 XML 操作过程。 话虽这么说，你的源代码控制在哪里，伙计！
*随着更新的改进的 Visual Studio 版本的出现，是否有任何理由不升级所有这些软件包并让每个人都使用 VS2017 或类似版本？
我用的是VS2015，转换过程并不好玩；有趣的事实：当您在 SSDT 或 BIDS 所在的同一台计算机上安装 VS2015 时，某些较低版本的注册表项会被最高版本的注册表项覆盖，从而导致某些配置 SSIS 任务（即 OLEDB 目标）在设计器中无法读取！
有一些，至少我经历过：
数据流源或目标的连接提供程序可能不受支持（即
从包转换为项目部署可能会非常令人头疼。
确保编辑 SSIS 项目的每个人都具有相同的版本和补丁对于大型组织来说是一场噩梦。
但是……如果可以的话，你应该是最新最好的。一定要更新那些在 BIDS 中开发的 DTSX 包！最后，如果您还没有设置集成服务目录，那就去做吧！伐木和安全方面蕴含着数不尽的财富。