业务系统迁移规划

㈠ 系统迁移如何进行

由于各种原因，越来越多的企业面临着ERP系统替换问题，而在系统更换前，现有ERP系统中有效数据的倒入，对ERP系统切换以及新系统正常运行有着重要影响。数据迁移稍有不慎，便会造成新系统不能正常启动，而迁移过多垃圾数据，将有可能使新ERP系统运行缓慢、甚至瘫痪。 因此，在进行新旧ERP系统替换过程中，企业CIO们除了要对新ERP系统进行项目需求、规划、实施，解决用户应用习惯以及开发相关接口外，还要认真考虑历史数据的导入问题。尤其是在现有ERP系统运行数年，积累了上百GB数据的情形下，CIO们更需要仔细衡量历史数据的有效性和对新系统的影响以及数据迁移的方式和方法。而这决不仅仅是异构数据库、不同存储设备之间数据迁移那么简单，它更像是对以前ERP数据以及ERP业务流程的重新审视和考核。 解决好ERP替换过程中的数据迁移问题不仅是新ERP系统成功上线的重要前提和保障，同时也是对已有ERP系统的一次全面总结和反思。 数据迁移切忌完整 对于传统数据迁移或数据库更替问题，企业CIO或数据库开发维护人员考虑得更多的是数据迁移的完整性和可靠性，但是对于ERP替换过程中的数据迁移而言，保持数据的完整性却是大忌。因为新旧ERP系统替换过程中，历史数据的迁移绝对不是孤立存在的。它虽然看似一个简单的数据库更替问题，但是，它涉及到从一个ERP系统到另一个ERP系统，从一个应用模式转向另一个应用模式的转变，这更多的是ERP本身的问题。 业内人士指出，对于同一厂商不同ERP产品替换，由于系统是在同一数据库基础上开发，而且存储逻辑或方法基本相同，所以旧系统中的数据利用率会很高，可以达到70%;而对于不同厂商的ERP产品替换，其旧数据利用率不超过10%，而且旧系统中数据利用得越多，新系统的负担就越大、性能越差、信息越不准确，这与简单的数据库迁移强调完整性有着本质区别。 而且，虽然用户选择的ERP厂商所提供ERP产品的模块可能相同，但是在相应实现方法、数据库记录的表结构以及ERP工作流程方面却是大相径庭，因此，ERP替换过程中的数据迁移不仅仅是数据的导入、导出问题，更是系统的更换、工作方式的改变。 所以，在进行ERP数据迁移时，企业CIO们不应简简单单地把ERP数据迁移看作是单一的数据库问题。企业CIO们首先应根据新ERP系统的需求设立项目目标，针对新的模块确定所要迁移的有效数据，其次才是ERP数据迁移过程中的技术实现问题。 虽然，数据迁移问题往往是在对新ERP系统进行项目需求、项目规划、项目实施、相应接口开发和人员培训之后，但是用户在与新ERP厂商签订合同、进行项目需求调研、规划时，就应该与相应ERP软件厂商共同探讨如何选择有效的历史数据以及如何对旧ERP系统中的历史数据进行导入等问题。 神州数码管理系统有限公司易飞服务部经理梁景茹建议，用户最好能请曾长期应用旧系统的人员参与到数据迁移小组中，以了解新旧系统的数据库和有关字段，避免数据字段对应错误。SAP咨询部中国区技术咨询经理赵旭民甚至建议，用户最好能请到原ERP系统的开发、设计人员来帮助自身共同做好数据的迁移工作。 对于ERP替换过程中的历史数据，并不是所有的数据都可以平滑过渡到新的ERP系统之中，尤其是对不同厂商的ERP系统替换，原有数据的利用率非常低。因此用户和实施顾问更应该关注数据的有效性，即搞清到底哪些数据对于新系统功能模块来说是有用的。 其次，新系统自动生成，是指在ERP系统切换后，通过新ERP系统的相关功能，或为此专门开发的配套程序生成所需要的数据。这种方法通常需要根据已经迁移到新系统中的数据来生成所需的信息。其实施的前提是，这些数据能够通过其它数据产生。 工具迁移与手工录入相结合 对于工具迁移而言，首先，各家ERP厂商多提供部分自主开发的迁移工具。北京时空公司相关负责人介绍，该公司就自主开发了专门解决数据迁移的“升级工具”。其可以从SQL Server 平台的数据源中抽取数据，完成转换和清洗，装载到各种系统里面，更复杂转换可以通过编写脚本或结合SQL语言的扩展来实现，并且该“升级工具”提供调试环境，可以极大地提高开发和调试抽取、转换程序的效率。 SAP针对SAP和非SAP系统之间替换的数据迁移工具分为两类：一类是专门针对少量数据迁移的SAP专有系统迁移工具(LSMW)，其可以非常方便将少量文本文件导入、导出;还有一类是针对大批量数据导入、导出的批导入工具，该软件类似于WORD里定义的宏概念。 另外，微软、ORACLE、IBM等数据库厂商也提供相应数据迁移工具，还有很多第三方公司开发的工具，如Ascential Software公司的DataStage。这些工具也可以从多个不同的业务系统，多个平台的数据源中抽取数据，完成转换和清洗，装载到各种系统里。 目前，通过工具迁移是最普遍的方式，但是用户在使用的时候经常遇到的情况是，原来系统中遇到的数字，并不是客户想要的准确数字。所以在通过工具迁移过程当中，派一至两个人检查，对新系统导入的准确性和有效性是有很大帮助的。 而在实际ERP数据迁移过程中，同时采用通过工具迁移和手工录入方式可能更为合理，即少量数据通过手工导入，大量数据通过工具迁移。比如对于仓库中上千种物料，通过工具迁移更为合适;而对于少量数据导入，如果还通过工具迁移，迁移的准确性肯定需要手工盘点来判断，如果之间出现误差，相关工作人员会再重新进行盘点或重新手工导入数据，其带来的繁琐程度大大超过直接录入。 数据检验也要靠人判断 在对旧ERP系统数据迁移完成后，用户还需要对迁移后的数据进行校验。而检验的指标应包括数据的准确性、有效性、一致性3部分。神州数码管理系统有限公司易飞服务部经理梁景茹指出，对于检验用户可以自己编制一些小软件，按业务流程和一些数据进行模拟，看最后的数据结果和报表是否正确。 但SAP咨询部中国区技术咨询经理赵旭民认为，除程序检测外，最好还要通过系统外的方法，即非计算机程序或软件程序来判断数据迁移的有效性和准确性。他说，“计算机程序没有智能行为，要判断数据的有效和准确一定要靠厂商中的实施顾问和客户中的关键用户。” 赵旭民认为，对于单一的数据，并没有办法判断数据的有效性或准确性，最后判断的根本还要回到原系统本身的运行状态和运行结果，如果原系统的业务流程或数据模式不合理的话，数据根本就不需要再进行迁移也就无需检验了。

