数据迁移字段映射表，不是把旧字段名和新字段名排成两列。真正要写清的是：源值代表什么，目标接受什么，怎样转换，不能转换时去哪里。字段名称相近、数据类型相同，也不代表含义和使用规则一致。
梳理时可以先在 Boardmix 的数据流绘图页面找到绘制入口，用连线标出新旧字段的对应，再把转换规则放在相邻表格中。关系图便于发现漏项和多对一关系，执行迁移仍需要实际的数据处理程序、测试和发布安排。
先对齐源与目标约束，再开始连线
以旧客服工单系统迁移到新系统为例，旧系统的状态只有“新建、处理中、关闭”，新系统却区分“待处理、处理中、已解决、已取消”。如果将旧“关闭”一律改成新“已解决”，历史上主动撤回的工单也会被算成解决，迁移行数可能完全正确，业务含义却已经变了。
准备材料时，源字段要有名称、类型、含义、可空情况及代表性样本；目标字段要说明含义、类型、长度、是否必填、允许值以及唯一性等约束。样本不能只选最整齐的一行，还要找历史空值、旧枚举和不符合当前规则的记录。
字段含义尚未确认时，先补数据字典中的定义与负责人，不要让开发凭英文名猜。映射表解决的是两套已知含义之间如何转换，不负责替业务决定“关闭”究竟代表什么。
工单迁移的映射表，至少写到规则和例外
| 旧字段 → 新字段 | 转换约定 | 异常处理与检查 |
|---|---|---|
| ticket_code → external_ref | 保留字符串及前导零，“0007”仍为“0007”；新系统自身主键单独生成 | 旧编号重复或为空时进入异常清单，不用行号临时替代 |
| status、close_reason → status | 0→open；1→in_progress；2且原因为solved→resolved；2且原因为cancelled→cancelled | status=2但原因缺失，或遇到未登记枚举，暂停该记录映射并请业务确认 |
| duration_sec → duration_minutes | 本例目标接受小数分钟，以秒数÷60转换；90秒→1.5分钟 | 先确认目标精度和舍入规则；负数及无法解析的值单独处理，空值不自动改为0 |
| requester_id → requester_uid | 通过已确认的新旧用户标识对照表查找，不按姓名匹配 | 查不到或找到多个目标时进入异常清单；不能随机选第一条 |
| created_at → created_at | 确认源时间的时区和格式，再转换为目标约定的时间表示 | “2026-09-01 09:00:00”本身没有时区，不能直接加Z当成UTC |
这张表采用的是本案例约定，不是某种工单系统的默认编码。0、1、2 与目标英文值都必须替换为实际系统定义。还可以为每条映射增加规则编号、确认人、样本编号与版本，较长的说明单独放规则卡，用编号对应，避免横向表格越堆越宽。
字段对应与类型转换应分开确认。Microsoft 的映射说明也将架构映射与数据类型映射分别讨论。某个工具能够按列名复制，并不意味着它已经理解你的业务状态、单位或标识关系。
画三类连线，找出两列表格不容易暴露的问题
在画布左侧放旧系统，中间放转换规则，右侧放新系统。每个字段一行，尽量让主要关系从左向右阅读。这张字段关系图重点说明数据从哪里来、经过哪条规则、写到哪里，旁边的表格承载具体约束与样本。
- 一对一：ticket_code 连到 external_ref，线上写“原样保留字符串”。用这条最简单的映射先确认长度、编码和唯一性，不要只写“直接复制”。
- 多对一：status 与 close_reason 共同连到规则卡 M02，再连到目标 status。两条输入缺任何一条，都不能擅自完成关闭状态细分。
- 依赖对照表：requester_id 连到用户标识对照表，再连到 requester_uid。把“无匹配/多匹配”的异常出口画出来，避免一根直线掩盖查找失败。
未迁移字段也要有去向。例如旧系统中的内部临时标签不进入新系统，可列为“本次不迁移”，记录理由和原始归档位置；不能因为目标没有同名列就静默丢弃。反过来，新系统新增的必填字段若没有来源，要明确由可靠规则推导、经确认使用默认值，还是先补齐数据。空白箭头不是处理方案。
同一旧编号如果在不同业务分区可以重复，还要确认目标标识是否需要组合“来源分区＋旧编号”。不要在导入时报冲突后才临时拼接一个字符串，否则后续关联表可能仍在引用旧编号，主表导入了，关系却断了。
用有预期结果的样本核对，不只检查总行数
先为每条规则准备输入和预期输出，再让实现者执行。下面四条状态样本能立即暴露“关闭都算解决”的问题。
| 源记录 | 预期结果 | 为什么 |
|---|---|---|
| 0007；status=2；close_reason=solved | external_ref仍为0007；status=resolved | 关闭原因支持已解决；编号未丢前导零 |
| 0008；status=2；close_reason=cancelled | status=cancelled | 取消不能变成已解决 |
| 0009；status=2；close_reason为空 | 进入异常清单，等待确认 | 现有信息不足以决定目标状态 |
| 0010；status=9；原因未登记 | 进入异常清单，不套用默认open | 未知枚举需要解释，不能伪装成新建工单 |
再补跨字段样本：90 秒是否得到 1.5 分钟，空耗时是否保持未知，用户标识能否唯一对应，时间转换后是否仍表示同一时刻。对只保留整数分钟的目标，应先确认舍入还是截断，以及是否允许丢失精度，不能由程序默认行为代替业务决策。
汇总核对时，以工单记录为单位，将本批源记录互斥地分为成功转换、存在异常待处理和按批准范围不迁移三类，三类数量之和应等于本批源记录总数。一条工单即使同时缺少关闭原因和用户标识，也只算一条异常记录；字段异常条数另外统计，不能拿来凑总行数。随后比较关键状态分布与关联完整性。总数相等只证明数量没有明显缺口，不能证明已取消与已解决的含义没有被混淆。
让业务、开发和测试对同一版规则确认
在 Boardmix 中给每条映射一个稳定编号，把源样本、规则卡、目标样本和待确认问题摆在相邻区域。评审 M02 时，业务确认“关闭”的真实含义，开发说明缺失值和异常队列如何处理，测试拿预期样本核对结果。讨论结束后，把决定回写进映射表，而不是只留在聊天里。
如果后来发现旧状态2还包含“重复工单”，就为 M02 增加新规则版本，找到受影响的源记录并重新核对。是否重跑、如何识别已导入记录及如何撤回错误转换，需要在迁移实现中明确；白板上的连线本身不会让旧数据自动修正。
交付给实施者的应是四份对应材料：字段关系图说明来源与去向，映射表说明转换规则，样本表说明正确结果，异常清单说明不能静默处理的情况。真正进入停写与切流阶段时，再使用数据迁移切换流程安排执行窗口，不把字段评审通过当成整次迁移已经完成。
粤公网安备44030502008643