Brent Ozar had a post SQL Server 2016 and the Internet: Forced Updates, Phoning Home. "Issue #1" is ‘You probably shouldn’t run 2016 side-by-side with older versions.’ So, I checked the language in all the SQL Server install ULAs and they all say the same thing. I know some shared components will be upgraded to the newest version on a server upon install of said version and feature, but this has been around for many Glenn Berry guided instance installs. Is there something I’m missing?
It's important to read the reasons pertaining to this freighting revelation
this software will automatically update and replace certain files or features within those editions with files from this software. This feature cannot be switched off.
The way I read that, the concern is the potential for one version to overwrite at a later point in time the files shared and needed by another version. This is probably a result of DLL Hell. You can see this on the Wikipage,
Sometimes, the OS itself removed or replaced DLLs with older or obsolete versions. For example, Windows 2000 would install black-and-white printer DLLs on top of color-aware DLLs, if a black-and-white printer was installed after the color printer.
In light of that, the suggestion not to run two versions side-by-side makes perfect sense.
Future Safeing the Problem
One way to avoid DLL hell, is to upgrade and install Ubuntu which doesn't have such a problem. SQL Server 2017 will run on Ubuntu. This means that SQL Server 2018 will likely also run on Ubuntu. At such time, you'll be able to run both versions concurrently. So it's nice to see the Linux work paving the way forward. For Linux, SQL Server is currently self-contained in the
/opt directory, and packaged officially with
dpkg (which supports multiple versions).
You probably shouldn’t run 2016 side-by-side with older versions because:
... You may get updates whether you want them or not.
This does not say you will get updates that will bork your box. Essentially, any Enterprise installation of SQL Server should be carefully managed - you probably shouldn't allow automatic updates of SQL Server at all, and I'd be quite afraid of letting Windows Update install any updates automatically without some kind of pro-active management.
Test your planned deployment on a non-production box to see if the installation of SQL Server 2016 will cause problems for your environment. Then make an informed decision about how to go about applying updates. Decide for yourself if you can afford the risk of a side-by-side installation, versus the extra cost of running multiple SQL Server boxes.
full disclosure - I don't work for Brent Ozar; even if I'd like to.