㈡ 基金行业的IT 基础架构建设需要考虑哪些因素才能满足“云化要求”

云时代，基金行业云化除了灵活、高效、低成本之外，还必须满足稳定、高性能、高安全性等要素。Nutanix 超融合基础架构和企业云操作系统软件解决方案可以满足基金行业的“云化要求”。

基金行业可以在新的数据中心部署Nutanix 超融合基础架构和企业云操作系统软件解决方案，并将数据库管理、自动化办公和容灾等主要业务系统迁移至Nutanix平台上。

这能有效提高企业新数据中心的效率和生产力，同时减少了企业管理开销和存储空间。通过减少用于基础设施“维护”上的时间，提高IT系统整体性能和灵活性，基金行业才能够将更多的资源投入到新的业务模式开发之中，以适应新的挑战。

另外，Nutanix内置的容灾保护功能，可以通过显著提升容灾的恢复时间目标 （RTO） 和恢复点目标 （RPO），有效降低基金容灾的技术复杂程度，使得基金企业能够更加迅速地应对所有系统中断或故障，快速恢复系统正常

㈢ 超融合注意事项有哪些

选型？还是转型？抑或运营？姑且认为你是在问传统架构转型超融合的准备与注意事项吧。

超融合架构相对传统架构具有高性能、部署维护简单、易扩展等一系列优点，在使用模式、部署模式和维护模式都有较大区别，是传统 IT 架构向新型 IT 架构的升级。所以在决定转向超融合的时候，需要全面考虑以下几点：

