历史数据迁移，货品经理需要提前想清楚的6件事 | 人人都是货品经理

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

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

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

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

所以，历史数据迁移，很中心。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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