I see this , at least initially, not so much a matter of methodology as one of strategy. Before one can address "how" parts of your portfolio will move to the cloud one must first ask "what" can and should move. I see this as a thoughtful planning process where one examines the age, operational costs, complexities and support limitations of applications in the current portfolio and makes priority decisions about which ones need to be modernized. That may mean in place upgrades or replacement with some other type of offering which may or may not be cloud based. The next step is, of course, evaluating the options and making decisions based on what is available and meets your needs. I believe some of the most compelling cloud-based applications today are those that address core business processes that are common across industries such as HR, collaboration, even e-mail.
As far as the actual migration itself, I personally don't know of a tested and published methodology. I'm sure that the major consulting firms have or could develop a methodology but I believe that this is a competency that IT organizations need to learn and develop internally because it is really the first step in managing these vendors and I believe that this will be a key function for IT organizations in the near future. Gartner even has a term for this calling this function "service brokers.". I see migration to a cloud-based application as first and foremost a project that needs to be planned and executed using good project management principles. The big "gottchas" in these migrations are usually, in no particular order, data migration, performance, compatibility and interoperability with your environment (no, everything isn't always "plug and play" regardless of what the vendor tells you). Most vendors have a basic migration plan that, if properly managed, will work well. Rigorous testing is critical of course. So, use the vendor's migration tools and process but manage the project yourself using sound project management methods.