2024 年春天，无锡一家本地母婴连锁找上门，门店分布在崇安寺、太湖广场和新区三个商圈，线上线下加起来有十来万会员。他们用了快十年的老会员系统卡在老式 POS 机里，积分规则改过三轮，数据库里堆着从 2014 年到 2023 年的全量记录。老板的诉求听起来简单：换套新的，把人和积分原样搬过去。我们这家小程序开发公司接下这单时，谁也没想到真正的工作量不在“搬”，而在“洗”。

背景：一家无锡母婴连锁的十年会员包袱

这家连锁最早在崇安寺商圈开第一家店，靠奶粉和纸尿裤的到店复购做起来。后来在太湖广场、新区又开了几家，还上了美团和社群团购。会员数据一直存在那套老 POS 配套的系统里，会员等级、积分、储值、优惠券四张表分散，积分规则在 2017 年、2019 年、2022 年各改过一次——每次都是运营口头通知，数据库里从没留过“规则生效快照”。等我们导出原始表时，光会员主表就有 9.3 万行。最后他们把单子交给我们这家小程序开发公司，图的就是无锡本地团队能上门跟财务逐笔对账。

原始诉求：先把人和积分原样搬过去

最初的需求文档只有两行：会员手机号、姓名、注册门店、当前等级原样导入新小程序；当前可用积分余额原样带入，不能让老客打开新小程序发现积分少了引发投诉。客户预期的工期是一周，报价也是按“数据搬运”估的。作为一家常做零售的小程序开发公司，我们之前也接过类似搬运单，所以当时真以为导个表、写个映射脚本就能交差。

中途变更：脏数据比账面多三倍

第一版映射跑完，对账就崩了。新系统按当前规则反算历史积分，和老系统给的“余额”对不上，差距接近三成。我们和客户的运营、财务坐下来一条条查，才看清包袱有多重：一是重复会员，同一人用不同手机号在三个商圈各注册一次，系统里并出 2.1 万个疑似重复档案；二是孤儿积分，有 9.7 万条积分流水挂着已注销的会员 ID；三是规则断层，2017 年那次改规则前攒的积分，老系统按旧比例算、新系统按新比例算，口径天然不一致；四是死积分，八千多条 2020 年前产生、早过有效期的积分仍显示为“可用”。中途客户又追加一条：线上团购和线下门店的积分要打通，同一人线上线下合并计。需求范围当场扩大了一圈。这也是很多小程序开发公司在接迁移单时最容易低估的一步。

最终数据：清理后留存反而稳了

我们这家小程序开发公司重新排了方案：先冻结当前积分规则版本并让业务方签字，再按该版本口径回算每一笔历史积分，对不上的挂到待核清单由财务逐笔确认。重复档案用手机号加微信 openid 双键去重，2.1 万疑似重复里核掉并合并 1.8 万；孤儿和过期积分直接置为失效并留审计日志；线上线下会员按 openid 归并到同一主体。整段迁移前后耗时 23 个工作日，清洗掉 9.7 万条脏积分流水，最终导入有效会员 7.2 万、有效积分余额 410 万分。上线后第一个月，老客回流核销率比迁移前高了 11 个百分点，因为积分终于“看得见、对得平”，客诉反而比预期少。

这一单留下的一条具体经验

如果只记一句话，就是：在导数据之前，一定先让业务方把“当前积分规则版本”冻结并签字，再用这个版本口径回算历史积分。这家连锁 2017 年那次改规则前攒的积分，老系统按旧比例、新系统按新比例，两套算法天然对不平，不先冻版本，历史积分永远差着一截，谁都解释不清。这条只针对“带积分的老会员系统迁移”这一件事，别的系统未必适用，也是小程序开发公司在做积分类迁移时最该先卡死的一条。