定义迁移策略和成功标准
定义迁移策略以识别云计算可能解决的现有应用程序的单个业务问题，并提供特定的业务理由从而证明云是正确的战略选择。
定义迁移策略
设置迁移策略对于任何转换计划都至关重要。迁移策略能激励整个组织，并使其凝聚为一体，同时提供一个明确的目标状态来指导他们的日常活动。（迁移策略的）愿景和使命可以集中在：
让移动办公人员更容易访问。
实现劳动力现代化。
提高安全性。
通过开发基于云的服务和托管功能来提高IT敏捷性。
提高可用性和响应能力。
更好地遵守法律法规。
通过战略合作伙伴集成，将组织转化为提供解决方案和功能的行业领头羊。
更大的可伸缩性。
快速开发、敏捷性、灵活性。
业务敏捷性、协作性和灵活性。
IT操作的单一流程集。
减少软件维护的工作量。
成本效益许可，随需应变供应，并把固定成本转变为可变成本。
更好地分析应用程序的使用情况。
迁移策略是将应用程序和基础架构主动迁移到云的过程中最关键的部分。迁移策略首先是为迁移做好准备并明确业务理由。高德纳公司发布了5个“R”策略，组织可以使用这些“R”策略来制定迁移策略：
重新托管（Re-host）：重新托管迁移策略也称为“直接迁移（lift and shift）”策略。这是一种向目标云的比对式应用迁移的策略。通常，某一组织出于业务用例的目的，希望将其应用程序快速迁移到云时，会选择这一策略。该策略可以轻而易举地在目标云基础架构上运行应用程序（对应用程序布局的改动最小）。组织选择重新托管策略的一个常见原因是为团队提供技能开发时间。该策略的另一项优势是可以自动执行迁移并编写脚本，自动化和脚本化迁移非常有效。需要进行存储迁移（无须转换）和某种程度的应用程序测试。示例包括简单到中等复杂程度的虚拟-虚拟（V2V）迁移和物理-虚拟（P2V）迁移。存储迁移将在本地直接访问存储设备（DASD）。操作系统迁移要求操作系统是红帽企业 Linux（RHEL）6以上，以及Windows Server 2008以上。
更换平台（Re-platform）：更换平台迁移策略也称为“拿起、思考、转移（lift, thinker, and shift）”策略。不改变系统的核心架构是该策略的一部分。但是，该策略通过快速的变更来降低管理和运营的开销，从而节省成本。该策略将在目标云上安装更高版本的操作系统和/或数据库。需要进行存储迁移（无须转换）。在迁移过程中，将在某种程度上更改应用程序或将应用程序重新安装到目标云上。强烈建议使用用户验收测试（UAT）进行测试。有机会实现重大基础架构升级，这将对合规性、监管和淘汰驱动程序方面产生积极影响。示例包括从Windows Server 2003/2008到Windows Server 2012的迁移。备选服务器是下面的Windows Server 2008、RHEL、Oracle 8到11以及所有数据库。也可以是新的应用程序版本，所有群集（Microsoft群集、DR等）和Microsoft SQL或相同技术的迁移。
重构（Re-factoring / Re-architecting）：实施重构迁移策略和重新编码需要对新功能进行投资。该过程存在潜在的重大营运冲击。这是一个极具挑战性的策略选择，但终将会给企业带来最大的收益。重构将涉及一个操作系统和/或数据库的移植。这将是对云服务产品的中间件和应用程序更改。迁移过程中将进行数据转换；数据库转换成MySQL、Aurora等。应用架构的更改也可能需要更高版本或移植。转换完成后，运用UAT进行检测非常必要。通常，当现有的应用程序环境无法提供特性、规模和性能时，组织会选择重新考虑或重新构建整个应用程序，以满足业务用例的需要，这有助于提高灵活性和发展业务前景。例如从AIX迁移到Linux操作系统，从Oracle迁移到SQL，从SQL迁移到Aurora，在迁移过程中摆脱中间件和IBM/HPE产品，执行自定义/复杂的应用程序更改。
停用（Re-tire）：组织在探索阶段运用此策略，因为他们发现15%-20%的资源根本没有使用，并且这些资源在完成云端迁移之后会被迅速丢弃。停用并根据需要存档数据。示例包括现有的项目范围退役，移除UNIX，AIX，SCO，DR集群主机，备用HA主机。
定义成功标准
定义成功标准首先是将正确的工作负载需求与有效的云选项相匹配。将工作负载放入正确模型时要考虑的成功标准包括：
数据合规性要求：数据从何处存储和访问，必须遵守哪些数据合规性要求？谁可以为每个数据区域提供服务？从何处提供服务？
锁定和许可：云提供商如何与应用提供商合作？在目前和将来，组织有何筹码来控制成本？如果应用或云提供商更改了其相互依赖的许可模式，它能以多快地速度调整路线？与基础架构相关的应用程序许可策略有哪些可用选项？
弹性和稳定性：每个工作负载需要如何在纵向和横向扩展？在评估云提供商时，请确保了解每个模型如何以增量的形式向上、向下和向外扩展。它能逐渐向外扩展吗？最小和最大增量是多少？云提供商让企业从规模经济、灵活性和可扩展性中获益。云提供商的基础架构是否可以灵活扩展从而适应不断增长的需求？
连接系统的延迟和性能要求：应用程序的延迟处理要求是什么？云提供商如何支持这一点？企业有什么样的绩效要求？云提供商是否提供架构帮助、部署指导和其他适用于云、应用程序基础架构及其他方面的最佳实践？
SLA要求：云提供商有何筹码可对任何中断、缺陷和不可用的服务负责？云提供商是否能够保护所提供的应用程序和服务？每个服务元素又如何呢？SLA是如何涵盖服务的？SLA结构和相关财务惩罚与所提供的基础架构和服务有多么紧密相关和灵活？
备份和灾难恢复：是否有经过验证和测试的灾难恢复计划？当前的备份计划是什么？怎么在云端实施备份计划呢？
财务战略：资本支出和运营支出偏好如何随时间变化？
本地（On-premise）或云提供商：谁来维护云环境？是本地IT团队还是托管云服务提供商（MSP）？本地IT团队是否具备维护云环境的专业知识？除了基础架构即服务（IaaS）和平台即服务（PaaS），云供应商将如何与其他服务集成？云提供商如何利用现有技术投资将成本降至最低？
云安全和合规性：在云中存储数据时，必须保护云基础架构。考虑组织的安全需求。行业特定的合规要求是什么？确保云提供商能够促进遵守行业义务。云提供商在认证和授权的安全性方面保证了什么？对安全功能的配置可以提供多少控制？
可用性：当前的基础架构是否已针对云进行了优化，或者MSP的基础架构是否已为工作负载做好了准备？云数据中心位置需要考虑什么?应用程序是否有数据位置限制，或者大多数用户是否居住在特定的地理区域?
任务
1.定义云迁移策略。
2.正确定义采购模式。
o需要什么能力？
组织产品和服务
公司电子邮件
虚拟桌面（VDI）
客户关系管理（CRM）
企业资源规划（ERP）
以及其他
o谁来管理业务运营？
合作伙伴管理
内部管理
o谁来管理技术操作？
产品合作伙伴管理
管理服务提供商（MSP）管理
内部管理
o应该如何实现解决方案组件？
软件即服务（SaaS）产品（Zendesk、贝宝、谷歌邮箱、微软Office 365、IBM Lotus Live、NetSuite）
PaaS产品 (Amazon Workspaces, 谷歌应用引擎, Windows Azure, Force.com)
PaaS集成(亚马逊红移，微软 SCCM)
IaaS产品（威睿、亚马逊、RackSpace hosting）
数据中心（计算、存储、网络、设施）
3.探索如何快速识别迁移前、迁移期间和迁移后需要特别注意或重新配置的堆栈元素。
4.了解如何客观、准确地监控应用程序和云基础架构，以确保一切都能稳定运行。
5.做好应用程序和云基础架构准备工作，以便大规模运行，并了解微服务和动态基础架构如何提供帮助。
6.详细说明并量化针对迁移的预期改进。
7.确定在迁移过程中仍然可以接受且不会有很大偏差的关键应用程序指标。
8.在迁移后，要指出错误率和错误类型没有发生显著变化，以确保没有将潜在的新错误引入系统。
9.了解要迁移的选定应用程序的预期用户体验。
提示和技巧
确保迁移项目按时、按预算进行。
为高度商品化的业务功能选择SaaS。
为标准业务功能选择PaaS。
为PaaS或SaaS不支持的工作负载选择IaaS。
o提高了IT基础架构的速度和敏捷性。
o可预测的运作成本。
o较低的总体拥有成本。
考虑迁移的成本、应用程序重新设计的潜在需求、寿命、性能和可用性、安全性和隐私要求、位置的选择以及其他潜在的监管要求。
对最终用户的响应时间应该在迁移前的某个阈值内。
稳态服务器利用率应在迁移前水平的特定阈值内。
与迁移前的水平相比，稳定状态下的基础架构成本应降低约定的最低水平。
服务错误率应该等于或低于迁移前的水平。
应用程序可用性水平和性能应该达到或超过迁移前的水平。
所有计划的性能改进都在新的基线中得到了验证。
所有负面的性能偏差都在计划的可接受范围内。
没有发现意外的特定迁移错误。
所有与计划偏离的剩余偏差都可以解释，并可以视之为是企业可以接受的。
活动输出
迁移策略文档
活动输出模板可通过以下网站获得：