把会员数据交给新服务商之前，先写清这份交接单

换服务商的项目里，最容易出问题的环节往往不是导入，而是交接。旧系统导出一张表，发到群里，新服务商回复“收到了”。上线之后才发现：行数对不上，余额口径不同，重复账号没人认领，备注里还混着手机号和订单号。数据传过去了，但没人说得清“这份数据到底是什么”。

交接不是一次文件传输，而是一次交付。交付需要有说明书、样本、验收标准，以及出了问题找谁。

一、交接单里至少要有五样东西

字段说明、口径对照、样本文件、验收标准、责任人。缺任何一项，对方就只能猜。猜出来的结果不会马上报错，通常在上线后以“会员说积分不对”的形式出现。

这五样不需要写成几十页的文档。一页纸的表格加一份样本，往往比一份没人看的说明书有效。

二、字段说明：让不熟悉系统的人也能看懂

每个字段至少写清：业务含义、类型、示例、是否必填、空值率、来源系统和用途。听起来琐碎，但真正卡住对接的通常就是这些细节：手机号有没有验证过；金额单位是元还是分；时间存的是本地时间还是 UTC；状态值 3 到底代表正常、冻结还是已注销。

如果某个字段只有原开发和旧系统知道含义，交接就没有完成。把它写下来，或者明确标记为废弃。

同时做一次减法：身份证号、家庭住址、自由文本备注里粘贴的手机号和订单信息，如果新系统用不到，就不要交。交接单里写清“不交什么”，和写清“交什么”同样重要。

三、口径对照：比字段更容易漏

同一个指标，两边可能不是一回事。会员数是否包含已注销、测试号和合并账号？积分余额是否包含即将过期的部分？储值余额是否含赠送金额？等级按自然年还是滚动十二个月计算？

建议做一张对照表，四列：指标名、旧系统定义、新系统定义、差异说明。差异不需要在交接时全部解决，但必须被看见。最危险的不是有差异，而是双方都以为口径一致。

如果旧系统自己也解释不了某个数字，就把它标成“待确认”，不要用估算填上。一个诚实的问号，比一个编出来的总额有用。

四、先给样本，不要直接给全量

在正式导入前，先提供 300–500 条有代表性的样本：正常记录、换过手机号的、没有手机号的、重复注册的、余额为负的、已注销的。让对方在自己的测试环境里实际导入一次。

记录对方遇到的每一个问题：哪些行被拒绝、错误提示是否可读、重复账号怎么处理、编码有没有乱码、金额有没有被截断。这一步能提前暴露大部分集成问题，成本远低于生产环境回滚。

样本要脱敏，或者先签保密协议。不要用生产库直接试，也不要把真实会员数据发到个人邮箱。

五、验收标准要写在交接之前

验收不是“导入成功”四个字，而是一组可以核对的数字：总行数、去重会员数、各资产总额、异常记录数量，以及异常的处理时限。再加上一句：由谁签字确认。

还要约定旧系统在新系统验收前保持只读，并明确回滚窗口。很多项目的问题不是迁不过去，而是发现迁错时旧系统已经停了。

六、交接之后，责任边界也要写清

字段说明由谁维护、发现问题找谁、会员争议由哪一方先接待、数据保留多久、删除谁有权执行。这些内容写进合同附件，比留在群聊记录里可靠。

尤其是保留和删除：旧系统什么时候停用，备份保留多久，谁还能访问。迁移结束后，这些数据仍然是一份需要被管理的资产。

七、一页纸的交接清单

1. 字段说明：含义、类型、示例、空值率、来源、用途。
2. 口径对照：会员数、积分、储值、等级等关键指标的定义差异。
3. 样本：300–500 条，覆盖异常情况，已脱敏。
4. 验收标准：行数、总额、异常清单、签字人和回滚窗口。
5. 责任边界：维护人、争议处理、保留期限和删除权限。

每一项都标上版本号和日期。交接单不是一次性文档，它会随着口径变化更新。

交接做得好，迁移只是按计划执行；交接做得差，导入成功也只是把问题推迟到上线之后。AcrossFlow 在迁移立项前会和商家一起把这份交接单过一遍，因为身份能不能对上，往往在数据交出去之前就已经决定了。