历史数据迁移，产品经理需要提前想清楚的6件事

新系统上线，历史数据迁移常被忽视，却直接决定客户是否愿意迁移。本文从产品经理视角，拆解迁移范围、字段映射、业务衔接、验收标准与切换时点六大关键问题，帮你避开默认值填充、状态硬凑、自动动作误触发等常见坑，确保老业务在新系统中无缝延续。

新系统上线，很多时候容易忽略一个问题，那就是历史数据迁移。

做需求的时候，我们更容易关注新系统有什么功能、流程怎么走、页面怎么设计。

等到准备上线，要让客户开始用的时候才发现还有一批问题没考虑到。客户如果之前都是线下还好说，要是之前用的是别的系统，那老系统里的客户、订单、合同等等数据怎么办？没走完的审批流怎么继续？以前的记录要怎么查？

新系统虽然准备好了，老业务却没办法安排好去处，那人家就得掂量掂量要不要往你这里迁。

所以，历史数据迁移，很重要。

并且，它不只是把数据从一个地方搬到另一个地方。对产品经理来说，更重要的是想清楚，哪些业务需要延续，按什么规则延续，以及怎么确认它们真的连接上了。

这件事，可以沿着下面六个问题顺着看。

一、迁什么：不是所有数据都要搬，但都要有安排

所谓数据迁移，并不是单纯地迁多少张表，而是要先了解清楚“哪些业务需要哪些数据”。

老系统用了几年，里面难免什么都有。不能说这也舍不得，那也很重要，一股脑全都想搬过去。

搬家尚且要收拾一下来个断舍离，换系统也没必要把整套数据库原封不动复制一遍。

通常情况下，我们可以把历史数据分成三类。

第一类，必须迁入新系统。比如仍在服务的客户、尚未履约完成的合同、还没结清的订单，以及支撑这些业务所需的关联记录。这些数据不进来，后面的业务就进行不下去。

第二类，不再参与后续业务，但需要存档查询。比如已经结束的业务记录、历史审批意见，可以考虑归档，或者保留旧系统只读查询，不一定都要放进新系统。

第三类，经过确认可以不迁。比如测试数据、重复数据，以及按适用的留存要求确认可以清理的数据。这里的重点是“经过确认”，你不能单方面替客户做决定，看着没用就直接给人家删掉。

还有一个容易漏掉的地方，一条业务记录，往往不是单独存在的。

假设要迁一份还在履行中的合同，你只迁合同台账那部分不一定够，它关联的可能还有客户信息、附件、收付款记录、审批记录等等，哪些是后续履约需要用到的，也要一起确认一起迁移。

所以，迁移范围这个事儿，比想象中要复杂很多，是一个牵一发而动全身的工作，不能只简简单单列个迁移清单，还得说清楚，哪些进新系统，哪些归档，哪些留在旧系统；迁的时候，除了主表，还有哪些关联附表需要一起迁过去；不迁的数据以后去哪里查，谁能查，要保留多久。

不迁，不等于甩手不管。只要还有业务查询、留存和追溯的要求，就得给它安排好去处。

二、如何对应：名字一样，不代表是一个东西

范围定下来以后，接下来就要看，老数据进了新系统，到底应该变成什么样子。

不是简单地把“客户名称”对应上“客户名称”就结束了。字段名字相同，在两个业务系统里面代表的业务含义未必相同。

假设啊，只是举个例子，老系统的“已完成”，只代表订单已经发货；而新系统的“已完成”，却代表发货、签收、结算全部结束。直接带过去，页面上一般看不出什么问题，但实际情况和登记状态却已经产生了偏差。

产品经理需要和业务、研发一起，把这些规则说清楚。

第一，字段含义。同名字段是不是在说同一件事？金额是否含税？时间记录的是创建时间、提交时间，还是业务实际发生时间？这些差别，平时看着好像没啥问题，等到统计和对账的时候你就知道有多重要了。

第二，状态对应。老系统的每一种状态，在新系统里是什么环节？能不能完全对应上？不能直接对应的，是保留历史状态展示，还是满足一定条件后再转换？不能为了对应方便，就把本来不同的状态硬凑到一起吧。

