Dealing with vendors can be maddening to say the least. One of the reasons is because whenever you find a problem with their DB code they're very reluctant to change it. And to a degree I understand that because they've got regression testing to do to make sure it doesn't break anything else, but very seldom do vendors bother updating their DB code at all. This is particularly true when porting their app to a new version of the DB platform. Again, since this is mainly a SQL Server blog I'll use that as an example, but it definitely applies to all DB platforms.
Let's look at an example of upgrading an application from SQL2K to SQL2K8. I've got plenty of apps in-house that are in the middle of an upgrade of both the app and the DB. And one of big things that remains the same across the board is that the vendor hasn't bothered updating any of their code to take advantage of any of the new features in the DB. There are so many new coding and management features in SQL2K8 that vendors are doing their customers a true disservice by not updating their code to take advantage of it.
So what does that mean we gain from an upgrade of your product? Well, we as DBAs gain the extra management features that are under our control, and we gain the extra DMVs, etc, but what we don't gain is the increased performance for the app itself. I've got more than one app here that has DB code over 20yrs old. They're all on SQL2K5 and above, and the only thing the vendor has done to port it to the new version is to make whatever minimal changes needed to make sure it compiles and runs. Anything else is ignored. And what's even sadder is that many of the apps I've seen like this are from vendors that sell DB management products and even they don't bother updating their code.
Now look, I live in the real world and I really don't expect a company to necessarily go through and update 600 SPs every time they port to a new platform. What I do expect though is that they take their top 10 or 20 SPs and give them the overhaul they deserve. Then they can slowly touch the rest of them on a regular schedule or as needed through service packs or interim releases. This is the way you're supposed to do these things. What you don't do is keep the same lousy code in your system for 20yrs only making the bare minimum changes you need to make something compile. This is not the way to say you care about your customers and it's not the way to keep them.
One of my big rants is about how companies always brag about having big companies as their customers. We've got Nokia, or we've got Hilton as one of our big clients. And that's very misleading because I've been that large customer many times and watched almost everyone in the company do nothing but complain about the product and then get the cold shoulder when they went to the vendor to have them make a change that really needed to be made. So it means nothing to me that a company says they've got a huge company as their client. What matters to me is, are they happy with you? If I went to their DBA and their app support people and asked them a series of questions would they tell me you're responsive to their needs, or would they tell me you took their money and ran? Would they tell me that you've fixed the biggest performance problems in the new version you forced them to go to so you could get the upgrade fee out of them, or would they tell me that it's the same old crap in a new wrapper?
So I'm speaking directly to you vendors out there now. Do the responsible thing and update your DB code when you port to a new version. I understand that you don't have time to do it all, but you do have time to knock out the top 10 or 20 worst performers. You can work your way out from there. And I'm tired of hearing the excuses that you don't have time with your tight release schedule. Release schedules aren't divined; they're set by you. So loosen the schedule a little bit and give yourself the time to do things right. And stop hiring C# guys to do your DB dev too. It's pathetic. There's a reason why you got a C# guy... because you needed someone who could write C#. But if you have a SQL component then you should also buy yourself a SQL dev. If he's dedicated to making your SQL code run well then he'll have plenty of time to make the necessary changes while the others are doing the front end. And while you're at it have him tune your indexes. So many of your problems can be solved by having efficient indexes and none of you seem to be able to grasp what a good index is.