在新系统替换老系统或者系统升级的项目中，难免会存在数据迁移的工作，并且随着业务系统和数据结构的复杂性，数据迁移的难度越大。

这亦要求在项目实施的前期，根据客户的需求尽可能全面地考虑到各个方面，输出一份详细的数据迁移方案。

笔者将结合实际的项目工作经验，将一些在数据迁移中的感悟与各位分享共勉。

一、迁移准备

迁移前需要调研的内容包含：

1. 老系统存储数据所使用的数据库类型

例如oracle、mysql、sqlserver等，或某些厂商封装的数据库，因为每种数据库的数据存储结构形式存在差异，新老系统如果使用不同的数据库，难免需要处理。对于常见的数据库转换，市面上有开源工具可批量处理。

2. 老系统存储数据的形式

是否包含图片、表单、音视频等多媒体内容；是否包含附件，附件是否可在线预览；系统内的数据是否有相互关联关系等。这些将作为迁移完成后，验证迁移效果的重要用例。

3. 老系统的业务分类

无论是CRM系统、OA系统、工单系统，都会细分具体的业务类型，数据迁移的时候，必然需要按照其对应的业务分类迁移，因此需要调研其详细的业务分类。

二、迁移内容

迁移的内容主要是需要根据客户的需求，来确定数据的哪些内容是需要迁移的，将其总结为如下几个方面：

1. 数据字段对应

根据调研，输出一个数据字典对照表，新系统和老系统存储数据的每个字段会不一样，但实际上对于业务来说，功能用处是一样的；另外，如果老系统含有特有字段，而新系统没有，那么就需要在新系统开发对应的数据表进行存储。

下表是项目中一个KM系统的数据字典对照表：

2. 数据的关联关系

数据库里数据之间的相互关联，和其他外部系统数据的相互关联，这部分内容在迁移的时候，需要有相互关联的关系表，一般是以数据ID之间的关联关系来识别，因为ID是每条数据的唯一标识。

3. 其他附件数据

这部分内容可能是挂在某条数据下面，也就和数据之间进行了关联，亦需要关联关系表，同样以ID来识别。

另外，也可能是单独上传的附件，这部分可直接获取。附件会存储在文件服务器上，且业务系统一般会在内网部署，迁移时，可直接读取附件URL地址进行下载上传。需要注意的是，在URL链接里需要拼接附件名字，不然只有附件的ID。

三、迁移方式

数据如何从一个系统迁移到另一个系统？

目前所接触有两种方式：

一是离线的方式，导出本地文件，再导入；另一种是在线的方式，通过接口调用传参实现。

由于涉及到两个系统，意味着有第三方（而且往往是新系统的厂商要去替换老系统的厂商，也就是抢别人的饭碗），其第三方配合程度是不可控因素，两种迁移也就各有优缺点。

1. 离线方式

需客户协调老系统导出本地数据（可写SQL语句导出，也可写代码导出，根据业务内容决定），在导出之前，应根据迁移内容提供标准的数据模板，包括数据字典模板、关联关系模板、业务分类模板等。

优点：所有数据已导出，均在自己手中，实施迁移的时候，很多问题都在自己的可控范围。

缺点：

数据量过大时，导入导出时间长，且可能存在程序崩溃的风险（可考虑分批次）；在新老系统过度期间，需要多次执行导出导入。

2. 在线方式

接口传参需要第三方开发调用接口，同样在开发接口之前，需按照迁移内容提供标准的统一接口文档。同时，为不影响生产系统，也可能需过滤一些敏感信息，需建立中间库。

优点：在系统切换过度期间，可定时扫描调用接口传参（即增量数据）。

缺点：需要第三方开发，有工作量，且调试接口的时候，配合程度不可控。

四、实施迁移

实施迁移即数据整理与数据转换。数据整理就是将老系统数据整理为系统转换程序能够识别的数据；数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式。

同时这部分需要开发迁移代码，在代码完成后，特别注意的是需先进行小批量的迁移进行验证，无问题后，再进行大批量直至全量迁移。

五、迁移保障

为保障迁移的整个过程顺利和迁移数据完整准确性，过程中需要有如下几个方面可参考：

迁移的数据全量备份：防止系统崩溃，数据丢失；迁移过程打印日志：（如：迁移了多少数据，其中成功多少条，失败多少条）；迁移完的验证：a.如在迁移准备中第2点描述的数据的集中类型，需核对是否与老知识库对应，展现形式是否完整；b.抽检数据验证，可按照GB2828-81中的AQL值为标准进行抽检，抽检的方式可按照分层抽样（即每多少条数据抽检几条验证）。

结语

以上为个人在项目中关于数据迁移的一些感悟总结，最后将整个数据迁移的过程以一张图总结下：

作者：菜鸟店小二，AI产品经理

本文由 @菜鸟店小二 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。