April 10, 2014 at 8:49 pm
Comments posted to this topic are about the item How Long Before You Upgrade?
April 10, 2014 at 10:54 pm
Ummm someone I know works on LOB applications.
They would run their application on the CTP, then the RTM, and then on the development server, and finally tell the business to upgrade its hosted platforms.
The business eventually forced him out. Then they forced someone else who could do it out. Now there is nobody to do it, and they will likely be stuck on 2012, a few CU behind, for the rest of eternity.
But you know they don't even use the 2012 features anyway so it's not a huge deal. Why? Because one customer insisted on running their own server, and that server is stuck on 2008. As a result, that's the version the LOB must target, and the entire business (and its tens of thousands of other customers) gets held back.
Fun. Moral of the story: If you do an LOB application, and a customer wants to host their own, make forced upgrades part of the contract.
April 11, 2014 at 1:22 am
Cody K (4/10/2014)
Ummm someone I know works on LOB applications.They would run their application on the CTP, then the RTM, and then on the development server, and finally tell the business to upgrade its hosted platforms.
The business eventually forced him out. Then they forced someone else who could do it out. Now there is nobody to do it, and they will likely be stuck on 2012, a few CU behind, for the rest of eternity.
But you know they don't even use the 2012 features anyway so it's not a huge deal. Why? Because one customer insisted on running their own server, and that server is stuck on 2008. As a result, that's the version the LOB must target, and the entire business (and its tens of thousands of other customers) gets held back.
Fun. Moral of the story: If you do an LOB application, and a customer wants to host their own, make forced upgrades part of the contract.
...or support multiple versions???
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 11, 2014 at 1:23 am
Our company is not a consulting or developing company, we are the customer and we often think: when something is running fine, leave it, don't mess with it.
We still have 2 instances of SQL 2000 because they have applications running on it that need this version. Since we don't want to update the application, SQL 2000 will be used till we decide to a new application.
Beside the SQL 2000 we have one instance of 2005, several 2008R2 and since a few month one 2012.
As you can see, a mix of several versions.
How long before upgrade? When the application needs it, otherwise we keep it at the same version.
have a nice weekend,
Vera
April 11, 2014 at 1:29 am
As I work as a freelance software development consultant, I occasionally get to influence the versions used of relevant software but not always. I like the strategy of do everything on the latest available version The definition of latest differs from company to company; for some it means the latest release from the vendor, for others the latest authorised version to use (which may be many versions old). That way you are likely to get the longest time possible for the given circumstances between commissioning systems and upgrading them.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 11, 2014 at 1:36 am
Vera-428803 (4/11/2014)
Our company is not a consulting or developing company, we are the customer and we often think: when something is running fine, leave it, don't mess with it.We still have 2 instances of SQL 2000 because they have applications running on it that need this version. Since we don't want to update the application, SQL 2000 will be used till we decide to a new application.
Beside the SQL 2000 we have one instance of 2005, several 2008R2 and since a few month one 2012.
As you can see, a mix of several versions.
How long before upgrade? When the application needs it, otherwise we keep it at the same version.
have a nice weekend,
Vera
Sensible approach in my opinion.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 11, 2014 at 1:59 am
I know of a company that has a SQL2000 instance still running in SQL7 compatibility mode.
The drive to upgrade comes when it is a physical machine with a spiralling maintenance cost attached to it. A 10 year old server will be 32bit, have a large physical footprint, require more cooling and power and be ever more difficult to supply replacement parts. In the same rack space as the old physical server machines they could host 128 virtual servers, each of greater power than the single physical machine.
There are two barriers to upgrading from SQL7/2000
1. Licencing costs
2. Huge number of DTS packages
April 11, 2014 at 2:06 am
I'd have to say that I have seen deprecated features, such as DTS like David.Poole mentioned, are a barrier to upgrading. This is a technology agnostic issue as I have seen the same issue holding back upgrades and migrations due to differing technologies such as .NET.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 11, 2014 at 2:47 am
I guess the companies motives and my own differ. I want to keep my skill set current and play with all the new features, the company don't want the cost of upgrade and regression testing without good reason. From my experience unless I can find a good justification upgrades happen when vendor support starts to go. Currently we run a lot of 2008R2 and a couple of 2012 and 2005
April 11, 2014 at 4:03 am
graeme.shorter 69931 (4/11/2014)
I guess the companies motives and my own differ. I want to keep my skill set current and play with all the new features, the company don't want the cost of upgrade and regression testing without good reason. From my experience unless I can find a good justification upgrades happen when vendor support starts to go. Currently we run a lot of 2008R2 and a couple of 2012 and 2005
This is where I would like to see companies allow both time and resources allocated to keep their staff up to date WITHOUT forcing upgrades. I have seen places where they evaluate new releases by test/sample migrations of the database or software most likely to require it soonest.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 11, 2014 at 5:48 am
We have been running on SQL2008 Standard edition (not R2) and recently upgraded our hardware to a relatively massive machine with two 12 core processors and 256GB of memory. Although we planned to upgrade to SQL2012 soon, we are seriously considering pushing it off until extended maintenance expires on SQL2008.
As it turns out, Microsoft didn't add a cap on memory and processor usage for Standard edition until SQL2008 R2. So if we want to upgrade and use all of the resources we currently have available, it will be a considerable cost increase to license 24 cores on Enterprise edition. That said, the server is definitely overpowered at the moment. We could upgrade and stick with Standard, but it would still be a pretty big increase in cost to license up to the 16 core cap on Standard and we would be limited to 64 GB of memory.
Up until now, the only thing delaying our upgrades was the time to schedule the work, but I'm really having a hard time justifying the extra cost based on the features that upgrading makes available this time.
--Andy
April 11, 2014 at 6:02 am
Currently running 2012 , will upgrade to 2014 this year or next.
April 11, 2014 at 6:12 am
I manage the Business Intelligence server for my company and we just started planning our upgrade to 2014. I expect that all our BI servers except the SharePoint/SSRS stuff will be upgraded by the end of August.
Again, we're very early in the planning stages but the rough outline goes something like this:
1. Developers upgrade to Visual Studio 2013 and SSDT-BI
2. Upgrade the SSIS servers
3. Upgrade the SSAS servers
4. Upgrade the Data Engine servers
We did an in-place upgrade of 2008 R2 to 2012 when it came out and didn't have a bit of trouble. This time we're doing side-by-side and will switch out Production servers over the weekend.
To be honest, we probably wouldn't be upgrading so quickly if it weren't for the In Memory Columnstore indexes. Nothing has really changed in any of the major SQL Server features except for the data engine but we have seen some fantastic results with the columnstores. We didn't get much traction with them in 2012 because of the extra work that needed to be done with the SSIS packages to add the DROP/CREATE steps wherever we needed them. Now it's a no-brainer.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog
April 11, 2014 at 6:20 am
I'd be more interested in the other half of the question. How will you prepare for your upgrade?
Places I've seen have no testing methodology for their LOB applications and basically "start it up, and if things appear to run, stick it in development, and if it doesn't fall over, give it to your smallest client, and if they don't die, deploy it to the rest."
I think you are MEANT to do a full backup, begin a trace to record a day of work, take another backup, and then use replays to compare the end results. Right? But, not many people appear to have gone into depth with examples of how to do the "best practice"... so few do it.
April 11, 2014 at 6:31 am
We do the trace-replay method of testing. However, you lose the original concurrency aspect. I think it would also be worthwhile to run some kind of load-test with your maximum concurrent users if possible.
Viewing 15 posts - 1 through 15 (of 57 total)
You must be logged in to reply to this topic. Login to reply