Principles
It's important to remember that generally, a cloud service is just a bunch of computers you don't own. Moving stuff to the cloud doesn't take away your need to do sysadmin stuff, even if you build from system images provided by the cloud provider - you still need to monitor for intrusion, check performance and keep systems patched up to date and so forth.
Considerations
What's your actual workload?
If you are doing lots of data moving to or from your on-prem networks, you'll need to factor in the cloud provider's bandwidth costs. If you are serving lots of clients out on the internet then it may be that the cloud provider's bandwidth costs are less than you are paying for on-prem or self-hosted stuff. Do you have modern servers already doing the work? if so you might want to consider sweating those assets before considering a move of platform. Are you doing video/audio stuff? Yes that can be done with some fiddling about although multicast isn't really supported in AWS for example so using something non multicast-based like Network Device Interface (NDI) from NewTek rather than SMPTE2110 from the Society of Motion Picture and Television Engineers is preferred. I'm going to blog about how we built a virtual TV studio on top of AWS in the near future so stay tuned!
Do you actually need to host your own server images in the cloud?
If you are doing web-serving at scale, you might well want to consider using "Serverless Computing" although that does rather lock you into a particular cloud providers platform very tightly On an anecdotal note, I gather from this podcast that the whole of the Stack Overflow family of sites runs on just nine (9!) servers on-prem with much RAM allocated for the underlying database engine. Basically you need to do the numbers very very carefully to get a good idea of what would be the most cost effective approach. Also it's important to bear in mind, if you are building from scratch, that Cloud servces provide many useful building blocks quite cheaply such as firewalls, load balancers etc, so you can avoid a lot of tricky network design issues (as that has already been done for you to some extent) but again you run the risk of vendor lock-in.
Bandwidth requirements
It's important to note that AWS bills for bandwidth very differently from hosting providers or from leased-line providers (if you are hosting on-prem). Hosting providers and some leased-line providers tend to bill on a 95th percentile basis - see opmantek.com for a succinct explanation, but basically it is a way of lopping off short peaks of traffic and billing on the underlying 'average' traffic. AWS bill in an incredibly complicated fashion; in fact if you search Amazon help pages for 'billing' and 'bandwidth' you don't really get anything useful. However some very nice people at Open Guides on Github have a great graphic explaining the complexities.
Now I don't know about you but I think this is pretty impenetrable and needs careful consideration with an application architect while pricing the solution!
Other considerations
The Cloud companies make available firewalling, load balancing and auto-scaling for very competitive prices compared with buying hardware to implement these functions and integrating with your existing systems. You might also be considering a hybrid strategy where your primary systems are on-prem and you have a backup in the cloud,maybe with continually-running database servers synched with your primary and front end servers in the cloud that are started when there is failure of your primary systems?
Security
Who has access to your data? Unless you encrypt at the disk level then backups that could be created by cloud staff are a possible way for your data to be stolen. How can we be certain that this does not happen?
Legal issues
General Data Protection Regulations, Online Harms Act and Safe Harbor/SCHREMS II; you are really going to have to be very sure in the near future that you know excatly where your data and servers are hosted to avoid legal issues. For instance, we once worked with an online entertainment platform who had- TV studios in London
- Front-end servers in Netherlands
- Games engine in Israel
- BackOffice systems in the Channel Islands
Costs
Predictability of costs
It's been our experience that the pricing of Amazon Web Services (AWS) is very difficult to predict costs in advance even with a good knowledge of your workflow. This may not be a big issue for large corporations but could make a big difference for an SME's bottom line. On the other hand, if you have a good idea of how many servers you'll need to deploy your application, that pretty directly maps onto rack-space, power and cooling requirements which in turn will give you the co-lo price for the space you'll need OR will let you get a price for approximately the right number of hosted servers from someone like Rackspace.
Cheapest price?
Of course it's not all about immediate costs; there are other factors to consider - are you doing a green-field install or do you have existing installed plant you want to carry on using (and is that on-prem or in hosting) - what scale are you building to? We aren't all building https://www.bbc.co.uk and it's amazing how much work you can get done with a small number of physical servers
Long term considerations
Is your hosting provider there for the long-term?
It should be noted that Jim Chanos, the infamous short-seller who predicted Enron's downfall, also predicts that Data Centre suppliers (aka datacenter real-estate investment trusts or REITs) will have their lunch thoroughly eaten by the big three cloud providers - although companies like Rackspace naturally disagree. See this article in The Register for a good discussion of this.
Or the short term?
We are being asked to move some of our data-centre hosting as one of our suppliers is closing the hall which is housing some of our servers, which means we will have to go through the pain of physically migrating our servers from one location to another, and maybe having to change the IP addressing scheme and the consequentials of that too. We wouldn't have had to do this with a cloud provider (or at least the process would be very much simpler). On the other hand we have designed in multiple data centres, so we can easily manage down time at one hosting site by switching to another.