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.

  • It's somewhat unclear what you're asking. Which file paths / folders are you talking about? In what way are you considering eliminating old version components? Jan 25, 2017 at 14:47

3 Answers 3


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.

  • In my Company there is a security team and they ask me to remove the older components, but I am a bit afraid to remove the components; my concern is breaking the SQL Server installation. Jan 25, 2017 at 20:42
  • Which components specifically do they deem a security risk? Have they explained why? Jan 25, 2017 at 20:43
  • Because, they are old components and probably we won't upgrade they anymore, we will focus on the sql server 2016 upgrades. Jan 25, 2017 at 21:09
  • Some examples: integration services , sql server management objects,sql server setup, sql server upgrade advisor, clr types for sql server etc Jan 25, 2017 at 21:11
  • I still don't follow how "old" == "security risk" - do they cite any documented cases of security breaches involving SMO, for example? Jan 25, 2017 at 21:17

After an upgrade from SQL Server 2014 to SQL Server 2016 the old Version stays partly intact and operational. Only the ..\MSSQL... path has been prepare for downgrading. The old Integration Services, parts of the old Analysis Services, localdb, DTS and the like are still there and fully operational.

E.g.: The old localdb can be used to run all databases with C-leven <= 120. So saying that this is not a security risk and those components can sit for ever unattended is not aceptable.


I agree that cleaning up components can be risky, so a test upgrade environment can be important to catch potential outages as you remove them. We've done the disable, and wait strategy from time to time as well.

If you are looking for security evidence, check the release notes for components like SQL Server Management Studio to see the security risks of leaving the old versions on the server.

Have your superiors review and sign off on the risks (in writing) if they choose not to worry about a clean up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.