Sql-server – Removing older components after upgrading

sql serversql server 2014sql-server-2016upgrade

I will upgrade to SQL Server 2016 from a SQL Server 2014 in my company.

This server has had many versions of SQL Server (2008, 2012, etc).

What should we do with the old version's components? When a version is upgraded, older components are left behind.

Best Answer

You could uninstall them, but why? They're just sitting their idle not hurting anything, but you could get over-zealous and remove something you didn't realize you need.

I'd be more concerned about the underlying OS - has it been upgraded along the way too? We just had a scenario where we couldn't upgrade to 2016 because the OS was no longer supported by SQL Server.

IMHO: Just leave those old components be.

If some pointy-haired security person automatically thinks that "old" == "insecure" without any evidence, then there are probably some components you can remove without causing problems, and some that involve more risk.

Safe (and I'll list those alphabetically):

  • old versions of upgrade advisor - current one, even, after you've upgraded.

Not slam dunks:

  • setup support files (until everything involving that version has been cleanly removed)
  • older management objects (on a system I have with 2014, 2016, and v.Next, I only have 2014 management objects listed)
  • CLR types for older versions (I would ensure that all of your databases are in at least that version+1 compatibility level and that you don't have custom CLR objects that rely on that version)
  • Integration Services (how do you know these aren't being used?)

For things that are services (like SSIS), a less risky way to do it would be to turn the services off for some period of time (a full business cycle is ideal). If nobody complains that the service isn't up throughout that time, than it is possibly safe to take the next step. As a bonus, your security folks should be happy in the meantime because if the service isn't running, it isn't a security risk.

At some point it makes more sense to just back up all your databases, pave a new OS, install a brand new instance fresh, and blow the old system away. This Chicken Little approach to "cleanup" for imaginary security risks just doesn't sound like a good time to me, and in fact seems to involve more potential risk than any security concerns they could possibly have.

Related Question