企业显然能够选择验证云应用迁移的业务案例。但是很明显，与云迁移相关的技术问题会毁了业务案例，破坏应用甚至产生应用性能和稳定性等其他方面的问题。
考虑实施云迁移的应用架构师们需要审查他们的整个应用生命周期管理(ALM)流程。然而除此之外，他们更应当特别注意管理的性能和可靠性，确保合规性和安全性，以及重中之重地确保云计算中的运行效率和稳定性。
通常来说，主要通过人工操作部署、重新部署和管理的应用都大多拥有静态资源并很少有改动。例如，大约三分之一的应用生命周期管理活动只使用最少的工具用于部署应用和组件，而低于15%的活动涉及到使用自动化工具用于测试性能和验证安全性。云应用迁移中最大的一个技术问题是要针对ALM创建一个更加灵活和自动化的框架。部署是这一个过程的核心。
反思云迁移中的应用模型
重新思考应用模型以寻求实现高效的云迁移是非常关键的。它不再是一个针对一台服务器或虚拟机的软件镜像，而是一种架构，一个通过虚拟网络链接、托管在机器镜像库中并准备致力于提供资源的一个虚拟组件架构。
这个模式反映了如下一个事实，即应用组件关系是由应用架构师事先设计并确定好的，但是只有在应用被部署之后这些关系才具有实际意义。为了实现这一目标，整个虚拟架构必须针对云计算的特点，并通过网络服务连接成为一个整体。人工部署是根本无法实现这一目标的。合适的解决方案是：使用DevOps工具。
DevOps是专为多组件应用的“脚本”或自动化部署或重新部署而设计开发的一个开源和商业产品集合。理想情况下，这些工具将使用一种模块化的脚本/建模形式(一个流行工具)来支持服务器、网络、数据库甚至应用机器镜像存储。
选择正确的DevOps工具是至关重要的，同时可供选择的工具也是非常多的(其他的例子包括Chef、Heat和Puppet)。如果孤立地评估这些工具，那将是很困难的。最好的办法是选择一些有代表性的应用，然后使用每一个工具进行试部署以确定其中哪一个工具能够实现最简单的运行状态、达到最好的控制效果以及支持最广范围的应用。你将需要在这个通用DevOps框架基础之上针对每一个新的云应用构建你的ALM实践。
一个对部署工具需要特别考虑的领域是通过冗余来管理可用性和性能的。负载平衡和故障转移往往需要有应用设计级的关注以便于管理数据库的完整性，而在转换过程中确保性能和可用性流程能够适当地保持上下文和状态。
这些相同的因素通常需要在部署和ALM中予以特别的关注，这是因为关于组件额外副本的决策一般是由监控反应时间或组件可用性的一些管理程序触发的。在部署过程中必须由连接触发额外组件副本的安装，而且应当通过DevOps工具中的模块而不是独立脚本或手动过程来启动这些新副本。否则，这些做法可能会影响基线部署和增量变化之间的同步过程。
在云迁移过程中保持合规性和安全性
当然，安全性和合规性是在任何云应用迁移中需要考虑的关键问题。
现在的普遍看法是，除非镜像安全性(和可审计性)程度非常高，否则加密密钥和认证的详细信息都不应被存储在云计算的机器镜像中。有时候会被疏忽的是在云计算中或在云计算与数据中心间集成应用组件的部署工具，如果工具本身受到损害，那么它们可能就会带来安全风险。一个受到污染的部署脚本能够轻松地将其作为一个合法的组件部署木马(Trojan)，从而也就确保云计算的ALM工具完全安全。
内部审计人员还应包括在他们合规性审计中的工具或者可能导致认证失败的不完整风险评审。
所有这些都与云资源活力的基本问题交结在一起。云计算托管在地理意义上的位置，在主机和用户之间网络连接的质量和可用性都有着显著的不同。这对响应时间和工人经验质量有着重大的影响，这意味着，当应用迁移至云计算时，在应用运行的云计算托管点验证应用是非常重要的。如果提供了无法接受的结果，那么可以肯定，云计算服务合约可限制应用的运行环境以避免产生额外的问题。
资源活力也会影响安全性和合规性。应用镜像和应用数据可在云计算中进行迁移，而每一个新站点可能有不同等级的物理安全性和不同的司法管辖区监管因素，例如税收征管或某些类型信息或内容的托管。应在整个托管位置范围内测试应用的每个假设，而不仅仅是你认为应用将会运行的位置。
如果云计算供应商与其他供应商有一个联盟协议以覆盖偏远地区或者在高负载下或故障响应时提供额外的资源，那么就要特别小心。这些协议可能并无法保护你的核心性能、可用性、安全性、合规性或者甚至运行假设，所以当你在判断云计算服务的合适程度时，你可能需要考虑额外的联盟资源。
认识云计算的独特特点
从技术上来说，云计算不同于其他环境。如果无法如建议一样管理上述重点区域的差异，那么验证迁移特定应用至云计算的业务案例无效就是一个足够大的问题了。
如果是这样的话，请确定要记录问题和结果，以便于具有类似需求的应用可以在他们自己的云计算评估中给出“有罪推断”的结论。从长远来看，当技术条件不能得到保证时，迁移应用只会伤害云计算的声誉。
