在企业里，许多上云迁移成功的案例，都是先从一些较为简单的应用开始迁移，然后再一步步把更多的应用和数据迁移到云，不可能同时把所有的应用都一下迁移过去。

对于要迁移上云的应用和数据，制定一份详细的计划与时间表是必要的，迁移是一个很复杂的过程，可以先从最简单的应用开始，然后再考虑复杂的、关联度比较高的业务，一些个性化的企业应用等。

     如上图所示，描述了企业稳步进行云迁移的一般步骤，迁移是一个系统工程，迁移过快往往将导致成本的急剧上升、工期延期甚至失败。

    上云迁移的过程，我们可以将其细化分为五个步骤。注意这里主要的场景是企业私有云，其总结的步骤也是适用于私有云的，对于迁移到公有云并不是很适用。下面我们重点来看，迁移上云的五个阶段步骤。

    企业传统的IT业务应用一般都构建在物理服务器和存储设备上，当开始进行云迁移时，一般会采用标准化技术，对以往的服务器及存储资源进行整合。对已存在的老的要上云的业务进行迁移评估，并根据数据中心的资源情况来制定详细的解决方案是比较重要的;如果是新的应用系统，则分配相应的资源，直接部署在云计算环境中即可。任何要上云的业务，对其实现难度的评估是对应用系统进行云化或改造风险与收益评估的重要手段. 整个业务系统的云化分析过程需要从包括硬件支撑环境改造、操作系统平台变更、平台软件绑定分析、IP地址依赖性消除、 API重构、模块化改造、标准化改造、外部依赖条件等在内的多个层面和维度进行，准确评估业务信息系统云化改造的相关难点与痛点，才能对信息系统云化改造有充分的认识和准备。

     当然，虚拟化和架构设计也是上云业务系统进行现代化改造的一部分。上云首先离不开架构设计，因为业务终究要被云化，不管其迁移的过程长短，企业通常都会使用虚拟服务器来代替物理的服务器，使用存储资源池来统一后端的存储。为了实现对异构存储设备的管理，往往还会进行存储的虚拟化和分布式改造。当然在这一步，有可能还会涉及业务改造的咨询和方案的论证优化，还必须开始使用脚本或者自动化的安装工具来适当减少工作量。

    虚拟化是上云的第一步，接下来迁移的第二步，是部署一套私有的云管理平台。那么是采购或是自建及部署云服务呢?

     从云平台的成本和价值来看。VMWARE是商业软件，其成熟度和稳定性经受了大量实际环境的考验，但使用成本高，体现在其授权费用和服务费用上。相对VMware 的昂贵价格，OpenStack免费、开放的优势还是很明显的。VMware高投入带来的功能，OpenStack大部分可以免费提供给客户。那么是 OpenStack还是VMware更有价值，这个问题并没有很清晰的答案，并且答案也取决于企业实际部署的规模。虽然OpenStack是免费使用的， 但是它需要有专业的开发人员和此领域的专家才行，并且需要很多架构和搭建方面的工作，因为它支持很多部署场景，并且安装过程都不尽相同。VMware则需要花费一些经费购买授权和服务，并且相对来说更加容易安装和运行，另外Vmware的学习成本更低一些，运维可以很容易上手。

     总得来说，基于以上的分析，大型企业采购使用VMWARE平台则更稳定和可靠。而OpenStack则入门门槛较高，如果企业没有足够的技术能力储备则无法解决大面积部署OPENSTACK所遇到的问题和坑。

    构建一个私有云，需要详细的规划设计以及实施，很多时候面临资源整合也包括管理理念的整合和融入。在这一步也可以采购或使用一些公有云服务，例如一个或多个SAAS应用、开发测试服务、云存储等。混合云融合了公有云和私有云，是近年来云计算的主要模式和发展方向。我们知道私有云主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源随需扩展，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。

    云的基础设施及服务部署完成之后，需要开始对现有的业务应用服务进行统一化或者升级。如前面所说，这一步可以先把一些较为简单的应用迁移到云中，然后再逐步解决剩下的那些复杂应用。

