电商ERP实战1：新老系统切换之数据迁移
当时笔者公司ERP原本是外部公司研发的，由于业务发展无法继续支撑，这个也是很多大公司常见的操作了，业务体量发展到一定程度，一般都会把原有第三方解决方案，转换为自研系统进行业务支撑。
这个过程就涉及到新老系统切换了，原有系统的业务数据逻辑等，都需要迁移到新系统。
当时我主要是分为3大步进行的：迁移前置工作、正式数据迁移、收尾工作，接下来我们展开进行详细描述~
一、迁移前置工作
这部分工作一般会在系统正式迁移前，进行提前配置。包含迁移方案、迁移前置条件输出，需要按步骤、按顺序做好记录。
1. 迁移方案
系统切换和系统部署2大原则基本一致，蓝绿部署——一键全部切换新系统；金丝雀部署——少量用户先用新版本，逐步切换。对应到新老系统切换方案，就是一键全部切换新系统；或者并行分步切换，部分业务先切新系统，逐步将全部业务切换到新系统。
图中举例说明了2种方案，涉及隐私，部分数据做了隐藏~
每个方案需要结合业务逻辑，梳理写出具体细节步骤，优劣势，最后结合实际与CTO、研发经理进行综合方案评审。当时笔者所在供应链业务线还要配合电商业务，最终我们采用一键换新，一次性全部迁移的方案。当时切换业务逻辑：先条码、后订单、最后库存迁移。
结合实际业务逻辑，当年青涩的我总共输出了4版方案，这里思路基本就是：
- 一次性全部迁移：老系统发完全部货物，再进行全部条码、订单迁移。
- 一次性全部迁移：先把所有条码进行迁移、全部订单进行迁移、最后仓库实际库存迁移。
- 并行分布迁移：新订单新系统发货，老订单老系统发货，老订单全部发货完成后，进行条码、订单迁移，最后仓库实际库存迁移。
- 并行分布迁移：先把已经出库的条码进行迁移，后期每天对新发货的条码进行迁移。
这块方案输出也是产品的基操了，带着解决方案找领导，而不是问题抛给领导。嗯，不然的话，这个产品离滚蛋不远啦，管理层只是来协调资源👈做决策的~ 像项目管理里边的CCB，CCB只是决策机构，不是作业机构哈~
2. 迁移前置工作
方案梳理完成后，就可以进行前置工作的具体输出了，最近看高项的书，发现正式场合都是需要一份报告＋详细方案输出。
当时我负责业务线没有专职项目经理，所以这部分文档我都是实用为主，并没有报告、详细迁移方案区分，只输出了一份表格的详细迁移方案。
基本格式涵盖了：事项总括、具体事项、事项拆分、详细执行步骤、对应数据来源、具体执行人、负责人、执行时间、状态备注等，具体如下图：
至于那句老莫的方案，李翔方案什么的。年少勇啊，大家不要学习，表达过自己的想法就可以了，具体执行还是要以领导意志为准。所幸我很少遇到小心眼的领导，不然该被穿小鞋了哈哈哈~ 这块跟新系统实施上线要提前配置的工作差不多，软件配置、账号及权限维护、基础资料维护，商品维护等~
这块大家结合自己业务来就可以了，唯一想提醒的是：B端业务如果涉及到硬件设备，比如：PDA、工业一体机等，还需要记录具体台数，初始化配置步骤，在现场配置好每台设备。
一般涉及工作：软件安装、MAC地址、IP地址获取等，结合具体业务及功能来看。像我们开发了快捷键激光扫码功能，就需要PDA开发者项进行提前配置才可正常使用（具体因公司、业务线而议，有的公司这部分工作实施来做。不管哪个部门或角色做，这里都需要记录清楚，因为这是系统迁移不可绕开的工作），如果涉及打印机等的，基本也是类似，硬件最终上线都是需要有这些前置配置条件的~
每项业务执行时间、具体执行人都需要提前规划好，这里就可以充分牛马组内的开发了，让人人都有活干~
大家不要只会自己埋头干活，适当带动你组内开发参与到业务中去。
注意暂停业务的时间也需要在迁移计划中体现，不然这边系统迁移，那边业务人员哼哧哼哧给你造数据，这下好了系统迁移工作要无限期不能终止了~
其他提前维护的内容ERP的基操了，大家应该都懂。
二、正式数据迁移
具体业务数据的迁移，这部分都是需要结合实际业务系统逻辑顺序来做，一般顺序在输出方案时已经确认了。我们当时的方案，一次性全部迁移：先条码、后订单、最后库存迁移。
每项业务迁移都需要明确不同业务类型、状态数据如何迁移，并提前确定迁移方式。这里以条码业务来进行举例，思路都差不多。
迁移事项分类主要是：指导思想、前置条件、不同状态、不同业务类型、迁移需要留存字段等。
1. 迁移事项实例
① 指导思想用来让组内同事对此达成一致意见， 尽量避免大家理解不一致导致的问题。
② 当前业务的前置条件，条码迁移这里没有。以销售订单来举例，ERP商品需要先和电商平台商品进行关联，才可以进行订单数据迁移。这里和系统迁移前置工作不一样的点在于：此处是当前业务迁移前置动作，业务逻辑关联有前后顺序，并且只能在系统迁移过程中进行操作。ERP商品关联前，电商平台需要先进行迁移商品迁移并下推ERP，ERP才可以进行商品关联。而系统迁移前置工作，基本都可以在迁移前提前配置。
③ 当前业务贯穿业务类型较多、并且业务逻辑完全不一致的，需要写出每个业务类型的数据具体迁移方式。
④ 当前业务不同状态业务数据如何迁移，这里产品条码不同状态迁移方式、注意事项都不一样~ 订单的话，历史订单、在途订单等按照状态分别列出了，状态比较多的，需要按照平时订单状态机的输出依次列出
⑤ 迁移需要留存字段，一般会保留旧系统全部字段在数据库，前台展示可以考虑以新系统为准。
2. 迁移方式
迁移方式基本和数据新增的方式一样，一是直接接口、或数据库同步形式，这部分工作一般由开发同事直接进行；数据量较小的话，用表格导入的方式进行。至于手动新增，这部分就😀，除非10条以下数据，比如仓库、店铺配置哈哈哈~
三、收尾工作
正式数据迁移完成后，就是系统迁移的收尾工作啦。
收尾工作我按2部分进行的，一部分老系统接口等处理，还有财务数据处理。系统迁移完成后，老系统接口一定要关闭，不然数据混乱后期处理麻烦。笔者当时只是迁移了业务历史、在途和新数据，财务数据没有进行迁移，后期财务数据还需要再做一次迁移。
当然，这份迁移方案也不是一版定稿的，当时基本写了3、4版方案，再去跟技术主管、CTO反复讨论。除了详细迁移方案，还有日常软件上线的必不可少的操作手册、切换背景、后期业务规划等附件~
至于最终迁移效果还是不错的，很可惜没能亲身经历（当时笔者已经跳槽去新公司开展新业务了），不过留下的迁移方案还是非常详细的，基本涵盖迁移全部工作，文档在手，万事不怕~
本文更多的是从产品、业务角度进行的分享，技术角度考虑维度可能会不太一样。笔者也还在持续输出，成长~ 欢迎感兴趣、想要交流的评论区前排留言，一起进步成长~
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
