In my experience. cost often doesn't get consider.
The cloud providers' media machine is very strong. The key messages are essentially "cloud is modern" (meaning anything else is "old") and "cloud is cheap" (meaning anything else is "expensive").
Of course nobody wants to miss the boat, so most places are jumping onto that bandwagon, often without assessing the true costs.
Probably the biggest surprise to many people (often too late) are the "egress charges" - every byte which moves from the cloud provider to the outside world, and sometimes even to another region within the provider must be paid for. So if the person who is reading your database gets the results on his local machine, or an on premise server that costs money.
Another area not often considered is how to get the same level of high availability that they've come to expect from (for example) HADR or PureScale.
There is also a degree of loss of control. That's particularly true for anything other than IaaS, where you are reliant on whatever the cloud provider exposes to you in terms of functionality (often a lot less than the underlying product is capable of). For example, point in time recovery to any point of your choice - that will probably cost you extra if it is available at all.
I'm seeing in the media that some people are starting to wake up to some of these issues. One recent example was that the company who originated the Ruby on Rails framework has gone back to on premise and reduced their cost by about 90% (from memory). But the examples of this are mostly the most tech-savvy companies.
I think the cloud providers rely on the fact that once an application / database moves to their platform the company who does it will probably lose the people who have the skills to take it back again. If AWS / Azure / Google manages your installations and patching then why should you retain your own people with these skills ...
I'm not saying that cloud services don't have a place. But my personal belief is that the sweet spot for cloud hosting is where the resources are short term. Either that means additional capacity for busy times, extra development servers or short lived applications e.g. for a special sales campaign. For systems that have to be available 24x7x365 the costs just don't stack up, even if you factor in the costs of having your own staff.
One interesting twist in this whole tale is that there appears to be a big upturn in interest on hosting containerized apps on zLinux, using Kubernetes or its derivatives like OpenShift. If you have a mainframe and can dedicate some of that resource to zLinux then essentially you have a very scaleable "private cloud" infrastructure that is capable of hosting the same applications that would run in a containerized environment on the cloud providers.
Another thing that has become clear to me is that you can't treat cloud hosted databases in the same way as you treat cloud hosted applications. The big difference is that you can typically throw away an app server and rebuild it from scratch fairly easily. But you can't do that with a database server or you will lose all your data. Unfortunately the people normally running cloud migrations are application people with an application mentality, which can be catastrophic for your data.
It's an interesting time. Personally I'm running both Db2 and PostgreSQL on my local (Linux) laptop here - and am learning how to move data and databases both ways. I think that knowledge is going to come in useful over the next few years - and particularly how to bring data from PG into Db2 (HINT : federation and "LOAD FROM CURSOR" is likely to be your best friend).
Phil