September 19, 2014 at 6:21 am
erb2000 (9/19/2014)
Best case scenario after upgrading is that the system still works.
Perfectly said.
September 19, 2014 at 6:39 am
Cost, cost, cost. The existing licensing fees are already enough that my team is under pressure to (and has started to) move to a free, open source SQL platform instead of M$ SQL Server 2008. There is no way the suits upstairs would ever pay for M$'s new scheme.
September 19, 2014 at 6:42 am
The number 1 roadblock to migrations is always developer and client resources. Someone has to modify/test the application in the new environment, and that is always a tough sell, regardless of the technical reasons and advantages to doing it.
September 19, 2014 at 6:44 am
We mainly rely on vendors to tell us when it's time to move to a later version. For custom in-house stuff, we are on SQL Server 2008 R2 and see no compelling reason to upgrade. There are several databases on it and each would have to be tested. It is time consuming with no real apparent benefit; at least to the end user.
Tom
September 19, 2014 at 6:54 am
Every place I've ever worked has an irrational aversion to in-place upgrades. So the alternative is to prop up a new server / instance and migrate databases and redirect connections. This is a much more labor, resource and logistically intensive process companies never seem to have the time to do.
It would be so much easier if they could trust the upgrade process. I personally don't understand the fear of in-place upgrades as I assume the in-place upgrade process has been thoroughly tested prior to RTM and certainly after SP1 has been released.
Does anyone do in-place upgrades to production servers? After 20 years, I have yet to see it.
September 19, 2014 at 7:15 am
Primarily it's a cost factor for us. 2008 R2 fills all our needs, so we'd see very little ROI with an upgrade to a newer version.
Be still, and know that I am God - Psalm 46:10
September 19, 2014 at 7:23 am
jhadden (9/19/2014)
Every place I've ever worked has an irrational aversion to in-place upgrades. So the alternative is to prop up a new server / instance and migrate databases and redirect connections. This is a much more labor, resource and logistically intensive process companies never seem to have the time to do.It would be so much easier if they could trust the upgrade process. I personally don't understand the fear of in-place upgrades as I assume the in-place upgrade process has been thoroughly tested prior to RTM and certainly after SP1 has been released.
Does anyone do in-place upgrades to production servers? After 20 years, I have yet to see it.
I can only imagine this occurring after an in-place upgrade was tested on a restored backup of production and supported by complete rollback processes as well as a decent time frame.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 19, 2014 at 8:02 am
I believe that how Microsoft numbers their version releases should be carefully considered by the marketing department from several different angles. For example, SQL Server 2014 generates a lot of excitement within the community, because it appears to be a major release over 2012, but is it really that big of a leap? Also, it actually be problematic when it comes to broad based adoption, because it seems like more of a migration effort than say going from 2008 => 2008 R2. Many, perhaps most, organizations would perceive it as more of a risk, especially since SQL Server 2012 was released only a couple of years ago and is working for them.
Also, for those of us studying for 2012 certification exams, or authors writing technical books, it would be great if the next major release (ie: 2012 -> 2014) didn't come out only a year after the exams are publicly released for the prior release. It makes us feel old hat before the ink is even dry.
All other things the same (features, release date, etc.), how many folks here think that SQL Server 2012 R2 would have just been a better name for marketing purposes?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 19, 2014 at 8:14 am
It easy to explain the lack of migration, the licensing mess. The deprecation of SQL Workgroup Edition is a major concern to our business. We have customers who don't need to power of SQL Standard and have maybe 5 to 10 users tops using our software solution. Once they hit the 10 GB limit on the size of a single database, the cost rockets. Think about it, We now have to license cores, not processors. As a VAR, we can't be bothered with tracking user CALs for our customers. That isn't the business we're in. We sell hardware and software solutions and want to purchase it once, install it and not have to deal with adding CALs as the customer's needs change. Microsoft, bring back SQL Workgroup, bring back the VAR program with preferential license fees and upgrading our customers to the latest version of SQL Server becomes attractive again.
September 19, 2014 at 8:15 am
We are a city government; most instances are on 2008R2, a few 2005. I agree with what others have stated. Basically, the benefits of an upgrade don't outweigh the costs ($, employee time, hassle, downtime, etc.)
September 19, 2014 at 8:48 am
In my case, we're hamstrung by our backup software. I fought the battle that the DBA's should be doing the database backups to disk and the Infrastructure group then pick those backups up. Lost that one....mainly because they've never done it that way before.
They insist on doing backups with their backup software via an agent installed on each SQL box. Unfortunately, there is no support for SQL 2014. Getting very vague answers as to when that support will be there.
September 19, 2014 at 9:00 am
We just got the last 4 databases that support our stores off of a SQL2000 Cluster to SQL2008R2 Cluster in May. That was a 2 year long project that had us migrate or replace 52 databases that support all of that. We still have two very small dept dbs on SQL2000 that will be sunsetted by the end of the year. We also have about 50 DBs still on SQL2005 and I have begun focusing on these now. The rest of our 400+ dbs are on SQL2008 and 2008R2 and one on SQL2012. I am going to put in the budget a SQL2012 license so we can migrate more things out of 2005 to 2012. 2014 is just too new without the first service pack released yet if you ask me.
Its all about when the vendor certifies the new versions, when we have time to upgrade to it and the $$ associated with it. For lower end systems I see no benefit of SQL2012 or 2014 so it is very difficult for me to go to my boss and say I need to replace 40 SQL Server licenses and not have a good justification to do so. Not to mention the fact that as fast as they release new versions of SQL Server I would never get everything upgraded before the next version is released. I am quite disappointed that Microsoft appears to be focusing on new versions versus issuing Service Packs for the versions they already have. Lately some of their CUs have had some problems in them.
September 19, 2014 at 9:13 am
CapnHector (9/18/2014)
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).
Do you have all versions you're supporting? 2005 -> 2014?
I agree on cost. Cost is a big factor, especially as licensing has changed for VMs.
September 19, 2014 at 9:16 am
Barry G Freeman (9/19/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.
I agree. This is me, and a reason why I'd struggle to justify a 2000 upgrade at this point. If it's been working this long, it's probably OK.
September 19, 2014 at 9:19 am
jhadden (9/19/2014)
Every place I've ever worked has an irrational aversion to in-place upgrades. So the alternative is to prop up a new server / instance and migrate databases and redirect connections. This is a much more labor, resource and logistically intensive process companies never seem to have the time to do.It would be so much easier if they could trust the upgrade process. I personally don't understand the fear of in-place upgrades as I assume the in-place upgrade process has been thoroughly tested prior to RTM and certainly after SP1 has been released.
Does anyone do in-place upgrades to production servers? After 20 years, I have yet to see it.
I see it, but it's binary. Works or doesn't, and if it doesn't, you never want to do it again. These days I think it's possible, but I'd do it this way. I'd run a P->V of the original server and then shut down the P. Might take a little bit of time as I'd do the conversion first, then get later diff/log backups and have them ready to apply to the V.
When the P is down, bring the V online and upgrade. If it works, you can live with it. Worst case is a 1:1 VM:host for the SQL Server.
Viewing 15 posts - 16 through 30 (of 69 total)
You must be logged in to reply to this topic. Login to reply