第三，缺失和异常数据。老系统没有、新系统却要求必填的信息怎么办？责任人已经离职、组织已经失效、客户存在重复，又分别怎么处理？

第四，转换规则。哪些可以自动转换，哪些需要人工补充，哪些必须先拦截等确认后再处理？

尤其，不要为了让数据导入顺利，就直接把人家缺失的数据补一个默认值或者直接补成0，把未知的日期填成迁移当天，把所有失效责任人都改成某个管理员，导入可能蛮顺利的，后续人家要统计、提醒，甚至是责任判断的时候就抓瞎了。

不能用系统不报错来等同于业务的准确性。

每一条转换规则，都应该说得出业务依据，也要有明确的确认人。拿不准的，就列成待处理项，不要把不确定性悄悄地变成隐患。

三、怎么接：数据来了，业务逻辑怎么接上

历史数据里面，最需要关注的，通常是那些还没结束的业务。

已经完成的记录，重点可能是能查到、查得是准的；而进行中的业务，需要的是还能接着往下走。

假设一笔采购申请已经完成部门审批，正在等财务审批。迁到新系统以后，是从财务审批继续，还是需要重新发起？原来的审批意见和附件能不能查看？当前待办交给谁？如果原审批人已经离职，又该由谁接手？

这些问题不解答，只把状态迁成“审批中”，没有任何意义。

部分发货、分期付款、退款处理中、合同履约中等各类场景，也都有类似的问题。

因此，不能只是把状态迁过去了。迁过去了然后呢，下一步能不能操作，关联单据找不找得到，责任人有没有权限，剩余金额和数量对不对？都要有说法。

另外，还要防止历史数据误触发新系统的自动动作。

假设新系统创建订单后会自动通知客户，状态变为“已通过”后会自动生成下游单据，那么历史记录导入时，会不会也触发？会不会重复发消息、重复生成任务，甚至重复执行外部操作？

客户突然收到一条几年前订单的通知会是个什么反应？

所以，迁移记录和新建业务要区分开。哪些自动动作需要跳过，哪些因为后续业务需要而必须补执行，都要事先按业务确认，不能一刀切地用“全部执行”或者“全部不执行”来敷衍。

所以啊，判断新老系统的承接有没有做好，不能只看表面的几个字段，还要看后面的流程能不能正常往下走。

四、如何验证：导入成功，只是开始验收的条件

“数据已经导入，没有报错”，只能说明导入过程完成了，但这并不能说明迁移结果符合业务要求。

验收标准最好在迁移前就定下来。

至少要看四个方面。

第一，完整性，该来的有没有都来。约定范围内的记录是否齐全，附件、明细、审批记录和关联关系有没有遗漏？没有迁入的数据，能不能说明原因和后续安排？

第二，准确性，内容有没有变错。金额、日期、状态、责任人是否正确？转换后的字段是否符合约定规则？假设一笔订单只收了部分款，迁移后已收金额和待收金额是否仍然准确？

第三，一致性，相关数据能不能对上。合同金额与明细是否一致，订单与收付款记录是否匹配？新旧系统按相同口径统计，结果是否一致？如果有允许的差异，也要讲清楚差在哪里、为什么允许，而不是笼统地说一句“新旧口径不同”。

第四，可用性，迁过去以后能不能用。业务人员能不能搜索、查看、编辑和继续处理？附件能不能打开？权限是否正确？进行中的流程能不能走到下一步？

验证不能只看总数。总数一样，也可能是这边少了几条，那边多了几条，正好凑上了，这不是不可能的。也不能只抽几条最简单的记录随便翻一下，要覆盖不同状态、不同时间段，以及缺失信息、人员变更、部分完成等特殊情况。

最好让实际使用这些数据的业务人员参与确认。哪些检查必须全部通过，哪些允许按约定方式抽查，发现差异后怎么处理，都要提前明确。

验收也不是要求所有问题都一刀切地处理。哪些问题必须修复后才能上线，哪些可以在风险可控的前提下，带着明确的负责人、处理计划和完成时间上线，同样需要事先说清楚，不能什么都等到切换当天再去临时商量。

