SQL Server 2005 or 2008 for release

Question

We have been using sql server 2005 during development and have had no real issues.

Now at the time of the release, it has been suggested we go with SQL server 2008. The installation of it is a bit of a nightmare with all the configuration options and I am sure this will confuse the customers (even with documentation). Powershell etc had to be installed together some other apps before it could install, as well as some windows updates.

Should we just release with SQL server 2005 (if I am not wrong the installation was easier) or would it be better to go with 2008 (and just accept the installation issues)?

JD

Answer 1

In a few years time new customers will not be willing to run with SQL Server 2005, so you will have to support SQL Server 2008 at some point.

My experience is it can be very hard to get current customers to update to a new version of a database server when you wish them to take an upgrade of your software, so you will most likely be forced to support SQL Server 2005 for a long time if you allow your customers to use it now.

So do you wish to?

• Have some pain now getting SQL Server 2008 working
• Or, have the cost of testing and supporting both SQL Server 2008 and SQL Server 2005 every time you do a new release for many years to come

You have to decide if a small delay in releasing is worth it to save the ongoing cost...

This is hard, as time-to-market is often more important in the real world then ongoing maintenance costs. After all if you don’t hit the market window, you have no ongoing maintenance costs!

Answer 2

The install/config issues shouldn't really be the primary focus, because those are one-time things and a well-written guide can address the vast majority of the issues you encounter.

Here's what I would consider making my decision:

1. Testing - Everything should work fine out of the box, but you're responsible either way. Better the devil you know than the devil you don't. There is a time and a place for upgrades, and right before a release isn't it.
2. Licensing - Remember that newer software often comes with a higher price tag, and you don't want to be forcing more expensive software on your users without some tangible of benefit.

All in all, I would stay away from upgrading for upgrade's sake. Stick with what you know, until there is a legitimate gain from upgrading.

Answer 3

Based on the information provided, stick to 2005.
Migrate to 2008 after you've been able to run the application in a test environment, thoroughly test it, and check documentation to be sure things line up.

Answer 4

Will this delay your release? Will it delay it enough to cost money?

I wouldn't worry too much about the installation complication. Your customers will experience the same (or worse) when they have to upgrade to 2008, which they will eventually because you won't stick with 2005 forever. I'd be more concerned about how it affects your project and sales. That would be the trade-off that I would focus on.

Answer 5

I'm always wwary of making last-minute changes to an application before release. If you decide to switch to SQL 2008 will your team have time to fully regression test your application? I wouldn't just assume that everything will work fine.

If you have the time for full regression testing then the question is, what does SQL 2008 offer to you? Obviously there's no critical technical reason - no function that is in SQL 2008 that isn't in 2005 but which you absolutely must have. Do you think that your customers will care one way or another? Do you have customer that already have 2008 servers and want to leverage that? Will it help your sales to be on the "latest and greatest" version?

Those are just some of the questions to ask.

You can always save the switch to 2008 for a future upgrade.

Answer 6

If you've developed and tested on 2005, then stay with 2005 to avoid complications, but I would upgrade everything to 2008 at some point.