This is a really good question. Cloud hosting of enterprise data seems to be a polarizing topic whenever it comes up in technical circles. Opinions range from gushing optimism to vehement hatred of all things cloud, so it's kinda hard to get the middle-ground picture on things.
That said, I've been involved with a number of enterprise migrations to cloud hosted solutions and here's the common sticking points that I've noted:
Long-term data retention and retrieval are easy to overlook when you're looking to move 'into the cloud'. Consider a scenario: It's 5 years later, and you want to move from your current provider to something different (another vendor's cloud, or back to a local software stack). How do you get your data out of the current system? How usable is the data going to be once you've got it?
With an in-house software stack, you bought the license, so you can restore the stack at a later date and restore your data if you absolutely have to. With a cloud solution, you have to ensure that you a)have an extract of the data and b)have some way of presenting that data. This is of particular concern if the data in question is required for any regulatory compliance reasons.
The bigger players in the various areas of cloud hosting are starting to improve their approach to this by exposing more APIs for data retrieval and settling on more standard formats. That said, you need to do your homework around this and ensure that the retrieval mechanisms you may require are present, and that they remain present as the product evolves. This brings me nicely on to my next point which is.
One of the touted benefits of cloud hosted software stacks is that development and improvement of the system is iterative, and the hassle of updating the system is entirely offloaded to the vendor. Of course, this also means that the update cycle is taken out of your hands, so changes in the way the system works can pop up without warning.
A good way to identify elements of your IT infrastructure as suitable for cloud hosting is to look at a system and ask 'Are we using this in a standard manner that's mirrored in other organization?'. Common examples of this are Email (most businesses use email in the same manner) and corp website serving (which has kinda been 'in the cloud' for decades).
A great example of the potential to get burned by this just happened: Google Wave's had the plug pulled on development, and it looks pretty likely that it'll cease to exist as a discrete tool in the near future. Some businesses are already invested in wave as a collaboration tool within their organization, and those must now find a new way of conducting that aspect of their business. So you should consider the question of 'what happens if that neat widget that saves the finance guys hours of manual work gets removed next week?'
While many cloud vendors tout stability and uptime as core advantages of cloud solutions, few seem willing to wrap their SLAs (if they even exist) with proportionate breach compensation. The big players have a lot of customer confidence in the reliability of their systems, seemingly on the basis that they're too big to fail. But is that really the case? There are numerous instances of large vendor cloud solutions failing. When you get down to the smaller players in the game, how can you even begin to evaluate the robustness of a vendors cloud solution? They are inherently hidden away and unknown.
So there's a strong need to look at any cloud solution from a DR perspective and say 'OK... assume this service disappears off the face of the earth one morning. How would the business suffer, and what would we need to do to recover from an indefinite outage? How long would we wait before we attempt to restore some form of service internally?'. These are all the kinds of questions you ask about your internal system when generating a DR process, but with a cloud-hosted solution you may not have sufficient options to adequately cater for DR, and it may not be wise to assume that a cloud solution will achieve the up-time you require.
So here's a scenario: You purchase 25 user licenses for a cloud-hosted email system. You reach your license limit, and an employee leaves and a replacement employee come on-board. What happens when you set that new employee up on the system? You'll have to either purchase an additional user license, or re-use the user license from the exiting user. But what about that exiting user's email? Does it all go up in smoke? Is there some kind of long-term freeze you can put on the account and free up the license? Again, this is a tricky one, vendor-specific, and you might not hit the issue until you've been running your new system for months. But it's a gotcha.
Full Disclosure: My employer Fronde is heavily invested in cloud solutions, and has ties to Google. Everything in this post is my opinion and not necessarily that of Fronde.