Gartner研究主管Richard Watson指出，“当CIO在进行简单指令操作的时候，比如把一些应用迁移到云，会面临选择困惑，他们必须考虑一个企业的整体要求、评价标准和体系机构。”
许多技术架构师会有一个错误的认识，认为云迁移就是把旧有的系统迁移到云上。事实上，云迁移包括两部分内容：即数据迁移和应用程序迁移。计划、设计和执行，每一部分内容都要被评估，然后再集成。他们都是云迁移的内容，但每一个分析步骤和技能集成都不同。一定要重视数据迁移，把数据迁移看成与应用程序迁移同等重要。
值得注意的是，政府机构在这一点做得非常好，比如在国防部的云战略中，呼吁数据即服务(DaaS)，在数据迁移阶段，数据要和程序分离。情报机构在社区云迁移中采取的也是同样的策略。
数据和应用程序云迁移的目标，都是为了让业务变得更加灵活。一般来说，迁移之前要对数据源和应用程序进行分析，核实你的关键节点，设定并完成迁移目标。
关注你的数据源迁移，你需要检查你的应用程序，如何让它更好地存储你的数据。通常是三种方式：一个是关系数据库管理系统(通过SQL)，另外一个是没有SQL的数据存储，再一个是在系统上的文件。在数据评估之前，**要看你的数量处理或存储空间是否具备可扩展性。重点选择能提供上述三种存储方式的供应商。
数据迁移由三部分组成:对数据子系统的生存周期迁移、**数据迁移以及迁移后的应用程序整合。让我们慎重地对待每一个环节：
1、数据生存周期迁移
以你的软件生存周期(SDLC)为例，生存周期迁移不是一个阶段性的需求，存在于每一个阶段。
此外，开发阶段的需求会被迁移阶段取代。在《伟大的云迁移》这本书中有更详细地解释。现在，我只想说，数据迁移首先要评估云平台的类型、可伸缩性需求、数据类型和数据量。*后确定你的评估目标，*终实现你业务的可伸缩性和弹性化目标。
2、**数据迁移
把你**的数据迁移到云，还是一个质量管控的机会，元数据标签、数据表、数据血统或者其他的数据管理都得到了*佳实践。即使你的数据迁移工作做得很好，迁移到云以后没有任何改变。但实际上，你的企业数据库已经进行了一个整合和清理数据的过程。一些企业希望以云迁移为契机，集中管理他们的数据。
3、整合与迁移后的应用程序
一旦你的平台目标完成，你必须将你的数据存储子系统和你其余的应用程序迁移到云。这种集成取决于你用的是哪些系统。从应用程序迁移转移到数据迁移，可以真正达成你的业务目标，实现业务的伸缩性、弹性和计量计费管理。
如果你数据迁移的步骤错了，你付出的代价将是昂贵的，无论是数据迁移团队还是企业成本的付出都是不可估量的。相反，如果抓住了你的云迁移契机，实现企业级信息管理，可以帮助企业更有效地达成目标。
公安机关备案号：
