Upgrades
-
I've spent a couple weeks on career polls, so I decided to go in a different direction this Friday.
Software is a funny business. In many ways it's a rather capital intensive business, it's just not physical assets, it's human ones. Think about it. To build a great software product, like SQL Server, a company needs to invest a bunch of resources (time and money) to get the product built. Granted you might not get it completely built, and you'll definitely cut corners to get the software to the market before the developers want to, but it still takes a substantial investment.
So you spend say $1,000 on the product getting it developed and you decide you need to spend $100 on marketing, advertising, etc. I hope you realize these aren't real numbers, but just numbers put out there for the sake of an example.
The software is ready to go, some cool, little utility that you're sure will change the world. You price it at $10 and start selling it. After you've sold 500 copies, you're in good shape. Revenue of $5000 with costs of $1100 and everyone is happy.
Or are they?
No matter where you are in the cycle of your products, you've still got ongoing expenses for developers. So they're either working on bug fixes for the current product (only helping with revenue as long as it sells), or they're working on the next version. At some point, no matter how big a staff you have, you decide you can't keep supporting version 1.0 when you're selling version 3.0 and working on version 4.0 at the same time. It's just too expensive to keep enough people around for these older versions.
And thus the upgrade path goes on. It doesn't matter if you use Microsoft software or Linux, there's a constant upgrade path and the further you stray from it, the less support options you have.
So this week, with Katmai slated to come out next year sometime, I'm asking you...
What's a good upgrade interval for SQL Server?
Here's the past history:
Version Year Released Interval from last release SQL Server 4.2 (on NT 3.1) 1993 SQL Server 6.0 1995 2 years SQL Server 6.5 1996 < 1 year SQL Server 7.0 1998 2 years SQL Server 2000 2000 2 years SQL Server 2005 2005 5 years SQL Server 2008 2008 2-3 years As you can see, the intervals haven't been completely consistent, but it's been close to 2 years, except for SQL Server 2005, which was a major paradigm shift and rewrite of the product. I'm not sure how to compare it to Oracle because they've had point releases and Microsoft has decided not to do that. However the plan I've heard from Microsoft in the past is a release every 2 years. They changed that slightly at the recent Microsoft BI Conference where one of the keynotes listed 24-36 months as the interval
But is that a good interval? My suggestion in 2003 to a few of the managers at Microsoft was to go with 3-4 years. It's a good interval, we don't get too out of date, but we have time to learn the ins and outs, let the product mature, and get our environments stabilized. They weren't thrilled with that and it's my idea that they're really only looking for 50% of their customer base to upgrade to every version. So SQL Server 2005 was designed to mostly get people off SQL Server 7 and earlier versions. SQL Server 2008 will be looking to move people from SQL Server 2000, etc. Given that support runs seven years, I'd think a 3 year time frame might make more sense for new versions. And maybe with 6 service packs and a point release in between, we'd be in a nice place as customers.
But what do you think is a good upgrade interval. Ten years is too long, anything less than 2 years is probably too fast. Let us know what the consensus is from this community.
-
Interesting article; especially the notion that SQL Server 2005 was really aimed at SQL Server 7 folks.
My take would be that 4 - 5 years would be about minimum. If an application was developed over 2 years, having less than a year of it running before needing a database upgrade would not be optimal!
We have had SQL Server 2000 here for ~4 years so far; an upgrade to 2005 is only just on the radar for next year.
I guess this depends on how many systems are reliant on the db.
-
It's interesting looking at the elapsed time periods between each versions of SQL. From my point of view, I can't believe SQL 2005 has been out for 18 months now! Where does the time go? It about 30 months ago now that I managed to get all of our servers onto 2000 SP3a, and then we did the SP4 upgrade this last Christmas. With all the testing that we go through for even an SP upgrade, regular version updates might put some people in my organisation in a bit of a spin!
I'm still working on how to tell them that I want to go to SQL 2005 by the end of the year! I don't fancy having to tell them to go to 2008 the following year. I would say a version release every 3-4 years would be suitable. After all, how much can you cram in to a new version every couple of years?
-
There is a fundamental difference between MS and their customers: MS are selling their products to a fairly established customer base and so new versions are the way to increase sales, whilst their customers are trying to increase their own customer base using a stable product.
My experience is mainly with VB and there it was VB3, skipped VB4, VB5 (only a little bit), VB6 and then .NET 2003. I reckon that I will be skipping 2005 and going on to Orcas aka VB2008 (the CTP is already out).
I personally wish that things would slow down a bit as the software is so involved these days and we are just getting to grips with it before we are told that we are out of date! MS are the best marketing company in the world and we blindly follow the hype.
Kind Regards,Ian Logan
straker.com -
We still have just under 100 databases to upgrade to 2005 yet, these are a mixture of 3rd party applications and in house. We will (if the wind is in the right direction) probably only just be on 2005 by the time the new version is out.
-
I agree with Ian, above. It's not how the world works - IT in particular - but wouldn't it be nice to get to a good and useful product and just... keep using it?
We moved up to SQL 7 because it was a big improvement on 6.5. We adopted SQL2K because it added bells and whistles but was broadly compatible with SQL7, which we are also still running. We haven't moved further because SQL2K does what we want, we understand it quite well, and there is no business demand or push to change it. We have loads of apps that use SQL2K as a secure, stable, managed data store (and we get BI from Business Objects with an Oracle warehouse).
I know the nature of the industry will mean we will eventually upgrade to ensure maintainability. But when a supplier wants to sell us again the product they sold us a few years ago, they are serving their interests more than ours.
-
I'm generally agreeing with all the points above, 2 years for a new software release is too quick, but wouldn't be so bad if it wasn't a server application like SQL Server. Like many of you guys out there, we have a combination of in-house software as well as bought-in applications. Realistically, I'd like to see upgrades not a timescale basis, but on a technological basis i.e. "here's a new release because it can do this, that, etc" rather than "here's a new version because we haven't released one for two years and we could do with some more revenue"
One of the problems we have is that while MS might say we need to upgrade from SQL 2k by 2008 (else we lose support) our software suppliers won't support their products running on a different version of SQL Server than was designed - which leaves us floating in no-mans land. And yes - I understand that most of the applications run fine on SQL 2005, but some have issues, and others use server side components written directly onto SQL Server (what can we do with these?)
Then we have the minor problem of having to go through a full test phase of every application we roll out to our user base - which in itself will take 6 months (provided there are no issues found). No-one will push a new MS product live without waiting for the inevitable service pack 6 months after release, meaning we can't get applications running on a new version for at least 1 year after the release of SQL.
No-one questions the need to push the product forward and I'm not saying that MS shouldn't try and push new technologies, but surely you should have a new product which has substantial benefits over the old one - otherwise it's not worth upgrading.
Dave
-
I think most of the other posters have already hit the high points. Upgrade and development times are just too long to support short release cycles. We started working with 2005 while it was in Beta. We started doing development against it for actual release code about 6 months after it came out. Not counting a few small apps, our first production releases to 2005 will be next month. We haven't even started talking about upgrading the existing systems to 2005. Yet, there's going to be a new version of SQL Server next year? Heck, the fourth book on the Inside SQL Server series hasn't even come out yet.
Either we'll skip the next release, or we'll skip upgrading the existing systems to 2005. I really don't want to have two (or more) systems to support if I can help it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
It's not just a matter of upgrading the software, at some point the people have to be upgraded too. It's definitely hard to stay current when your employer is still using currentversion -1 or currentversion -2. How much change will we have to master at each upgrade? No avoiding change, but a nice steady path would be nice!
-
As much I do not like short release cycles I think actualy it might be better. WIth a short cycle between releases MS don't have time to completely change the product around on us (i.e. 7.0 -> 2000 upgrade, vs 2000 -> 2005 upgrade). At least for me upgrading to 2000 was a no brainer on pretty much every server and DB I did it too, while 2005 has been, slightly more of a challenge.
-
I couldn’t have said it better than Ian. In my mind, SQL Server 2005 was not ready for release. In no time, Microsoft posted a SP1 and SP2 and then SP2a, that fixed issues that should have been caught in the initial release.
This amounts to lots of wasted DBA time, that could have been better served doing other things. 
Example: When setting up a linked server, you can’t see the data objects. (It took until SP2, as I recall, to fixed this issue)In my experience, most companies are just now starting to upgrade to SQL Server 2005. At my company, I have been working on upgrading from SQL Server 2000 to SQL Server 2005 64 bit. It has been an uphill battle all the way. I have opened 4 Tickets with Microsoft so far.
SQL Server 2005 64 bit – can’t connect to Oracle without an Oracle patch.
SQL Server 2005 64 bit – can’t connect to Lotus.
SQL Server 2005 – can’t connect to SQL Server 2000 until Instcat.sql is executed on SQL Server 2000
SQL Server 2005 64 bit – can’t connect to AS400 through Iseries until you run special commands on SQL.
SQL Server 2005 64 bit – doesn’t work with Project Server 2003, unless you apply 2 special hotfixes. (Still don’t have this issue resolved)
SQL Server 2005 64 bit –Can’t use the SQL 2000 Object to run DTS packages, must run with the dtsrun command.
SQL Server 2005 – Can’t convert ActiveX and a whole host of other objects in DTS packages to SSIS packages. (We have over 100 DTS packages)
SQL Server 2005 64 bit – Host of other things that 32 bit can do that is not supported in 64 bit.
In my mind, Microsoft needs to slow down and give us a quality product. SQL Server 2000 to SQL Server 2005 is a huge upgrade. Microsoft needs to work on getting it stable and working with other products before working on another version.
-
Like others in this posting, we haven't even completed our SQL 2000 upgrades. It takes time and money, not to mention there was a steeper learning curve with SQL 2005. There is so much different between 2000 and 2005 with all the new functionality from Integration Services to Notification Services. We need time to really get to know this product as DBA's, which for me is a thourough understanding of all of the features of the product. It seems as though SQL 2005 was just released.
We aren't even considering SQL 2008. I'll be attending TechEd, but I'll probably be skipping the SQL 2008 presentations.
5-years for me.
-
I definitely agree with the idea that 2 years is entirely too soon for an upgrade. With many people only now considering the upgrade to 2005, and Microsoft has admitted they aren't seeing the adoption they expected, it would be foolish to think of releasing a new product into the market anytime in the near future.
I feel MS should take the time and work on the x64 products, they seem to lack some of the essentials required to make them world class products. While I enjoy a job supporting MS products, I sometimes feel they forget about those of us that are selling their products to our own organizations. It's a hard sell when they continually upgrade products on the 18-24 month cycle. We barely have time to test, patch, and re-patch the products before the new version comes out.
With most people not adopting new products until at least 1 service pack comes out, it would seem logical in my view that MS should spend more time supporting their products and getting them stable than trying to force newer versions into the market.
I would say 4-5 years as a reasonable path.
-
I'm part of a very small (2 people full-time) supporting about 300 users of an ERP and WMS system using SQL Server databases. From our perspective, 5 years is a good timeframe - upgrading is a huge effort - machines, operating systems, WMS, ERP, terminal servers, etc. There doesn't seem to be much real benefit for us to upgrade more often. We get a bit more functionality each time, but that's usually credited to the higher level ERP & WMS systems.
We don't have a choice about upgrading our SQL - when our software vendors demand it, we must do it. But, it's very time consuming & costly.
-
My thoughts are 3-4 years (preferably 4) between releases is a good idea.
Consider this: Not everyone is going to jump on the upgrade bandwagon. Of those who do, 85% of them are going to wait at least 6 months after a new version for the other 15% to find all the bugs, have all the server crashes, etc. It certainly happed at my work place, though we waited 9 months instead of 6.
So, the customers who want to upgrade have already lost a quarter to half of the current life cycle of SQL Server. And that's the people who can implement an upgrade quickly and fairly easily. Small environment people, people who have all their upgrades automated, etc.
Then you run into the big environment people. The big environment people are going to upgrade a little bit at a time. It'll take them at least a year to catch up to everyone else, which may or may not include the implementation planning stages. We have 4 servers (brand new hardware) and it took us 5 months to plan our upgrade (we did everything, including DTS-to-SSIS). I shudder to think how long it'll take for people with over 20 servers.
Lastly, there's the out-of-date hardware / out-of-date "essential" software people. People who can't upgrade because they can't afford the new hardware or their necessary programs won't run on the new OS's, etc. These are the people that are still on SQL 7 or SQL 2000 and if MS puts out a new version every 2 years, they're going to be unable to upgrade at all by the time SQL 2010 comes out. Or they're going to have to jump through hoops trying to find someone who sells the "defunct" SQL 2005 version so they can upgrade.
And Microsoft wants to stick to a 2 year schedule? YIKES!
Viewing 15 posts - 1 through 15 (of 39 total)
You must be logged in to reply to this topic. Login to reply