互联网更新迭代频繁，为了给用户提供更优质的体验或者满足底层架构的升级，经常会遇到数据迁移的事情。如何做到高质、无缝的迁移，下面是具体的规范内容（主要针对db类型的数据迁移）。
一：评估
1、原系统的分析
(1) 了解原模块的逻辑和依赖，从涉及的页面、服务、接口入手。
了解之前业务，并以文档的形式整理出涉及到的范围，包含系统、服务、接口、页面。
(2)理清楚相关表的表结构，细化到每个字段的含义，建议表结构从生产环境导下来，保证无误。
(3)要有详细的技术文档，并能定制出多套方案。
2、人员
(1)根据以上分析评估需要参与的人员，做好分工和提前知会。
(2)技术方案评审要拉相关人员一起进行。
二：开发
(1)脚本或者涉及数据改动的逻辑加上日志。
(2)开发的过程中要考虑相关依赖和新旧版的兼容。
(3)异常情况的处理，主要有：
脚本中途异常停止；
漏掉数据；
导错数据。
(4)映射关系。
(5)上线后数据核对（对于复杂的数据，可以通过开发脚本来进行核对）。
(6)导数据脚本中查db的逻辑，要根据实际情况选择主库还是从库。
(7)针对数据量大的迁移，要考虑优化脚本的性能（如分析查询sql的执行效率，调接口的耗时，一次性执行多少条等等）。
三：测试
1、功能测试
(1)测试用例
2、性能测试（主要针对数据量比较大的迁移）
(1)根据需求提前查出线上的数据量，并结合测试的情况，评估出线上执行的大致时长。
3、准备上线工作
(1)迁移前定好上线的详细步骤和流程，并能估算出开始上线时间和迁移结束的时间，做到上线时有条不紊。线上步骤可以参考如下范例：
19:55 备份数据表
涉及到的表和字段有xxx（列完整）；
20:00 代码、服务上线
加配置，打开xxx文件，在xxx行后面加入xxx；
20:10 执行初始化脚本
此步骤大致将执行xxx分钟，执行命令为xxx；
如果脚本中断，则xxx。
(2)提前将上线时间和需要支持的事项以邮件和企业微信的形式通知相关人员。
三：迁移
按照上线步骤实施。
注意：每完成一个环节后，在工作群里进行通知，并跟进相关人员做好验证，无误后进入下个步骤。
四：迁移后测试
1核对数据
2测试功能