五、怎样切换：要有一个明确的切分时点

数据迁移需要时间，但业务有时候不一定能完全停下来等这个时间。

这中间可能会有个时间差。

第一次迁完以后，老系统可能又新增了一批订单，修改了一些客户信息，还有几笔审批往前走了几步。这些变化如果不能被发现和补上，新系统里的数据从上线第一天起就可能不是最新的。

所以，切换方案要讲清楚这么几件事儿。

什么时候开始迁，迁移窗口有多长；这段时间是否暂停业务，哪些操作需要冻结；首次迁移后新增和变更的数据怎么补齐；从哪个时点开始，新业务只能进入新系统；老系统何时停止写入，由谁通知、谁执行。

这些安排最终的落点都是一个明确的边界：什么时间之前以老系统为准，什么时间之后以新系统为准，中间的变化怎么接上。

边界不清，最容易出现的情况就是两边都在录、两边都在改。核对会越来越复杂，业务也很容易混乱掉。

除了切换步骤，还要有切换条件：哪些验证必须通过，哪些关键问题不能遗留，由谁决定正式切换。如果条件不满足，是延期、继续修复，还是启用事先约定的备用处理方式？

失败回退的方案也要想清楚。

切换之前，如果新系统还没有承接实际业务，回退主要是停止切换、恢复原来的业务安排。但切换之后，新系统可能已经产生了新的订单、审批和操作记录，甚至已经发生付款、发货等实际业务。

这时再切回老系统，新增业务怎么办？已经付款的记录怎么保留？已经发货的订单会不会再发一次？系统切回去不是什么复杂的事情，但你想让实际发生的事情也来个回退，那就很麻烦了。

因此，切换后的问题处理，要明确如何暂停新增写入、如何保留新系统产生的记录，哪些数据需要补录或核对，哪些业务要人工接管，以及如何避免已经执行的动作被重复执行。

回退很难让业务回到过去，而是需要在恢复系统的同时，不要再制造新的断档和重复。

六、如何收尾：迁完了，后面的流程需要继续走下去

切换当时的顺利，不代表后面就没有问题。

有些差异是有潜伏期的。只有到了实际查询、结算、对账，或者继续办理业务的时候才会暴露出来。

因此，上线以后要留出一段观察和处理得时间，不能迁完就万事大吉了。

这期间遗留的问题最好放到统一的清单里，说清楚影响什么业务、涉及哪些记录、临时怎么处理、谁负责修复、谁负责复核、什么时候完成。

如果修复需要修改历史数据，还应保留修改依据和处理记录。否则今天修好了，过几天回过来再查的时候发现解释不通，又得重新找人、翻记录、回忆现场。

旧系统的去留，也要在这个阶段落实。

旧系统是否转为只读，哪些人还能访问，历史查询保留多久，什么时候停止服务，停用前需要满足哪些业务、留存和追溯要求，都应当有明确安排。

这里要分清楚两件事：旧系统停止服务，不代表历史数据可以直接删除；历史数据需要留存，也不代表旧系统必须一直运行。如果改为归档查询，要确认归档后的内容、权限和追溯能力能满足要求。

不能因为新系统上线了，就直接关掉旧系统；也不能因为担心有遗漏，就让两个系统长期并行运作。前者可能让历史记录无处可查，后者则会不断制造新的差异，还会产生重复维护成本。

迁移工作真正收尾，应该有明确的完成条件：关键业务能够正常运转，遗留差异有结论或已按约定闭环，相关负责人完成确认，历史数据有可靠的查询去处，旧系统后续怎么处理也已经落实。

这整个过程中，产品经理不需要亲自编写迁移脚本，但需要把业务规则、验收标准和处理责任都跟业务理清楚。

从迁什么，到如何对应、怎么接续、如何验证、怎样切换、如何收尾，这六件事说到底都在解决同一个问题：历史数据迁移，不是简单地让数据在新系统的界面里呈现出来，而是让客户登上新系统以后，依然能查得清、接得上、走得下去。