论文部分内容阅读
【摘要】 随着云计算的发展和各地电子政务基础设施建设，各地政务信息化正由分散化向集约化转变，独立部署的政务信息系统迁移至统一的电子政务基础设施是大势所趋，而系统迁移是一个复杂的过程，本文从迁移的角度出发按照政务信息系统迁移流程对各个环节工作进行梳理，分析问题并提出解决方案，对各地政务信息系统迁移有参考意义。
【关键词】 政务云 电子政务 数据迁移 系统改造
Abstract： With the development of cloud computing and the construction of local e-government infrastructure， the informatization of local government affairs is changing from decentralization to intensification. It is a general trend to move the independently deployed government information system to the unified e-government infrastructure， and the system migration is a complex process， In this paper， from the perspective of migration， according to the government information system migration process to sort out the work of each link， analyze the problems and propose solutions， which has reference significance for the government information system migration in various regions.
Keyword： Government cloud; E-Government; Data Migration; System Reform
引言：
经过多年信息化发展，我国政务云建设取得了显著成绩[1]。中央层面，国家电子政务外网、政务云平台已经为中央政务部门30余项业务系统部署提供了统一安全、按需使用的基础设施环境和及技术支撑服务。地方层面，我国九成省级行政区（不包括港澳台）和七成以上地级行政区已建或正建政务云[2]。为避免分散投资，重复建设，同时推动政务信息资源共享交换和业务协同[3]，各地政务云完成建设后，目前分散部署的政务信息系统必将迁移至政务云统一承载和集约化部署，因此一段时间内，政务信息系统迁移将称为各地电子政务重点工作之一。本文研究分析了政务信息系统迁移过程提供了各环节的解决方案，希望能为各地政务信息系统迁移工作提供参考。
一、迁移原则
政务信息系统迁移是一项非常复杂的工作，涉及部门较多，并存在一定安全风险，应参照以下原则开展[4]。
1.充分计划，有序组织。成立政务信息系统迁移工作领导小组负责统筹协调各相关部门工作开展，同时在工作开展之前要充分调研，做好迁移方案和应急措施，必要时请专家论证确保迁移工作安全有序开展。
2.风险评估，保障安全。政务信息系统迁移可能面临业务不能中断、环境不兼容、功能失灵、性能下降、改造难度大，迁移工期短等问题，从而增加系统迁移难度和风险。因此迁移之前一定要做好充分调研和风险评估并准备应对措施。
3.循序渐渐，先易后难。按照系统的业务要求，结合调研和风险评估结果，按照“先易后难，先外围后核心”的策略开展迁移工作。从业务连续性和耦合度要求低的业务系统入手逐步开展迁移工作。
4.迁移为主，兼顾整合。政务信息系统迁移的不是单纯的数据拷贝和设备搬迁，工作开展应该以迁移为契机，在业务迁移基础上，推进业务梳理和流程优化，从而促进政务信息系统的整合共享[5]。
二、迁移方案
2.1 迁移方法
第一种方法，基于IAAS搬迁。此种方法是利用政务云平台的基础设施资源进行迁移，基本不需要系统改造。此种方法分为两种情况，第一种情况是物理机设备搬迁，采用机柜空间的方式实现物理集中部署，而系统和数据随物理设备一并完成迁移。此种情况适用于硬件设备在状态良好且保修期内，可利旧使用避免资源浪费。第二种情况是硬件设备老旧不适合继续使用时，将采用政务云资源统一承载，而数据库、中间件等支撑软件将利旧使用，自行部署。此种情况新申请的资源配置（如：CPU、内存、存储空间等）原则上应与原设备配置相似[6]。
第二种方法，基于PAAS迁移。此种方法是使用政务云提供的应用程序开发及运行的环境部署系统，而不需要考虑底层基础设施细节。这种迁移方法较基于IAAS迁移更进一步但还不同于基于SAAS迁移，适用于专业性较强，无法使用SAAS调用的方式完成部署系统。此种方法需要一定量的系统改造，如中间件配置、数据库操作等代码调整。
第三种方法，基于SAAS迁移。此种方法充分利用政务云的软件服务进行迁移。此种方法在迁移过程中需重新分解政务信息系统，采用政务云平台封装好的SAAS服务实现系统原有的功能（如邮件、OA协同办公等）。此种方法系统改造量較大。
2.2 迁移流程
政务信息系统迁移是一项复杂的工作，应按计划有序开展，如果盲目进行，轻则造成迁移失败，重则影响业务造成经济损失。
结合以往经验，政务信息系统迁移工作至少应包含迁移准备、情况调研、迁移实施、迁移验收等工作环节。其工作流程如图1所示。 2.3 迁移调研
由迁移工作领导小组统筹协调各相关单位开展对政务信息系统设备、网络、数据、软件、业务等情况进行全面调研，如计算、存储、网络情况，存储的数据量、数据类型、数据增量、备份策略以及系统功能模块、架构、通信机制、相关系统依赖以及业务需求、运行需求等，并综合以上情况对待迁移系统进行分类，有针对性申请和分配资源，不同类型政务信息系统资源需求情况请见表1。
2.4 风险评估
2.4.1风险识别
政务信息系统迁移的各个环节均存在一定风险，常见的风险主要有业务风险、数据风险、网络风险以及安全风险等4类：
1.业务风险。系统迁移过程中经常会因为网络割接、系统配置、数据备份系统改在等工作暂停系统服务影响业务办理，因此必须充分考虑并提前做好应对策略，如选择休息日或下班时间迁移、准备备用系统以及提前通知停止办理业务等应对措施。
2.数据风险。系统迁移过程中通常出现数据丢失、数据不完整、数据不一致等情况。如部分系统迁移割接之前通常采用正式系统与测试系统并行运行一段时间的，待确认测试无误通过验收后正式割接，这种做法通常会使生产系统和测试系统产生数据差异，而影响实际业务。因此可以借助归档日志或者全数据导入的方式实现两套系统的“数据对表”以及数据备份恢复等方式保证数据安全。
3.网络风险。系统迁移必须要考虑网络风险，一是因计划、调研或测试不充分而造成的新网络环境不稳定，二是采用远程方式迁移大量数据时会在占用大量网络带宽造成网络不稳定。因此应该在充分调研、有序计划的同时采用增加临时线路、扩展已有链路带宽等方式降低网络防风险。
4.安全风险。系统准备迁移时一般会对数据进行拷贝、备份、恢复等操作，因此必须做好充分准备防范数据安全风险，特别是数据泄露安全风险。如验证数据操作人员的身份，记录操作日志，以及数据加密等方式保障数据安全。
2.4.2风险评估
结合系统迁移调研情况从兼容性、性能、改造难度、资源及工期风险等几个方面进行风险评估并出具报告。
1.兼容性评估。对支撑系统的政务云支撑软件兼容性进行评估，如所使用的云平台、虚拟机操作系统、云数据库的版本型号，网络拓扑结构以及硬件设备的参数配置等是否与待迁移的政务信息系统兼容。
2.性能评估。对系统使用的计算设备、存储设备、网络设备、支撑软件（如数据库、中间件等）性能以及系统数据存储量、数据处理技术、用户访问量等情况进行评估，判断其能否满足系统需求。
3.改造评估：根据系统的业务特点、技术路线、关联系统依赖以及政务云情况评估系统改造风险。
4.其他评估：针对系统迁移的方案计划、实施工期、使用资源、人员配置、部门协调等情况进行风险评估。
2.5 迁移实施
2.5.1 硬件迁移
物理设备的搬迁相对简单，但是也存在设备故障、网络故障、人员失误等风险因素。因此搬迁之前一定要统筹协调搬迁单位、使用用户及供货厂商人员做好设备状态检测确认等准备工作，同时要备份系统代码、配置文件及系统数据等文件，一旦出现紧急情况可以应急恢复回滚。针对易损设备要提前准备备件或者购买原厂质保。设备下架之前应该提前通知各相关单位做好准备，按顺序关机下架，严格按规范打包。
设备运输过程中要注意防震、防雨、防水处理。必要时可以采用关键节点冗余部署然后分批迁移等方式进行搬迁调试，降低设备迁移风险，确保关键节点安全稳定运行。
2.5.2 网络迁移
网络迁移一般涉及互联网出口、业务子网（专网）、内部局域网迁移、网络设备搬迁、IP地址规划、网络割接等工作。迁移之前要摸清楚网络情况，如目前IP地址如何规划，业务系统哪些功能依赖业务专网（子网）提供服务，使用哪些线路交换数据，使用哪些线路对外提供服务，网络中有哪些关键节点等情况，并针对这些情况做好网络迁移方案。在迁移实施过程中要统一指挥，将迁移方案、计划以及应急措施提前通知相关部门人员，一旦发生意外情况在规定时间内无法处置，能够及时启动回滚操作，保证业务能够及时恢复。
2.5.3 系统迁移
应用系统迁移和数据迁移相关性较高很难分开，很多情况下是一并完成的。根据业务需求不同，可以采用以下方法完成。
1.基于存储复制技术迁移。当原存储和目标存储为相同品牌即原和目标存储同构时，可以通过存储自身复制技术进行磁盘和逻辑单元数据复制完成系统和数据迁移。当同原存储和目标存储异构时，可以使用存储虚拟化技术统一管理不同类型的存储并实现异构存储数据复制和迁移[7]。此种数据复制技术适合短时间内大数据量迁移。
2.基于卷镜像技术迁移。如果原主机与目标主机操作系统一致，可以考虑使用卷镜像技术为原有逻辑卷增加新的物理映射，然后通過初始化机制完成不同存储之间的数据迁移。
3.基于数据库迁移。基于数据库的结构化数据迁移，在数据迁移过程中会经常用到[8]。当原数据库与目标数据库相同时（包括版本相同），可以通过在原设备上数据备份然后在目标设备上恢复数据的形式实现数据迁移，如：oracle数据库的exp/imp、expdb/impdb、rman，SQL Server数据库的backup/restore，MySQL的mysqldump，以及Sybase的数据库的dump/load命令等[9]。也可以使用数据库的数据复制工具完成数据迁移，如：使用ReplicationServer完成Sybase数据迁移、使用DataGuard完成Oracle数据迁移等。需要注意的是如果迁移双方数据库软件版本有差异时部分数据迁移可能会失败，如使用exp/imp、expdb/impdb完成不同版本Oracle数据库的LOB数据迁移就可能会出现问题[10]。当原数据库与目标数据库为不同产品时或者产品相同但是版本不同时，也可以考虑借助第三方迁移工具完成数据迁移，如Navicat、DataX等。但此种方法涉及系统改造较为复杂，经常会遇到如SQL语句差异，序列、触发器、存储过程、函数不兼容等问题，因此需要实时前做好充分的迁移方案。实际迁移过程中也可以根据实际数据及业务情况综合运用多种方法完成数据迁移。 4.基于云迁移技术迁移。基于云迁移技术的迁移是系统迁移上云常用的方法，根据迁移双方运行环境不同可以分为P2V迁移和V2V迁移。可以选择成熟的迁移工具，如：VMware Convertor等实现P2V、V2V迁移，此种方法被经常使用。为确保系统平稳过渡、顺利迁移，迁移之前还应充分考虑目标主机CPU、内存、存储空间等配置以及迁移时间、网络带宽等因素，并根据业务需要情况选择冷迁移或热迁移。
2.5.4 系统改造
在对待迁移系统充分调研的基础上，充分分析系统的功能要求、用户范围、基础环境特点以及系统改造风险等，有针对性的提出系统整体架构、业务应用、数据库的改造方案和系统改造测试方案。如可以考虑使用ETL、DATAX、数据总线等工具完成单位内部数据整合，通过工作流等技术完成内部工作流程再造，使用Web Service、SOA技术开发接口完成数据交流和访问控制，使用单点登陆等技术完成单位内部政务信息系统整合与身份认证等。
三、测试验收
3.1 测试
1.功能测试。系统迁移完成后应进行全面的系统功能测试确保服务可用性。功能测试应组织所有用户和开发运维单位分别从业务和技术角度按业务流程和系统开发文档对系统的所有功能模块及关联系统（如采集系统与数据分析系统）的相关功能进行测试。
2.性能测试。参考系统业务运行历史情况估算系统并发量等性能指标，搭建测试环境，使用LoadRunner、JMeter等压力测试工具进行性能测试出具测试报告，并根据测试结果对系统进行优化调优。
3.2 验收
系统完成迁移并通过测试后则进入试运行阶段，待试运行一段时间后，由迁移工作小组组织相关单位及人员开展系统迁移验收形成验收报告，并对整体迁移工作进行总结。
四、结束语
政务信息系统迁移是一项复杂而重要的工作，其过程复杂且涉及面较广，期间如何保证系统安全、平稳、快速的完成迁移至关重要。本文从实施者角度出发，按照政务信息系统迁移流程分析了迁移各环节需要做的工作、可以使用方法、可能出现的问题及应对措施等，对各地政务信息系统迁移有参考意义。
参 考 文 献
[1] 张琳琳，李倩.云计算支撑下的产业互联网发展[J].信息通信技术，2018，12（3）：13-17.
[2] 安晖，庄金鑫.“新基建”为云计算产业向更高水平发展带来新机遇[J].中国信息安全， 2020，（5）：48-50.
[3] 徐晓林，明承瀚，陈涛.数字政府环境下政务服务数据共享研究[J].行政论坛，2018，（1）：50-59.
[4] 郑炯，杨婷.政务信息系统云化迁移探讨[J].电子产品可靠性与环境试验，2018，36（s1）：191-195.
[5] 徐晓林，明承瀚，陳涛.数字政府环境下政务服务数据共享研究[J].行政论坛，2018，（1）：50-59.
[6] 张晓艳.云计算环境下大数据处理对电子商务发展的作用探析[J].无线互联科技，2016，（20） ：139-140.
[7] 王文飞，李长春.基于HPXP虚拟化技术的异构存储优化[J].科技风，2018，（13）：60-61.
[8] 钟志宏.从SQL SERVER到MYSQL的数据库迁移研究[J]. 电脑知识与技术，2019，15（14）：1-2.
[9] 徐灵均.数据迁移技术及其应用[D].南京：南京理工大学，2013.
[10] 彭展，李密，杨楠.基于XML数据迁移技术应用研究[J].现代计算机，2017（7）：79-82.
【关键词】 政务云 电子政务 数据迁移 系统改造
Abstract： With the development of cloud computing and the construction of local e-government infrastructure， the informatization of local government affairs is changing from decentralization to intensification. It is a general trend to move the independently deployed government information system to the unified e-government infrastructure， and the system migration is a complex process， In this paper， from the perspective of migration， according to the government information system migration process to sort out the work of each link， analyze the problems and propose solutions， which has reference significance for the government information system migration in various regions.
Keyword： Government cloud; E-Government; Data Migration; System Reform
引言：
经过多年信息化发展，我国政务云建设取得了显著成绩[1]。中央层面，国家电子政务外网、政务云平台已经为中央政务部门30余项业务系统部署提供了统一安全、按需使用的基础设施环境和及技术支撑服务。地方层面，我国九成省级行政区（不包括港澳台）和七成以上地级行政区已建或正建政务云[2]。为避免分散投资，重复建设，同时推动政务信息资源共享交换和业务协同[3]，各地政务云完成建设后，目前分散部署的政务信息系统必将迁移至政务云统一承载和集约化部署，因此一段时间内，政务信息系统迁移将称为各地电子政务重点工作之一。本文研究分析了政务信息系统迁移过程提供了各环节的解决方案，希望能为各地政务信息系统迁移工作提供参考。
一、迁移原则
政务信息系统迁移是一项非常复杂的工作，涉及部门较多，并存在一定安全风险，应参照以下原则开展[4]。
1.充分计划，有序组织。成立政务信息系统迁移工作领导小组负责统筹协调各相关部门工作开展，同时在工作开展之前要充分调研，做好迁移方案和应急措施，必要时请专家论证确保迁移工作安全有序开展。
2.风险评估，保障安全。政务信息系统迁移可能面临业务不能中断、环境不兼容、功能失灵、性能下降、改造难度大，迁移工期短等问题，从而增加系统迁移难度和风险。因此迁移之前一定要做好充分调研和风险评估并准备应对措施。
3.循序渐渐，先易后难。按照系统的业务要求，结合调研和风险评估结果，按照“先易后难，先外围后核心”的策略开展迁移工作。从业务连续性和耦合度要求低的业务系统入手逐步开展迁移工作。
4.迁移为主，兼顾整合。政务信息系统迁移的不是单纯的数据拷贝和设备搬迁，工作开展应该以迁移为契机，在业务迁移基础上，推进业务梳理和流程优化，从而促进政务信息系统的整合共享[5]。
二、迁移方案
2.1 迁移方法
第一种方法，基于IAAS搬迁。此种方法是利用政务云平台的基础设施资源进行迁移，基本不需要系统改造。此种方法分为两种情况，第一种情况是物理机设备搬迁，采用机柜空间的方式实现物理集中部署，而系统和数据随物理设备一并完成迁移。此种情况适用于硬件设备在状态良好且保修期内，可利旧使用避免资源浪费。第二种情况是硬件设备老旧不适合继续使用时，将采用政务云资源统一承载，而数据库、中间件等支撑软件将利旧使用，自行部署。此种情况新申请的资源配置（如：CPU、内存、存储空间等）原则上应与原设备配置相似[6]。
第二种方法，基于PAAS迁移。此种方法是使用政务云提供的应用程序开发及运行的环境部署系统，而不需要考虑底层基础设施细节。这种迁移方法较基于IAAS迁移更进一步但还不同于基于SAAS迁移，适用于专业性较强，无法使用SAAS调用的方式完成部署系统。此种方法需要一定量的系统改造，如中间件配置、数据库操作等代码调整。
第三种方法，基于SAAS迁移。此种方法充分利用政务云的软件服务进行迁移。此种方法在迁移过程中需重新分解政务信息系统，采用政务云平台封装好的SAAS服务实现系统原有的功能（如邮件、OA协同办公等）。此种方法系统改造量較大。
2.2 迁移流程
政务信息系统迁移是一项复杂的工作，应按计划有序开展，如果盲目进行，轻则造成迁移失败，重则影响业务造成经济损失。
结合以往经验，政务信息系统迁移工作至少应包含迁移准备、情况调研、迁移实施、迁移验收等工作环节。其工作流程如图1所示。 2.3 迁移调研
由迁移工作领导小组统筹协调各相关单位开展对政务信息系统设备、网络、数据、软件、业务等情况进行全面调研，如计算、存储、网络情况，存储的数据量、数据类型、数据增量、备份策略以及系统功能模块、架构、通信机制、相关系统依赖以及业务需求、运行需求等，并综合以上情况对待迁移系统进行分类，有针对性申请和分配资源，不同类型政务信息系统资源需求情况请见表1。
2.4 风险评估
2.4.1风险识别
政务信息系统迁移的各个环节均存在一定风险，常见的风险主要有业务风险、数据风险、网络风险以及安全风险等4类：
1.业务风险。系统迁移过程中经常会因为网络割接、系统配置、数据备份系统改在等工作暂停系统服务影响业务办理，因此必须充分考虑并提前做好应对策略，如选择休息日或下班时间迁移、准备备用系统以及提前通知停止办理业务等应对措施。
2.数据风险。系统迁移过程中通常出现数据丢失、数据不完整、数据不一致等情况。如部分系统迁移割接之前通常采用正式系统与测试系统并行运行一段时间的，待确认测试无误通过验收后正式割接，这种做法通常会使生产系统和测试系统产生数据差异，而影响实际业务。因此可以借助归档日志或者全数据导入的方式实现两套系统的“数据对表”以及数据备份恢复等方式保证数据安全。
3.网络风险。系统迁移必须要考虑网络风险，一是因计划、调研或测试不充分而造成的新网络环境不稳定，二是采用远程方式迁移大量数据时会在占用大量网络带宽造成网络不稳定。因此应该在充分调研、有序计划的同时采用增加临时线路、扩展已有链路带宽等方式降低网络防风险。
4.安全风险。系统准备迁移时一般会对数据进行拷贝、备份、恢复等操作，因此必须做好充分准备防范数据安全风险，特别是数据泄露安全风险。如验证数据操作人员的身份，记录操作日志，以及数据加密等方式保障数据安全。
2.4.2风险评估
结合系统迁移调研情况从兼容性、性能、改造难度、资源及工期风险等几个方面进行风险评估并出具报告。
1.兼容性评估。对支撑系统的政务云支撑软件兼容性进行评估，如所使用的云平台、虚拟机操作系统、云数据库的版本型号，网络拓扑结构以及硬件设备的参数配置等是否与待迁移的政务信息系统兼容。
2.性能评估。对系统使用的计算设备、存储设备、网络设备、支撑软件（如数据库、中间件等）性能以及系统数据存储量、数据处理技术、用户访问量等情况进行评估，判断其能否满足系统需求。
3.改造评估：根据系统的业务特点、技术路线、关联系统依赖以及政务云情况评估系统改造风险。
4.其他评估：针对系统迁移的方案计划、实施工期、使用资源、人员配置、部门协调等情况进行风险评估。
2.5 迁移实施
2.5.1 硬件迁移
物理设备的搬迁相对简单，但是也存在设备故障、网络故障、人员失误等风险因素。因此搬迁之前一定要统筹协调搬迁单位、使用用户及供货厂商人员做好设备状态检测确认等准备工作，同时要备份系统代码、配置文件及系统数据等文件，一旦出现紧急情况可以应急恢复回滚。针对易损设备要提前准备备件或者购买原厂质保。设备下架之前应该提前通知各相关单位做好准备，按顺序关机下架，严格按规范打包。
设备运输过程中要注意防震、防雨、防水处理。必要时可以采用关键节点冗余部署然后分批迁移等方式进行搬迁调试，降低设备迁移风险，确保关键节点安全稳定运行。
2.5.2 网络迁移
网络迁移一般涉及互联网出口、业务子网（专网）、内部局域网迁移、网络设备搬迁、IP地址规划、网络割接等工作。迁移之前要摸清楚网络情况，如目前IP地址如何规划，业务系统哪些功能依赖业务专网（子网）提供服务，使用哪些线路交换数据，使用哪些线路对外提供服务，网络中有哪些关键节点等情况，并针对这些情况做好网络迁移方案。在迁移实施过程中要统一指挥，将迁移方案、计划以及应急措施提前通知相关部门人员，一旦发生意外情况在规定时间内无法处置，能够及时启动回滚操作，保证业务能够及时恢复。
2.5.3 系统迁移
应用系统迁移和数据迁移相关性较高很难分开，很多情况下是一并完成的。根据业务需求不同，可以采用以下方法完成。
1.基于存储复制技术迁移。当原存储和目标存储为相同品牌即原和目标存储同构时，可以通过存储自身复制技术进行磁盘和逻辑单元数据复制完成系统和数据迁移。当同原存储和目标存储异构时，可以使用存储虚拟化技术统一管理不同类型的存储并实现异构存储数据复制和迁移[7]。此种数据复制技术适合短时间内大数据量迁移。
2.基于卷镜像技术迁移。如果原主机与目标主机操作系统一致，可以考虑使用卷镜像技术为原有逻辑卷增加新的物理映射，然后通過初始化机制完成不同存储之间的数据迁移。
3.基于数据库迁移。基于数据库的结构化数据迁移，在数据迁移过程中会经常用到[8]。当原数据库与目标数据库相同时（包括版本相同），可以通过在原设备上数据备份然后在目标设备上恢复数据的形式实现数据迁移，如：oracle数据库的exp/imp、expdb/impdb、rman，SQL Server数据库的backup/restore，MySQL的mysqldump，以及Sybase的数据库的dump/load命令等[9]。也可以使用数据库的数据复制工具完成数据迁移，如：使用ReplicationServer完成Sybase数据迁移、使用DataGuard完成Oracle数据迁移等。需要注意的是如果迁移双方数据库软件版本有差异时部分数据迁移可能会失败，如使用exp/imp、expdb/impdb完成不同版本Oracle数据库的LOB数据迁移就可能会出现问题[10]。当原数据库与目标数据库为不同产品时或者产品相同但是版本不同时，也可以考虑借助第三方迁移工具完成数据迁移，如Navicat、DataX等。但此种方法涉及系统改造较为复杂，经常会遇到如SQL语句差异，序列、触发器、存储过程、函数不兼容等问题，因此需要实时前做好充分的迁移方案。实际迁移过程中也可以根据实际数据及业务情况综合运用多种方法完成数据迁移。 4.基于云迁移技术迁移。基于云迁移技术的迁移是系统迁移上云常用的方法，根据迁移双方运行环境不同可以分为P2V迁移和V2V迁移。可以选择成熟的迁移工具，如：VMware Convertor等实现P2V、V2V迁移，此种方法被经常使用。为确保系统平稳过渡、顺利迁移，迁移之前还应充分考虑目标主机CPU、内存、存储空间等配置以及迁移时间、网络带宽等因素，并根据业务需要情况选择冷迁移或热迁移。
2.5.4 系统改造
在对待迁移系统充分调研的基础上，充分分析系统的功能要求、用户范围、基础环境特点以及系统改造风险等，有针对性的提出系统整体架构、业务应用、数据库的改造方案和系统改造测试方案。如可以考虑使用ETL、DATAX、数据总线等工具完成单位内部数据整合，通过工作流等技术完成内部工作流程再造，使用Web Service、SOA技术开发接口完成数据交流和访问控制，使用单点登陆等技术完成单位内部政务信息系统整合与身份认证等。
三、测试验收
3.1 测试
1.功能测试。系统迁移完成后应进行全面的系统功能测试确保服务可用性。功能测试应组织所有用户和开发运维单位分别从业务和技术角度按业务流程和系统开发文档对系统的所有功能模块及关联系统（如采集系统与数据分析系统）的相关功能进行测试。
2.性能测试。参考系统业务运行历史情况估算系统并发量等性能指标，搭建测试环境，使用LoadRunner、JMeter等压力测试工具进行性能测试出具测试报告，并根据测试结果对系统进行优化调优。
3.2 验收
系统完成迁移并通过测试后则进入试运行阶段，待试运行一段时间后，由迁移工作小组组织相关单位及人员开展系统迁移验收形成验收报告，并对整体迁移工作进行总结。
四、结束语
政务信息系统迁移是一项复杂而重要的工作，其过程复杂且涉及面较广，期间如何保证系统安全、平稳、快速的完成迁移至关重要。本文从实施者角度出发，按照政务信息系统迁移流程分析了迁移各环节需要做的工作、可以使用方法、可能出现的问题及应对措施等，对各地政务信息系统迁移有参考意义。
参 考 文 献
[1] 张琳琳，李倩.云计算支撑下的产业互联网发展[J].信息通信技术，2018，12（3）：13-17.
[2] 安晖，庄金鑫.“新基建”为云计算产业向更高水平发展带来新机遇[J].中国信息安全， 2020，（5）：48-50.
[3] 徐晓林，明承瀚，陈涛.数字政府环境下政务服务数据共享研究[J].行政论坛，2018，（1）：50-59.
[4] 郑炯，杨婷.政务信息系统云化迁移探讨[J].电子产品可靠性与环境试验，2018，36（s1）：191-195.
[5] 徐晓林，明承瀚，陳涛.数字政府环境下政务服务数据共享研究[J].行政论坛，2018，（1）：50-59.
[6] 张晓艳.云计算环境下大数据处理对电子商务发展的作用探析[J].无线互联科技，2016，（20） ：139-140.
[7] 王文飞，李长春.基于HPXP虚拟化技术的异构存储优化[J].科技风，2018，（13）：60-61.
[8] 钟志宏.从SQL SERVER到MYSQL的数据库迁移研究[J]. 电脑知识与技术，2019，15（14）：1-2.
[9] 徐灵均.数据迁移技术及其应用[D].南京：南京理工大学，2013.
[10] 彭展，李密，杨楠.基于XML数据迁移技术应用研究[J].现代计算机，2017（7）：79-82.