This editorial was originally published on Apr 11, 2014. It is being re-published as Steve is out of town, with a few minor changes to dates and values.

It's 2017. SQL Server 2000 is 17 years old, but there are still quite of you managing instances. SQL Server 2005 is 12 years old, and I'm sure more of you still deal with that version. I know because I work for a software vendor and I'm constantly asked if our software will run against those two versions of SQL Server. Most of our software is no longer supported on those versions, as they're too far out of date.

For many of you, however, if you're managing a SQL Server 2000 instance, it might only be 10 or 12 years old. Your company might still have been installing SQL Server 2000 in the year 2005. The same is true for SQL Server 2005. I wouldn't be surprised to find companies still installing 2005 instances in 2008 or even 2009.

Companies don't care much about versions. They tend to mostly care about databases getting the job done, and sometimes, support. Many organizations don't see value in upgrading too often because of the overhead. I suspect many managers would prefer to get many years usage out of a platform before they change in order to minimize work that doesn't add value to their business.

The question this week asks you about the longevity of your database instances. Think about the average instance, or even the majority of your applications and how long they will remain on a particular version.

How many years will you run a platform before you upgrade it?

Years ago I heard someone at a large Fortune 100 company say their stated policy was to get 10 years of service out of a database server. At the time I thought that was a long time, but the more I think about it, the more I think that might be a minimum amount of time I'd want from a platform.

Let us know this week what you experience, and perhaps what you'd prefer.