September 18, 2014 at 8:18 pm
Comments posted to this topic are about the item No Compelling Reason
September 18, 2014 at 9:43 pm
Some of the main reasons we have not upgraded is due to the lack of knowledge on benefits and costs. Working for a smaller company, it's a little harder for us to upgrade so quickly.
For me, coming from the open source world, I personally hate limitations due to costs. I would rather use MySQL or any of the various NoSQL solutions out there. But, on the other hand, having had more time with SQL Server, I am following in love with the platform and would love to explore 2014.
But then again, I think more people need to make better arguments on why an upgrade should happen, including arguments that I should find myself.
September 18, 2014 at 9:54 pm
For my company it is cost. Sinking 7k a core for enterprise means its a long term expense that will be there for 4-5 years at least. We are still running some 2005 boxes because the customer does not want to upgrade. (Thankfully the last 2000 box was just decommissioned office space style) Slowly but surely every thing is getting upgraded but most of our upgrades are going to 2012 since 2014 is still so new (some clients wont move till the first service pack).
For performance Issues see how we like them posted here: How to Post Performance Problems - Gail Shaw[/url]
Need to Split some strings? Jeff Moden's DelimitedSplit8K[/url]
Jeff Moden's Cross tab and Pivots Part 1[/url]
Jeff Moden's Cross tab and Pivots Part 2[/url]
September 18, 2014 at 10:46 pm
As far as I've seen, the retention issues are not the platform itself but the dependants. The technical part of the SQL Server upgrade is one of the smoothest there is, upgrading everything else is a pain in the B, even more so if the version gap is greater than two versions.
😎
September 18, 2014 at 11:43 pm
The new licensing model and cost is the biggest issues.
Anton
September 19, 2014 at 1:42 am
What are the reasons that prevent you from migrating those 2005/2008/2012 instances to 2014?
Mainly two things:
1. The licencing mess
2. Product segmentation
To me there seems not much to gain by upgrading a standard version to a newer standard version as nearly all new things and improvements are enterprise edition only. And to my knowledge no design or other fixes of importance have been made either.
The only things I would like to use now, but are not worth an upgrade over:
1. More complete over clause
2. Sequences (interesting, but not sure it always bests identity columns)
Overall, there isn't much there to make a good sale to the majority of existing customers (most will have standard or web editions, i am pretty sure of that).
September 19, 2014 at 1:45 am
I work for a large Theme park operator and I have 250 SQL Servers in the estate. I am the only DBA.
We still have a couple of legacy 2000 boxes, many many 2005, many 2008 many 2008 R2, some 2012 and zero 2014.
I'm a great believer in "If it ain't broke, don't fix it" and so if a system is running acceptably for it's purpose, I'll leave it alone.
New systems are going in on 2012 and I'll get a pilot 2014 in test at some point after SP1.
Upgrading is done only when there is a pressing reason to do so. We are adding a new attraction in London soon so the servers that service the existing properties are being consolidated onto a new box bought for the new attraction.
The licensing model now in play doesn't make economic sense for us to upgrade our 2005 servers.
DBA (Dogsbody with Bad Attitude)
September 19, 2014 at 3:25 am
I recently upgraded an old application from SQL 2000 to 2008 R2. Simple, you may think, and indeed apart from a few old school joins in procs (*= type stuff) and a little date work and other minor issues it was all good.
However the way SSRS integration had been implemented on the project meant that it took weeks of work to find a secure way forward to migrate reports upwards. That's the kind of thing that puts you off.
You can say it's a bad implementation etc but the fact remains. As there were no tests set up it being pretty old, it was a case of full testing to find any issues. That takes a few weeks too.
September 19, 2014 at 3:38 am
All the reasons stated above ring true to my ears!
I'm sitting in a small company as well, and we have planned to upgrade from 2005 to 2012 (not 2014!) for some time.
Mainly because the SQL Server 2005 installation is running on a Windows Server 2003 machine which is giving us headaches! So if we are going to spend valuable time "upgrading", we think we might as well upgrade both. Yet, we haven't got around to actually do it for 1½ years...
I have spend some time analyzing the various cons and pros between the SQL Server versions. Had we been running a 2008 R2, I would have left it alone!
I have picked the 2012 version because it has proven itself and offers some very nice features (e.g. native support for intellisense and improved windowing functions) which will save time when we the coming years need to review and recode a lot of our legacy scripts.
I have yet to see the potential in SQL Server 2014, because the performance gain to be had there isn't an issue for our use. Second, we are not staffed to run "front-edge technology" where things can go wrong any day (or night) and the communities isn't teeming with good advices about how to fix. However, as time go by (without us upgrading) the choice slowly tips in favor of 2014.
But then again, I see advises against upgrading too many steps at a time, and going from 2005 to 2014 in one go may be too risky, if we can't see the reward...
September 19, 2014 at 4:02 am
As with others, costs and licensing. Mostly costs, when the only 'benefits' over our current working system are things that would be great to play with technically, but which we don't actually need to deliver the solution.
Add to that the fact that we are a very small company serving some very large high street, helpline and charity organisations who demand 24/7 coverage - finding maintenance windows is nigh-on impossible and the risks of an upgrade that we can't test and validate are unacceptable. Yes, we just have a production platform and nothing else ... :crying:
September 19, 2014 at 4:42 am
We're still concentrating on getting everything up to 2008 and consolidating servers onto windows 2008R2 with plenty of virtualisation.
I don't think 2014 has had UK government security sign off yet but we aren't even going to 2012 at present because of:
1. Lack of manpower to work on upgrades to all the 2008 systems
2. Business being sold so waiting for new owners to determine policy - SQL or Oracle or what? Which version?
3. Licensing costs of new model especially on virtual servers
4. Other tasks having priority for the team.
September 19, 2014 at 5:54 am
The two biggest issues that I have repeatedly come across are:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 19, 2014 at 6:10 am
1) Cost, neither us or our clients has the extra dollars to pay for the increased licensing.
2) There's nothing in the new features that's compelling enough to upgrade.
3) If it's not broke, don't fix it. Applications would have to be recertified.
4) There's a lot of things that need improvement, (SSIS, SSRS) that Microsoft has ignored to come out with features we don't need.
5) OSS RBMS and tools are gaining acceptance in the market. When you build a web application, no one cares what technology you use as long as it works and is secure.
September 19, 2014 at 6:15 am
In two words - regression testing.
It is a costly endeavor, even for those systems that aren't considered "regulated".
September 19, 2014 at 6:17 am
The system is already working. Best case scenario after upgrading is that the system still works. There is no motivation to spend the time and money to get what we already have. And if it's like all other MS products, the new one will be more bloated and slower, so new hardware would likely be required.
Things would be different if it were a new installation. Then we would start with the latest version.
Viewing 15 posts - 1 through 15 (of 69 total)
You must be logged in to reply to this topic. Login to reply