About ten years ago my sister-in-law broke the screen on her mobile phone. She’d had an older iPhone and when she went to upgrade, none of the upgrade processes worked because her OS was so far behind that they couldn’t transfer her information smoothly. She had been avoiding OS updates because they interrupted her life, but that was now a problem because the world had marched so far beyond her version that there weren’t tools, or at least, no one was interested in trying to perform an upgrade across multiple OS versions (I think it was 3 or 5 versions).
I ran into this recently with someone else I knew, but not for a mobile phone. For TFS 2015. This customer had been working along with this older system and is finally ready to upgrade to Azure DevOps in the cloud. They wanted to know if they could somehow upgrade the TFS database and move all that data easily into the cloud. I said this wasn’t likely easy as this isn’t an upgrade, but an export and import of a lot of data. Microsoft offered a path, but it was multiple upgrades before an export/import, which was deemed too expensive. Right now, I’m not sure what they’re doing to do.
I know that many people keep old versions of SQL Server out there. Brent’s population report still shows some 2014 and older databases, and I’m sure there are plenty of 2008-era (or older) instances in use. Many of you continue to run older software because it works. That might especially be true on desktops, where we often install specific software for a task that might not change for years. I think there is plenty of value in older software that works well, though there might be security concerns.
However, for platforms or software where there is a regular upgrade path that you will need at some point, it pays to keep up, at least a bit. Maybe you don’t upgrade with every version, but you likely shouldn’t fall more than two versions behind. Vendors don’t want to maintain compatibility for too long and certainly don’t want to keep providing updates for new features. Even security updates get expensive to produce for old versions with complex test matrices needed to ensure the patches work and don’t break the application.
Software is a bit of a crazy business. In the analog world, if we own a product and it breaks or has an issue, often there are third parties who can repair it, or even create the necessary parts for the DIY market. Software is different, and the pace of change can be a bit overwhelming, expensive, and annoying. We can’t fix old software, heck, we’re not even allowed to fix old software. We can get into legal trouble if we try.
I don’t know if there is any good solution, but I certainly do know that if you manage software, you ought to be careful to keep abreast of how often the software upgrades and when support for previous versions is waning. Even if you don’t care about customer support calls, you likely care about upgrading to a newer version at some point, so make sure you know when they might drop support for upgrading from your version. Stepped upgrades work, but they can be expensive and time-consuming, and if there are issues, often vendors aren’t interested in why the upgrade didn’t work from your extremely-old version to a slightly-less-old version.
I still expect a database version to run for 10 years, but I know that support is tricky, and I also know that I better be ready to upgrade at that time.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Voice of the DBA 