Editorials, SQL Server

Updating/Upgrading your SQL Server Installation(s)

Long ago (no galaxy involved) it was common practice to wait until after SP1 or even SP2 arrived on the scene before updating to the newest version of SQL Server.  I’m curious how virtual machines, the ability to test more completely on developer editions and such, and general stability of SQL Server and the power of the engine have changed that for you?

Specifically, do you wait?  What is your process now for updating?  Do you use virtual machines for the deployment/testing and so-on, or do you build a new system from the ground up (or, something I still can’t bring myself to do, an in-place upgrade…)?

When you update, what types of things are you looking for in order to give the go-ahead?

  • Third-party software go-ahead – this used to be a bigger deal than now, where software produced by some vendors would lock in on specific versions of SQL Server.  Now it’s more likely that you’ll run into “SQL Server 2016 or greater” type qualifiers.  However, how is the impacted on an update, rather than an initial installation?  It seems to be easing up as well, but what do you see with your applications?
  • Third-party tool support – like the item above, tool support is a biggie.  In particular, if you’re using tools that help you monitor and administer your SQL Servers, having those go offline with a new version would certainly give pause to the process.  To me, this has become a bigger issue than the application support.
  • Human comfort and knowledge of the new release – in other words, expertise on your available team for supporting the new release of SQL Server that you’re moving to.  This is pretty important, and you’d think it would be a major milestone in the decision to move forward, but the reality that I’ve seen is quite different.  It seems like a basic knowledge of SQL Server at your current release, and then a passing knowledge of the new release is often enough.  I’ve asked several times why this is – the assumption appears to be that if feature usage is not changing in moving to the new release, that people will be able to support the new release, doing the old things, well enough.  I call this “bath by fire” when things happen that need attention, and certainly if there are tweaks and tuning to be done for the new release, they’re unlikely (at best) to be deployed during the update.
  • Data compatibility – this is a solid thing from release to release by and large.  Unless you’re putting in the “blue whifflesnargit” feature in moving to the new release – if it’s a sideways move in terms of data and storage, you’re usually ok.  There may be some data type issues, or some handling of stored procedures, but the assumption is that this isn’t a major target of deciding whether to move.

What am I missing?  What elements do you look for?

The choices and key elements will be driven too by your environment, whether it’s a hybrid, on-premises, cloud or what have you.  But I think the underlying options and things to be aware of at the SQL Server level are fairly consistent.  What say you?