December 23, 2017 at 11:22 am
Comments posted to this topic are about the item Why Haven’t You Upgraded SQL Server?
Aunt Kathi Data Platform MVP
Author of Expert T-SQL Window Functions
Simple-Talk Editor
December 26, 2017 at 11:14 am
Part of the choice is 'if it ain't broke, don't fix it', keeping the old one as long as it's still in support and doing its job ... changing every 4 years is better than changing every 2.
The other reason is that SQL is at the bottom of the upgrade chain. We have lots of 3rd party apps (some far more expensive than SQL server) running on top. We can't upgrade SQL till all these are upgraded first and that involves getting approval and money from the different departments who own these applications, planning retraining users (at multiple locations) who will be using the updated applications (users seldom see any visible change from SQL updates, but some of these applications introduce radical changes over the time period). To minimize the pain, applications are updated a few per year, but SQL has to wait until they're all ready.
...
-- FORTRAN manual for Xerox Computers --
December 26, 2017 at 2:19 pm
One, the applications aren't certified by third party providers for the latest version of SQL Server and licensing requirements require running approved versions of SQL Server.
Two, cost of upgrade can't be justified at this time.
Three, customers balking at cost of upgrading or upgrading every two years
Four, can't justify the shiny new "buttons" (i.e. haven't had the opportunity to develop POC's)
Just a few reasons.
December 26, 2017 at 4:58 pm
SQL Server 2008 R2 running on Server 2008 R2 does everything we require and the operator interface is the best Microsoft ever produced. Every newer version of both is so different and obfuscated that I sometimes think their goal is to tempt us to switch to Linux and PosgreSQL. We just migrated (painfully) from Server 2003 and SQL 2000 which were both working perfectly.
December 26, 2017 at 6:09 pm
I can give you some very good reasons to NOT upgrade to the latest and greatest... look at 2012 and the problems they had there. They didn't actually fix some of the more serious RTM problems until SP3 ( and we actually held off on our upgrade until SP4) like that nasty problem if you rebuilt an index online with only a couple of "Goldilocks" conditions and it nicely corrupted your table if it was the Clustered Index. How about the lovely 2014 SP1 release that ate SSIS installations for lunch? How about the "wonderful" SQL Server 2005 RTM, which was horrible. It wasn't actually viable for me until they came out with SP1.
The cost for doing an upgrade from one version to another or two, especially when it comes to regression testing, is phenomenal, even when everything works perfectly but especially when SQL Server doesn't break your Dev or Testing Environments and then it crushes performance thanks to an "improvement" in the product when you finally upgrade prod, which is what happened when we upgraded to 2016 this last summer. Of course, we waited until well after SP1 had come out. 😉
Now... let's bring up deprecated and discontinued features that occur with each and every new release. Yeah... love that... especially when they take out well documented and well supported features in favor of "improvements" that actually turn out to have more problems than the originals. Heh... even MS code is still using (even in 2016) sys.sysindexes because THEY apparently don't have the time to fix their junk but they expect us to. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2017 at 2:47 am
Money is the main reason here. We're still running 2008 (not R2) on one environment, while 2012 on the other. I'm not going to lie when I say that I hate working with the 2008 server, mainly because the part of the company that use it historically had bad data management; wrong data types and thus bad data formatting. Thus I really miss simple things like TRY_CONVERT. As the application is a vendor database as well, when doing things like running aggregates I can't use quirky, as the indexes aren't in the right set up. Thus I often end up with Triangular Joins (puke). LEAD and LAG are also a massive loss.
We are looking at upgrading mind, however, we're going to move both environments onto one. This'll save us a lot, as instead of 2 sets of licences, we only need the 1. The 2008 server has little traffic it, but will be required indefinately so it makes sense to do a merge when it's not going to impose any performance problems hosting both front end application on the same server. We're most likely looking at 2017 as why wouldn't we (well the reasons Jeff gave). Earliest we'll likely have the server is going to be End of Q1 2018, however, more likely looking at Q2. Even if we got it early, by the time testing is done this means that we should be on about CU8 (so hopefully a lot of bugs will be ironed out).
There's a lot of new features that have come out since 2012, a lot with 2016 which should be quite interesting.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
December 27, 2017 at 6:42 am
Thom A - Wednesday, December 27, 2017 2:47 AMMoney is the main reason here. We're still running 2008 (not R2) on one environment, while 2012 on the other. I'm not going to lie when I say that I hate working with the 2008 server, mainly because the part of the company that use it historically had bad data management; wrong data types and thus bad data formatting. Thus I really miss simple things like TRY_CONVERT. As the application is a vendor database as well, when doing things like running aggregates I can't use quirky, as the indexes aren't in the right set up. Thus I often end up with Triangular Joins (puke). LEAD and LAG are also a massive loss.We are looking at upgrading mind, however, we're going to move both environments onto one. This'll save us a lot, as instead of 2 sets of licences, we only need the 1. The 2008 server has little traffic it, but will be required indefinately so it makes sense to do a merge when it's not going to impose any performance problems hosting both front end application on the same server. We're most likely looking at 2017 as why wouldn't we (well the reasons Jeff gave). Earliest we'll likely have the server is going to be End of Q1 2018, however, more likely looking at Q2. Even if we got it early, by the time testing is done this means that we should be on about CU8 (so hopefully a lot of bugs will be ironed out).
There's a lot of new features that have come out since 2012, a lot with 2016 which should be quite interesting.
It is about money and time here. If I were to go to the CIO with an Invoice to upgrade all of ours he would simply ask me what is the big benefit to upgrading? I would only be able to tell him to stay within support from Microsoft. The added features in 2012/14/16/17 are of no good to 90% of our installations and what we have in 2008R2 are simply running great as they are today. With reduced headcount in the apps area it is going to be a real struggle to upgrade all of these. I told my boss that we would need a full time DBA and 3-5 apps folks focused 100% if their time to keep up with Microsofts upgrades. AND even that we would never be caught up or stay current with the number of applications and DB servers we have.
December 27, 2017 at 4:50 pm
I first have to say to Jeff Moden; love the animation. Secondly, I and most all of the world agree with you.
MS needs to slow down releasing new product(s) as a source of income, they need to release better product(s) to increase their income.
I would like to see a 5 year release cycle with full support of product(s) for 10 such as:
Year 0: Version A Initial release
Year 1: Version A Service pack 1
Year 2: Version A Service pack 2 and Version A R2 that includes all service packs slipstreamed into the install. (Most people wait till year 2 to upgrade, after major bugs have been worked out)
Year 3: Version A Service pack 3
Year 4: Version B Initial release and Version A Service pack 4
Year 5: Version B Service pack 1 and Version A service pack 5
Etc, Etc, Etc....
If we spend most of our time upgrading and patching our servers we have little time to do the actual work we need to do...
Don't get me wrong I still want critical updates as they become available.
Well that is my 2 Cent rant, and I know most bean counters would agree that a ten year life cycle is within reason.
Thanks for Listening
December 28, 2017 at 5:54 am
Frank W Fulton Jr - Wednesday, December 27, 2017 4:50 PMI first have to say to Jeff Moden; love the animation. Secondly, I and most all of the world agree with you.
MS needs to slow down releasing new product(s) as a source of income, they need to release better product(s) to increase their income.
I would like to see a 5 year release cycle with full support of product(s) for 10 such as:
Year 0: Version A Initial release
Year 1: Version A Service pack 1
Year 2: Version A Service pack 2 and Version A R2 that includes all service packs slipstreamed into the install. (Most people wait till year 2 to upgrade, after major bugs have been worked out)
Year 3: Version A Service pack 3
Year 4: Version B Initial release and Version A Service pack 4
Year 5: Version B Service pack 1 and Version A service pack 5
Etc, Etc, Etc....
If we spend most of our time upgrading and patching our servers we have little time to do the actual work we need to do...
Don't get me wrong I still want critical updates as they become available.
Well that is my 2 Cent rant, and I know most bean counters would agree that a ten year life cycle is within reason.
Thanks for Listening
Well... Since Microsoft announced that they are no longer going to be releasing Service Packs at all for SQL Server 2017 and beyond they aren't going to be taking any of your advice.
December 28, 2017 at 6:46 am
Frank W Fulton Jr - Wednesday, December 27, 2017 4:50 PM...
If we spend most of our time upgrading and patching our servers we have little time to do the actual work we need to do...
Don't get me wrong I still want critical updates as they become available.
Well that is my 2 Cent rant, and I know most bean counters would agree that a ten year life cycle is within reason.
Thanks for Listening
I believe there is a disconnect between some SQL bloggers and SQL users. I see it in they way they are frequently trying out new (often pre production) versions, experimenting with new features, wiping and building a new instance at the drop of a hat etc.... in a way they are more like the game enthusiast crowd that can't wait to get the next version to try. It seems obvious that the next new thing is the one to use as soon as possible. This is not a bad thing, because they're the ones that help explain to us what is coming down the pike.
Most of us in the workplace don't have that luxury. We have neither the time, nor even the hardware resources to play around with new features, many of which we simply don't need at this moment. Upgrading a version is a huge freakin deal for us: cost, planning, purchasing resources, training, moving applications (which may also need upgrading) without disrupting business.
For us, upgrading SQL is not like loading the latest 'Call of Duty'. It's more like a root canal.
BUT SERIOUSLY-- thanks to the bloggers who have the time, so we can stay informed.
...
-- FORTRAN manual for Xerox Computers --
December 29, 2017 at 2:55 am
Kathi Kellenberger - Saturday, December 23, 2017 11:22 AMComments posted to this topic are about the item Why Haven’t You Upgraded SQL Server?
Just got SQL Server 2012 certified in 2015 in our org. (large, financial services company). Ultra conservative. rigorous testing of new releases. thousands of instances. huge cost and risk. Regulatory concerns. still trying to migrate the last of Windows 2003 and SQL 2005.
personally, I'd rather see Windows 10 upgrade first but again, with 100,000 instances .... huge testing and costs
Gerald Britton, Pluralsight courses
January 2, 2018 at 11:10 am
As others have already mentioned on this thread, cost and resources involved is the main stumbling block. Our main SQL install base is SQL 2008R2 and things work with it very well. Convincing "the man" to give a slice of the funds for the upgrade effort is fruitless as other upgrade efforts have trumped it. Also, due to licencing costs, all new development projects are looking at other relational database solutions. Even though the money is not there for upgrades, everyone is looking into other relational database solutions as a migration effort to see if the "free" licensing cost but more work/effort is a viable route.
January 2, 2018 at 2:05 pm
I would like it if we could just keep buying ongoing support for as long as the product works for us. This way, we get to keep using what works and Microsoft gets to make money. Eventually Microsoft might make something that works enough better than SQL Server 2008 R2 to make it worth the pain and cost of upgrade.
January 2, 2018 at 2:10 pm
davidhoeflein - Tuesday, January 2, 2018 2:05 PMI would like it if we could just keep buying ongoing support for as long as the product works for us. This way, we get to keep using what works and Microsoft gets to make money. Eventually Microsoft might make something that works enough better than SQL Server 2008 R2 to make it worth the pain and cost of upgrade.
Not going to happen. Eventually they will be supporting too many versions and their support folks will be way overwhelmed. They already support SQL 2008 2008R2 2012 2014 2016 and now 2017. Do you know of any software vendor that fully supports all versions they have ever made that are Enterprise systems forever?
January 2, 2018 at 4:36 pm
jay-h - Tuesday, December 26, 2017 11:14 AMPart of the choice is 'if it ain't broke, don't fix it', keeping the old one as long as it's still in support and doing its job ... changing every 4 years is better than changing every 2.The other reason is that SQL is at the bottom of the upgrade chain. We have lots of 3rd party apps (some far more expensive than SQL server) running on top. We can't upgrade SQL till all these are upgraded first and that involves getting approval and money from the different departments who own these applications, planning retraining users (at multiple locations) who will be using the updated applications (users seldom see any visible change from SQL updates, but some of these applications introduce radical changes over the time period). To minimize the pain, applications are updated a few per year, but SQL has to wait until they're all ready.
I know what you mean. I was really thrilled to retire that last 2000 server in 2010!
Aunt Kathi Data Platform MVP
Author of Expert T-SQL Window Functions
Simple-Talk Editor
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply