I recently had a request to build a handful of servers that would run a piece of critical infrastructure in our environment. The requester wanted SQL 2008 R2. I laughed. The earliest version I’m willing to deploy in 2015 is SQL 2012. And if the application supported SQL 2014, then that’s what we’re going to deploy. The sun is setting pretty quickly on SQL 2008 R2, and the risk of running on an old version is just too great.

The requester was my old boss, and I absolutely adore the woman. She’s also very conservative with DBMS platforms and doesn’t always trust the latest versions. Her aversion to risk with newer versions is impressive.

When it comes to running database serves for infrastructure, I will always advocate for running the most recent supported, stable version. I learned that trick very early on in my career.

In 1996, I was working for a company that provided IT services to large companies. I was onsite with a client that operated a nuclear facility. Anything that came out of a hot area had to be buried  in several feet of concrete, and burying computers got to be incredibly expensive. They had a rule that everything that went into their hot areas had to be state of the art and would stay there until it was absolutely unsupportable. In fact, when they were putting new desktops in the hot area, they were literally hours off the assembly line at IBM. That’s how seriously they took this.

Today, I work for a financial services company, and the analogy isn’t too much of a stretch. We only upgrade when we have to. After all, it’s not broken, why incur the cost and risk of upgrading? Right now, we’re doing a risk analysis of our Windows 2003 servers that will soon come out of support. We still have servers running SQL 2005. That technology is ten years old! The good news is that I’ve been pretty diligent at getting rid of our SQL 2005 servers, so the number of boxes running Windows 2003 is pretty small.

For environments that we host for clients, we upgrade their DBMS when we upgrade their version of our application. For most clients, that model works well because they upgrade to the latest version of our application every few years. But there are a handful of clients that will hang onto an old version of software until we force them to upgrade or they finally understand that a critical piece of their application landscape is no longer supportable.

So when the request came in for a bunch of SQL 2008 R2 servers, I dug in my heels. When we’re supporting SQL 2022. I don’t want to still be babysitting this little group of SQL 2008 R2 servers. This particular application doesn’t yet SQL 2014, so we’ve deployed SQL 2012. I’m okay with that.