I do a bit of work in the consolidation space, and speak about it a lot. The update to my old SQL Server 2000 consolidation planning whitepaper is almost done and I should be doing a webcast next month. But I wanted to address one thing here in the interim: the biggest sticking point is not moving databases or maintenance plans; it's applications. There are lots of aspects to this which I am not addressing in this blog post. I am specifically going to address application compatibility with later versions of SQL Server such as 2005 or 2008. A common complaint I hear from many customers is that the applications they use do not support SQL Server <insert version here>.
There are a few issues with this really large, and to some degree, crippling problem:
1. Part of the problem is not the vendor, but the customer.
a. Many vendors do have later versions of their application; customers just haven't implemented it. I'm oversimplifying here; it's a deeper problem than that which is explored in the next few sub-letters.
b. Change is hard. Later versions introduce new, or changed, functionality that may not even be used. If something is changed, it may not be to a customer's liking. As far as unused functionality, there comes a point for a lot of people where what is there is "good enough" and there may be no reason in terms of features to seemingly want to upgrade.
c. If the application is highly customizable (such as Siebel), it's not a slam dunk just to implement it. There's downtime as well as retraining of end users.
d. This one is really a side effect of a, b, and c: even if it means not being supported, it sometimes may feel like it is just easier to go with what you know.
e. ... and then there is cost. Upgrades generally are not free.
You can work through downtime and any technical issues associated with an upgrade; the more intangible (perceived value) and tangible (do we have money to do this?) are a bigger problem.
2. In the cases where there is no later version of the software, it's unfortunate, but Microsoft cannot play the heavy and force vendors to make an application support a later version of SQL Server. Believe me, I wish they could, but I can only imagine the potential legalities of that. It's really up to the customers to make their voice heard to get a version of an application that supports what they need. If they can't, realistically, it may be time to move to another software package that supports the platforms you deploy. You could possibly consider virtualizing the server and its SQL Server instance, but you're still supporting the old version of SQL and you need to be sure the vendor supports you in a virtualized environment - but you do get rid of the physical box.
3. All of this is a Catch-22. Your application pain now forces you to deploy or still keep older versions of SQL Server in play, affecting your long term supportability not only from Microsoft but in terms of your DBAs. Do you want your DBAs to be a long way behind in their knowlegde of the platform? Heck no!
By the way, this problem extends to service pack levels. In my experience, some software won't allow you to upgrade/patch your SQL Server instances to a later service pack unless they support it. That doesn't bode well for consolidating that application where you have a shared instance with N number of databases, all of which will be upgraded at the same time.
Trust me, I wish I had a magic wand to make these issues go away. They are very real and must be dealt with appropriately in a consolidation effort. What is right for one customer may not be for another. I do enjoy helping customers work through these issues, but I can assure you that it is never easy and hard decisions need to be made.
Subscribe