1. 现状和需求分析

如上所述，超融合架构对 IT 基础架构的改进是全面的，但用户应该首先梳理当前的主要痛点有哪些，从而在产品选择时，进行更有针对性的评估。

2. 超融合产品的选型

通过深入了解各厂商产品的优劣势，然后进行 POC 测试验证，结合预算等方面进行超融合产品的选定。

3. 虚拟化平台的选择

因为超融合可以支持多种虚拟化平台，所以需要结合医院现使用的虚拟化平台进行考虑，是否继续选用现使用的虚拟化，还是采用其他虚拟化平台，因为关系到未来业务系统迁移的复杂程度。

4. 资源规划

如果是传统架构淘汰，更换为新的超融合基础架构，需要统计现有资源的使用情况，来规划能够承载现有业务系统的资源，另外再加一部分预留资源，给予故障后承载。

如果是新建数据中心或者是新上业务系统采用超融合，那么可以计算和存储资源均衡的方式进行构建，未来资源不足的情况下，可以直接扩充。

5. 业务系统的迁移规划

比如一些要求的停机时间窗口较小的场景（如医院），需要提前进行各业务系统分析，选择最佳的迁移方式，进行测试模拟，规划出准确的停机时间，以及回退方案。

6. 整体方案规划

不论是先试点还是一次性全部替代，最好能够有一个整体规划，包括备份、双活、网络、安全等等方面，能够采用超融合基础架构逐步地去完成。

整体来说，由于超融合架构比较简单，而且使用标准的 x86 服务器和以太网交换机，所以切换是比较容易的，对团队的要求也比较低，不需要太多的准备条件。

㈣ 企业上云服务过程中，应该注意哪些方面

当下是中小企业上云的最佳时机，借助云服务优化企业管理，缩小与大企业间的信息化鸿沟，市中小企业实现转折的一次契机！但是企业上云并非易事，要不得盲目。这里借用容商天下副总裁徐延政的一段话来给广大中小企业业主提个醒：企业上云之前，要做的第一步并不是选择云服务厂商，而是了解“企业上云”、企业自身结构及生产特点，并制定一份完整的上云规划。

1、信息收集

“企业上云”需要进行严谨细致的调研工作，需要收集硬件及网络环境信息、现有及将来可能增加的业务各类需求、系统配置信息、应用系统信息、数据风险等。

2、需求评估

从业务需求的角度分析各业务的目前现状、存在的问题、是否可以云化、业务未来的发展需求，定制对各个业务系统迁移的目标。

从系统的角度分析各系统的目前现状，包括了主机、存储、网络及安全，分析系统存在的问题，根据评估结果进行规划。

3、应用分析

应用分析是成功上云，降低业务停滞时间的关键。根据业务的负载、特性、复杂性、关联性分析确定并量化业务上云风险可能对业务造成的影响及损失，以确定业务上云的优先分批范围及上云策略。

4、风险分析

根据收集到的相关信息对目前系统进行业务上云的风险分析，分析各种潜在危险并针对可能发生的危险事件，采取相应措施。

5、上云策略

“企业上云”策略可遵循：统筹规划、分步实施、由易而难、由简单到复杂。一般顺序：（1）独立应用的系统，如邮件系统、合同系统；（2）应用堆叠的应用系统，如办公OA；（3）存在业务依赖的系统，如CRM、ERP、MES系统；

㈤ 机房搬迁详细方案

机房搬迁不仅仅是把机房的设备迁移到新机房那么简单，而是要求网络系统的迁移和集中存储系统的迁移必须安全平稳，不能过长时间影响生产应用。表面上就是几个IT 民工的搬运，但实际是一项目高度集中的体力与脑力的综合项目。现将一般机房搬迁步骤介绍如下：

1、新机房的准备

2、搬迁规划

3、系统的备份

4、设备文档的准备

5、搬迁设备标签

6、设备拆除、打包和运输

7、设备重新安装

8、测试及验收，

具体每个步骤的的工作应该怎样开展，都有详细的介绍。远瞻分享丨全面介绍机房搬迁需要做哪些步骤及实施方法？网页链接。希望能帮助到您。

㈥ 企业IT应用系统向云迁移如何估算成本

