2. Implement limited, non-critical functionality. There's a reason new skiers start on bunny slopes, and it's an appropriate approach for cloud computing as well. An application that the business does not depend on allows a more measured perspective and evaluation. Conversely, if the first application "has" to run, one can be sure that problems will not be seen as educational opportunities, but rather as full-on emergencies, which is not conducive to organizational learning.

3. Circumvent cloud infrastructure dependence. Perhaps the best way to protect oneself from a poor choice is to implement in a fashion that insulates one's applications from direct dependence upon a particular cloud implementation. There are several techniques to accomplish this.

First, manage your application code for deployment flexibility. Design the application so that it encapsulates code and software component installation, thereby allowing substitution of specific cloud infrastructures.

Second, use vanilla code components and eschew the use of cloud-specific services. Read my for insights about the potential downside of leveraging a particular vendor's application framework. Instead, use components and services that are widely deployed, enabling you to migrate an application among several cloud providers.

Finally, don't grow too dependent upon your initial cloud provider's management console. There are a number of cross-cloud management tools and frameworks, and you should evaluate them to determine if one of them can avoid dependency and lock-in.