应用迁移的过程不是简单的点几个按钮就大功告成，我们需要从云平台的环境特点出发，对自身的产品做一定的适应调整。比如，是否支持静默安装、磁盘空间的使用、参数设置应该由API 或 CLI 来完成、跟踪和日志信息通过脚本命令还是平台统一收集等。

    数据迁移对于一个业务应用来说是最重要的，直接关系到业务上云的成败。数据迁移会将业务系统中很少使用或不用的文件移到辅助存储系统(如磁带或光盘)上，而把热点常用的数据迁移到优质存储(如SSD或闪存阵列)上，有点像分级存储管理吧。通常为了保证数据的安全性和完整性，我们业务的迁移工作一般会与备份策略相结合,并且对重要数据进行重点备份。还有的业务系统上云后去O，把Oracle替换成Mysql,那么就会涉及到SQL语法的适配、数据的转换、新老系统的交互、应用的改造甚至重构等，挑战比较大，这些都需要在迁移阶段有充分的考虑。

      数据迁移的实现可以分为3个阶段：数据迁移前的准备、数据迁移的实施和数据迁移后的测试校验。由于数据迁移的特点，大量的工作都需要在准备阶段完成，充分而周到的准备工作是完成数据迁移的主要基础。具体而言，要进行待迁移数据源的详细说明(包括数据的存储方式、数据量、数据的时间跨度);建立新旧系统数据库的数据字典;对旧系统的历史数据进行质量分析，新旧系统数据结构的差异分析;新旧系统代码数据的差异分析;建立新老系统数据库表的映射关系，对无法映射字段的处理方法;开发、部属ETL工具，编写数据转换的测试计划和校验程序;制定数据转换的应急措施。其中，数据迁移的实施是实现数据迁移的3个阶段中最重要的环节。它要求制定数据转换的详细实施步骤流程;准备数据迁移环境;业务上的准备，结束未处理完的业务事项，或将其告一段落;对数据迁移涉及的技术都得到测试;最后实施数据迁移。

      数据迁移后的测试校验是对迁移工作的检查，数据测试校验的结果是判断一个业务系统能否正式启用的重要依据。可以通过质量检查工具或编写检查程序进行数据校验，通过试运行新系统的功能模块，特别是查询、报表功能，检查数据的准确性。

     当然为了保障数据迁移的质量和效率，也离不开好的迁移工具。商业和开源的产品各自有不同的特点，选择时还要根据具体情况进行分析。纵观目前国内一些大型项目，在数据迁移时多是采用相对成熟的ETL产品，其实也可以看到这些项目的一些共同点，主要包括：迁移时有大量的历史数据、允许的宕机时间很短、面对大量的客户或用户、存在第三方系统接入、一旦失败所产生的影响面将很广。

     目前，许多数据库厂商也都提供相应的数据抽取工具，如Informix的InfoMover、Microsoft SQLServer的DTS和0raele的Oracle Warehouse Builder等。这些工具在一定范围内解决了数据的提取和转换，但这些工具基本都不能自动完成数据的抽取，用户还需利用这些工具编写适当的转换程序来提高效率。

     再有就是企业里的复杂应用由于业务耦合度高，对传统架构依赖性强，一般都需要大量的改造开发，比如你想替换特定的中间件和数据库及商业套装软件，可能需要几年的时间来完成该步骤。由于时间周期比较长，不可控的风险太多，因此需要谨慎地对现有系统从投资回报以及可行性方面进行详细迁移评估。

     在企业里，当大量业务应用都迁移上云后，使用云管理平台进行业务系统的自动化配置、审批、服务交付、升级改造及监控就变得比较重要了。不断地对现有IT流程进行自动化改造至关重要，我们希望尽量的把每一个业务上云的流程都自动化，从虚拟机及应用的线上资源预订到其交付，这样可以大大缩短部署时间、减少人工成本，提高系统配置的准确性及一致性。虽然在标准化统一化的阶段就已经开始进行基本的自动化，但到了全面自动化阶段则需要把大量的脚本、应用安装程序、自动化工具引入到一个流程编排系统，在该系统中可以使用云管理平台进行服务及工作流的设计。

     传统业务上云一般需要经过资源供给、交付服务、运维及安全流程等的若干环节审批，因为在云服务完成及上线之前，很多这些流程都需要进行改造，自动化交付则需要IT安全人员对虚拟机模板、软件化网络、存储资源、操作系统、应用平台等预先进行授权或批准。该阶段还需要考虑冗余性及伸缩性，包括服务器、虚拟机、应用及云管理平台在数据中心部分或者完全失效的情况下的持续运行能力。安全操作及IT治理在该阶段也必须完全建立，最终这五个步骤的云迁移计划将把公司带到一个全面云运维的状态。

     业务上云是个复杂系统的工程，不论是老的应用还是构建新的应用，迁云团队都需要仔细考虑成本与运营是否与平台模式匹配。从现阶段来看，应用分阶段迁移可能是唯一的选择。目前一些公司已经成功的用这种分阶段方法改变了他们传统的应用，并使风险最小化的同时受益于云计算，这也许是未来一段时间云化的主题。