然而，向云迁移却牵扯着许多的问题，企业需要评估迁移需要的成本，以最合理的方式和成本进行迁移。 企业需要以下两个步骤： 1、评估需求 人们很容易低估将应用程序迁移到云环境的成本。例如，你可能会估计所需要的特定大小的服务器数量，你需要使用这些服务器多久以及你将使用的存储数量。这会帮助你粗略估算出云成本，对吧?但这并不能让你估算出你的应用程序在云环境的运营成本，这种计算并没有包含让应用程序在云中部署和运行的成本。为此，我们需要考虑云迁移的评估、设计和执行的成本。 本文中我们只考虑一种情况，即将现有应用程序从企业内部基础设施迁移到公共云供应商提供的基础设施即服务(IaaS)中。迁移应用程序到新平台(例如Google Engine或者Heroku平台)不属于本文讨论的范围。 这种系统可能使用相对较少的脚本，并且复制数据的方式并不需要与其他应用程序的协作，同时以相对简单的方式将生成的数据传递给用户，例如基本报告或者警报。而另外一方面则是跨越多个服务器，具有复杂工作负载，大量依赖网络，并在业务运作中发挥关键作用的应用程序。这些应用程序也可以迁移到云环境，到那时需要进行大量的规划和设计工作。一旦确定了需要迁移的应用程序，你就可以开始仔细研究功能要求和运作依赖性。 云迁移的部分成本来自于向你的应用程序提供配套服务的需要。很多应用程序需要身份验证，并依赖于企业内的LDAP或Active Directory服务。这些目录能够全部或者部分复制到云环境中吗?如果可以的话，你还需要考虑维护费用。如果不可以，你需要确定如何确保能从云端服务器访问这些目录。这可以像改变防火墙设置一样简单，或者还需要添加云端服务器到你的VPN，这会产生额外的运营成本。 你还需要评估初始数据加载的需要。你可能有相当多的数据要复制到云存储。除了直接成本外，还应该考虑复制数据到云端所需的时间。 几乎没有应用程序是完全孤立的孤岛。大多数应用程序依赖于其他系统的数据或者应用程序服务。你应该确定在云端运营的迁移应用程序是否能够访问这些服务(例如有没有防火墙限制)?另外，还要考虑到云端应用程序的网络流量是否有更长的延迟，这是否会对应用程序性能造成不利影响?最好尽可能早地确定这些依赖性，以避免需要重新修改设计和部署。 确定迁移到云端的应用程序是否具有故障恢复功能。应用程序服务器和数据库可以在故障转移集群中配置，可以用于执行阶段来简化迁移的最后步骤。 2、设计和执行云迁移 这可能需要一个了解应用程序、网络配置和存储架构的设计团队，因为他们将需要考虑访问控制、网络安全、数据传输和软件授权等问题。例如，如果配套服务将部署在主应用程序中，软件架构师将需要确定这些服务在哪里运行以及如何配置组件。设计团队将需要考虑数据该如何被复制到云端。小量数据可以通过网络复制到云环境，但是大量的数据应该通过磁盘复制到云端。 当在云环境服务器中运行商业应用程序时，请一定要确定是否需要获得软件许可。这对于在公共云广泛应用之前创建的旧应用程序而言，尤为重要。 执行应用程序云迁移 迁移应用程序到云环境的最后一个元素是实际执行。如果早期评估和设计阶段很全面的话，这个过程应该会有一些惊喜。在执行阶段，你需要与云服务供应商讨论管理要求，建立和部署机器映像，配置网络基础设施，并确保对企业内部应用程序中数据的最后修改都完整地复制到云应用程序数据存储中。 对应用程序新部署的测试需要确保应用程序进行了正确的配置，并且企业内部和云端数据库中的数据相同。 最后一步就是从企业内部系统切换到云端应用程序。这个步骤非常简单，只要关闭这一个，开启另一个即可，当然，还可能涉及更多操作，这取决于应用程序的类型。 将应用程序从企业环境迁移到云环境富有挑战性，因为应用程序可能存在复杂的依存关系和互操作性问题。评估当前的配置，制定一个迁移计划，并有条不紊地执行这个计划，可以帮助你减轻风险，并减少昂贵的迁移错误。