Randy, I can virtually guarantee you that a competent consultant could quickly find a myriad of misconfigurations, suboptimal infrastructure, poor mx, bad queries, BAD indexing, etc. etc. etc. A fair bit of that would be considered low-hanging-fruit and fixable pretty quickly. And if the ISV uses sprocs or other in-database TSQL code you have access to there are things you can do that would be low-risk but offer huge performance (and concurrency) gains. Same for indexing, although with that it doesn't matter what the code is. I note that those two things will likely get you to an "unsupportable" state, but I have had any number of clients partake of them out of sheer necessity. Oh, plan guides are a possibility too, although I find them to be a bit too fragile. A consultant could also get rather direct with the ISV if necessary in showing them just how awful the system is designed, coded, indexed, etc. 

Oh, and please don't post to a year old thread. Start a new one. 🙂