数据迁移是一个难度很大，并且业务方也不太理解的一种技术改造。这种驱动往往是技术团队内部根据业务发展的规模以及目前技术栈变革、业务支撑的压力负载等原因造成的。除了业务支撑不下去的理由之外，公司的业务团队是不会认可这种改造带来的风险，所以风险性极高。
我司前几年做过一次大规模的数据迁移，主要原因是要去oracle，然后用PostgreSQL（PG）来替代，前前后后持续来接近半年才把所有系统都换成了PG。先是找一些数据量不是很大或者非主流的系统来试验，在这个试验中，其实就发现了很多问题，比如有一些安全攻击带来的特殊字符，转成jsonb格式就出问题，还有新老数据库切换开关的设置，等等这些问题的暴露和解决给后面全面替换oracle打下了基础。
下面是我当时记录的一些要点，可供大家参考：
1. 数据要双写，在迁移前段，数据同时写入到老库和新库，并检查新库的落地情况，在迁移后期，服务都切到新库了，也尽量做到双写，确保能够回归，如果不能，那么就要有数据导入方案（从新库到老库）
2. 要做好开关，从逻辑层确保能够回滚
3. 对关联方或者外边系统提供的接口尽最大可能保存不变，否则极易引起生产问题
4. 新库上的sequence，尽量设置的比较大，防止中迁移阶段产生的数据和新库中的数据造成冲突
5. Schema尽量用之前的，不然影响比较大
6. 写一个工具来对比新老库之间的schema及数据变动
7. 要把一个库copy成临时库，不然不利于数据比对
8. 数据清洗，有BI的数据，安全攻击的数据等，这些会带入特殊字符，或者一些脏数据的处理，我们之前有些value从Oracle到PG，转成jsonb格式的时候，字段出现了问题，后来都改成了text格式
9. 记录一下迁移或者导库的时间，方便做回滚或者迁移的决策，特别是切回回滚方案的时候
10. 在看库的时候，有可能会看到一些注入攻击的记录，可以copy出来发给安全团队作为参考，从前端做拦截，确保不入库
11. 在测试环境的演练以及在灰度环境的试运行
12. 确定测试回归范围