September 3, 2015 at 9:17 am
I would love to upgrade from 2008 R2 to at least 2012. I've been granted that wish thus far, but have not made the transition yet.
Now with 2014, something that I'm super excited about from a BI platform perspective, I'm not ideally being blocked by anything else other than the IT team that is not as open to adapting new technologies that quickly.
So, even in my case with a large volume database primarily used for data & analytics and is easier to integrate to newer versions, there is still road blocks elsewhere in organizations that are also not as keen to adapting new technologies or updated to existing technologies that quickly until they have been proven.
September 3, 2015 at 9:19 am
If you have an old truck that still does the job, you don't buy a new one just because it is new. Upgrades are a cost benefit decision. Microsoft needs to understand that. Companies have lots of mini-applications. Sometimes hundreds, that do not justify upgrading. Most often, they will wait until it requires a re-write.
The more you are prepared, the less you need it.
September 3, 2015 at 9:24 am
We are running SQL 2008 Standard with a few thousand databases (mostly under 1 gb) on three Windows servers. I would be hard pressed to justify the licensing costs when most of our business logic resides in the application layer. I'd consider making some very dense servers (and maybe >1 instance) to not blow up my core costs.
I've always wished MS had a sizable discount for upgrading from one production SQL to another... a discount not call "Software Assurance".
September 3, 2015 at 9:35 am
Andrew..Peterson (9/3/2015)
If you have an old truck that still does the job, you don't buy a new one just because it is new. Upgrades are a cost benefit decision. Microsoft needs to understand that. Companies have lots of mini-applications. Sometimes hundreds, that do not justify upgrading. Most often, they will wait until it requires a re-write.
I wouldn't upgrade an old database to v2014 just for the new T-SQL smell, but there are some features like Clustered ColumnStore, SSD buffer pool extension, or Delayed Durability that can be a game changer without making significant changes to the underlying code base.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 3, 2015 at 10:03 am
george sibbald (9/3/2015)
Markus (9/3/2015)
We just upgraded our last few SQL2000 dbs to 2008R2 earlier this year and that was a very large project that took over 2 years to complete as it was a massive system with over 50 databases. We are actively moving things off of 2005 to 2012. This is a constant battle and will be even worse when 2008 goes out of extended support in 2019 because we have 60% of everything in 2008/2008R2. We are attempting to be more agressive with upgrades but the costs are quite high. With Microsoft coming out with SQL2014 23 months after SQL2012 it makes our job much more difficult. 2008R2 came out less than 2 years before 2012. We have well over 500 production databases and I just don't see how we can keep up with just upgrades.hear, hear
+2
September 3, 2015 at 10:06 am
In my experience it's not the license costs. When I get stuck with these boxes it's usually because they are attached to applications which aren't in active development anymore, which makes the whole migration process a painful, risky, expensive journey into the world of code archaeology. The license costs are usually pretty trivial compared to the development time.
September 3, 2015 at 10:43 am
I'd say that a business should upgrade at the latest time possible but while it is still a choice rather than a diktat. An upgrade should take place when you have time to think it through not when your back is to a wall.
You don't want to find that an old machine goes pop, you can't get parts and the software won't run on either the new OS and/or the new hardware. You'd pretty much want to know up front that a system cannot be upgraded, only replaced.
There is also the upgrade path to consider. Perhaps you can skip from version x to version x+3 but there is no path to version x+4. This is also has to factor into your thinking.
I have found that databases per se tend to use tiny subsets of the features the platform actually supports. I seen 3rd party apps that are certified for SQL2012 with schemas that would happily run on SQL7.
September 3, 2015 at 12:19 pm
Snark of the day:
Microsoft Licensing - promoting Open Source for twenty years.
September 3, 2015 at 1:21 pm
We're faced with this.
MS comes out with new version.
1-3 years till all our 3rd party applications are available for the new SQL
Aother couple years before all the allocations for all the (expensive) 3rd party apps are available--Not to mention the downtime, testing time, training time to move all the users from the 'current' 3rd party apps to the new one.
That's why we're a good 5 years behind the current MS offering.
We just moved a last major app off of 2005. The data analysis application is quite expensive in itself, has a complex series of data feeds grabbing data from across the organization that had to be re-tuned to the new version, training for the users (who in the meantime had to continue to use the proven existing version until everything was confirmed). As part of the process we discovered resource issues that we faced on the new version, all of which had to be resolved and proven.
And yet there is a 2nd, smaller, instance of that application for another division, which is a few months behind.
...
-- FORTRAN manual for Xerox Computers --
September 3, 2015 at 1:53 pm
I'm one of those people who still have a SQL 2005 server running. We're primarily on SQL 2008 and have plans to get the main 2005 instance migrated to 2012. Given how sensitive SharePoint is, however, the SharePoint instance isn't like to be going anywhere any time soon.
So much of the decision is based on licensing costs. We're one of those small to mid-sized companies, having less than 200 employees. We simply don't want to lay out piles of cash every couple of years just to be on the latest, greatest and buggiest version that's out there. A lot of where I'm coming from is the stability of the product. How long was SQL 2014 SP1 out before MS pulled it? I encountered the same thing with SQL 2004 SP4 and have heard of the same thing with SQL 2000 SP3. I value stability and reliability very highly and I just can't see it being worth the risk. Being without our database is both painful and expensive.
Would I like to play with the coolest new toys? Of course. Is it worth the risk? No.
I know I'm probably in the minority on it. Maybe I just have an overdeveloped sense of responsibility for the data I'm responsible for.
September 3, 2015 at 2:45 pm
SQL2005 is EOF April 2016. It's on Extended Support. So not accurate to say "... old, unsupported ..."
https://support.microsoft.com/en-us/lifecycle?c2=1044
David LaCourse
September 3, 2015 at 2:51 pm
Great timing for this article as MS is actively seeking input about this very topic.
September 3, 2015 at 2:53 pm
xinternet (9/3/2015)
SQL2005 is EOF April 2016. It's on Extended Support. So not accurate to say "... old, unsupported ..."
For a TB+ sized data warehouse there is more of a strong and compelling reason to upgrade than there is for an application database that hasn't seen an increase in daily usage since it's deployment back in 2005.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 3, 2015 at 4:23 pm
Sean Redmond (9/3/2015)
Firstly, if it ain't broke, don't fix it.Secondly, is this not a task for the sysadmins? They are responsible for security. If they are happy that the server is nicely isolated and protected within the network, then why upgrade? What do they say about it?
Very true. Why upgrade?
I'm if the opinion that Microsoft releases their products much too often. They should introduce a 5-year cycle with support over 2 cycles (10 years). The resulting product, though, should be so good, and so well tested that the decision to go with the new release should be what out American cousins refer to as a 'no brainer'. At the moment, we get a drip-feed of new releases every 2-3 years and rarely is a release so good that the decison to upgrade is clear. It was with SQL Server 2005. I thought that it was so with the In-Memory-OLTP in SQL Server 2014 until I tried it with our current DB.
I disagree. I like release cycles every 2 years. As long as MS knows I'm not likely to upgrade an instance for 8-10 years.
September 3, 2015 at 4:24 pm
samot-dwarf (9/3/2015)
I think Microsoft would be better served by letting customers license the scale they need
You mean similar as Oracle where you have to multiply your real cores by a factor definde by the exact type of the core?
Maybe. Perhaps not that complicated, but maybe unlimited RAM and I get to license 1, 2, 4, 56, 192 cores as needed. Let me add cores and a license when I need it.
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply