研发数据迁移时遇到同名字段，先别按字段名直接对齐。更稳妥的做法是：盘点源系统与目标系统各自字段的业务定义、取值范围、必填规则和关联对象，建立“源字段—语义—目标字段”的映射表；对语义不一致的字段做拆分、合并、值转换或落备注，再用抽样数据双向核对，确认无误后批量迁移。本文按范围确认、语义判断、映射方法、抽样核验和回退条件五个环节展开，适用于需求、缺陷、任务、用例等工作项数据的字段迁移。
要点总览（TL;DR）
- 同名字段不能按字段名直接对齐，先比对源系统与目标系统对同一字段的业务定义、取值范围、必填规则和关联对象，四个维度任一不一致即视为语义不同。
- 为每个同名字段建立语义对照卡，记录双方定义、取值、确认人和确认日期，作为映射表的输入和争议追溯依据。
- 映射表至少包含源字段、源含义、目标字段、目标含义、转换规则、负责人和核验状态；语义不一致的字段按一对一、一对多拆分、多对一合并、无法对应四类情形分别处理。
- 映射规则确认后先抽样试迁移，按对象和字段分层抽取，逐条比对源值与目标值，差异回写规则后重新抽样，通过后再批量迁移。
- 语义无法确认、必填字段无合法来源或批量迁移后发现系统性偏差时，应暂停或按批次回退，清理已导入数据后重新走映射确认与抽样核验流程。
先确认迁移范围：哪些同名字段需要重新映射
同名字段映射的第一步是收窄范围。研发数据迁移往往涉及需求、缺陷、任务、用例、迭代等多个对象，每个对象下又有大量字段。如果一开始就逐个字段比对，工作量会迅速失控。先明确源系统和目标系统的版本、部署方式与对象范围，再列出本次迁移涉及的字段清单，才能把精力集中在真正需要重新映射的同名字段上。
范围确认需要产出三样东西：源系统与目标系统的版本信息、迁移对象清单、同名字段清单。同名字段清单要标注字段所属对象，因为同一个字段名在不同对象下含义可能不同。例如“状态”在需求对象下表示需求生命周期阶段，在缺陷对象下表示缺陷处理阶段，两者的枚举值往往不能通用。
| 确认项 | 记录内容 | 示例 |
|---|---|---|
| 源系统 | 产品名称、版本、部署方式 | 源系统 A，版本待确认，私有化部署 |
| 目标系统 | 产品名称、版本、部署方式 | 目标系统 B，版本待确认 |
| 迁移对象 | 本次迁移的对象类型 | 需求、缺陷、任务、用例 |
| 同名字段 | 字段名、所属对象、是否本次迁移 | “优先级”，需求与缺陷均存在，本次迁移 |
| 暂不迁移字段 | 字段名、原因 | “自定义评分”，目标系统无对应字段，暂不迁移 |
暂不迁移的字段要写明原因和后续处理方式，例如保留在源系统只读、导出为附件或后续单独评估。范围清单确认后由业务负责人和数据迁移负责人共同签字，作为后续映射和核验的基线。
同名字段含义不同的判断依据与输入材料
判断两个同名字段含义是否一致，不能只看字段名，也不能只看界面标签。需要收集四类材料：字段定义文档或数据字典、界面提示文字、实际取值样例、历史数据分布。定义文档说明字段设计意图，界面提示反映用户看到的使用说明，取值样例和历史分布则能暴露实际使用中与定义不一致的情况。
具体判断时，重点比对四个维度：业务定义、取值范围、必填规则和关联对象。业务定义回答“这个字段用来记录什么”；取值范围回答“允许填哪些值”；必填规则回答“什么情况下必须填”；关联对象回答“这个字段与哪些其他数据存在联动”。四个维度中任何一个不一致，都应视为语义不同，进入映射处理流程。
| 判断维度 | 需要收集的材料 | 不一致时的信号 |
|---|---|---|
| 业务定义 | 数据字典、字段说明文档 | 同一字段名，一个记录严重程度，一个记录处理优先级 |
| 取值范围 | 枚举值清单、实际取值样例 | 源系统有五个等级，目标系统只有三个等级 |
| 必填规则 | 字段配置、表单规则 | 源系统选填，目标系统必填 |
| 关联对象 | 字段联动配置、业务规则说明 | 源系统字段随工作项类型变化，目标系统全局统一 |
每个同名字段形成一张语义对照卡，记录源字段定义、目标字段定义、取值范围、必填规则、确认人和确认日期。确认人应是熟悉该字段实际业务含义的产品或业务负责人，不能仅由技术人员判断。语义对照卡是后续映射表的输入，也是出现争议时的追溯依据。
建立字段映射表：拆分、合并与值转换的处理方法
映射表是字段迁移的核心交付物。它的作用是把每个源字段的处理方式固定下来，让迁移执行和核验都有据可查。映射表至少包含七列：源字段、源字段含义、目标字段、目标字段含义、转换规则、负责人和核验状态。每一行对应一个源字段，语义不一致的字段在转换规则列写明具体处理方式。
语义不一致的字段通常落入四类情形，处理方式各不相同：
- 一对一直接映射：字段含义、取值范围和必填规则基本一致，直接对应。例如源系统“标题”对应目标系统“标题”，仅需确认长度限制。
- 一对多拆分：源系统一个字段承载了多种信息，目标系统拆成多个字段。例如源系统“优先级”同时包含紧急程度和影响范围，目标系统分为“优先级”和“影响范围”两个字段，需要按规则拆分取值。
- 多对一合并：源系统多个字段在目标系统合并为一个字段。例如源系统“严重程度”和“优先级”在目标系统统一为“优先级”，需要定义合并规则，明确冲突时以哪个字段为准。
- 无法对应：目标系统没有语义相近的字段。处理方式包括落入备注字段、作为附件保留、写入独立的自定义字段，或在迁移报告中登记为未映射字段并说明原因。
枚举值和状态字段是转换规则中最容易出问题的部分。源系统的“已关闭”可能包含“已解决”和“已拒绝”两种终态，目标系统的“已关闭”只有一个状态。这时需要决定：是合并为一个状态并在备注中保留原始状态，还是在目标系统中新增状态值。状态字段还涉及工作流流转，映射规则要与目标系统的工作流配置一起确认，避免迁移后工作项卡在无法流转的状态。
| 源字段 | 源含义 | 目标字段 | 转换规则 | 负责人 | 核验状态 |
|---|---|---|---|---|---|
| 优先级 | 缺陷处理紧急程度，五级 | 优先级 | P0→最高，P1→高，P2→中，P3/P4→低 | 缺陷模块负责人 | 待核验 |
| 状态 | 缺陷生命周期，含已解决、已拒绝 | 状态 | 已解决→已关闭，已拒绝→已关闭，原值写入备注 | 缺陷模块负责人 | 待核验 |
| 严重程度 | 缺陷影响范围，三级 | 优先级 | 与优先级合并，冲突时以优先级为准，严重程度写入备注 | 质量负责人 | 待核验 |
| 自定义评分 | 内部评估分值 | 无对应字段 | 写入备注字段，格式“原评分：X” | 数据迁移负责人 | 待核验 |
映射表填写完成后，由各字段负责人逐行确认转换规则，核验状态从“待核验”更新为“已确认”。转换规则中涉及枚举值映射的，要附上完整的值对照表，不能只写“按规则转换”。对于无法对应的字段，要在映射表中保留记录，不能直接删除，以便迁移后追溯。
在映射表维护和核验记录环节，如果目标系统是 ONES，可以借助其工作项与文档管理能力承载迁移过程：把映射表作为迁移项目的文档沉淀，每个字段的确认状态和核验记录关联到对应工作项，迁移执行人、业务确认人和核验人按角色分工更新状态。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并支持迁移问题属性和属性值、附件、评论等信息，字段配置也在可迁移的系统配置范围内。字段级转换规则的具体配置方式，建议在实施前向原厂确认，并以目标系统实际字段配置为准。
用抽样数据核验映射结果
映射规则确认后，不能直接全量迁移。先用抽样数据跑一遍转换，验证规则在真实数据上的效果。抽样要按对象和字段分层：每个迁移对象抽取一定数量的工作项，覆盖不同状态、不同优先级、有无附件、有无自定义字段取值等情形。样本量根据数据总量和字段复杂度确定，字段转换规则越复杂，样本应越多。
核验时逐条比对源值和目标值，重点检查四类问题：值是否正确转换、枚举值是否落在目标系统允许范围内、必填字段是否都有值、无法映射的内容是否按规则落入备注或附件。比对结果记录在核验表中，每条差异写明源工作项标识、字段名、源值、目标值、差异类型和处理结论。
- 抽样方法：按对象分层，每层覆盖全部状态和优先级组合，再随机补充样本。
- 比对方式：导出源数据与转换后数据，按工作项标识逐条对照，字段级比对。
- 差异记录：记录差异类型（值错误、值缺失、枚举越界、落位错误）和初步原因。
- 规则回改：差异属于规则问题的，回写映射表并重新抽样验证；属于数据质量问题的，单独登记。
- 通过标准：抽样范围内字段转换准确率达到约定阈值，必填字段无缺失，枚举值全部合法，由业务负责人和数据负责人共同确认。
核验通过后形成抽样核验记录，包含样本清单、比对结果、差异处理清单和确认人签字。这份记录是批量迁移的放行依据，也是迁移后出现争议时的核查材料。
映射出错时的回退与停止条件
映射过程中出现以下情况应暂停迁移：同名字段的业务含义无法由业务负责人确认；必填字段在目标系统中无合法取值来源；枚举值转换后出现目标系统不存在的状态；抽样核验发现系统性偏差，例如某一类工作项的字段普遍转换错误。暂停不是失败，而是避免错误数据进入目标系统后再清理的成本。
批量迁移后发现系统性偏差时，回退方式取决于迁移工具是否支持按批次回退。如果支持，回退最近一批迁移数据，修正映射规则后重新执行；如果不支持，需要按迁移批次标识清理已导入数据，清理前先导出迁移日志，确认清理范围不波及迁移前已存在的数据。回退后重新执行映射表确认和抽样核验流程，不能跳过核验直接重跑。
| 停止/回退条件 | 触发时机 | 处理动作 |
|---|---|---|
| 字段语义无法确认 | 映射表填写阶段 | 暂停该字段映射，升级至业务负责人确认 |
| 必填字段无合法来源 | 映射表确认阶段 | 暂停迁移，评估补录或调整目标字段必填规则 |
| 抽样核验发现系统性偏差 | 试迁移阶段 | 回退样本数据，修正规则后重新抽样 |
| 批量迁移后字段普遍错误 | 批量迁移后 | 按批次回退，清理已导入数据，重新映射 |
| 状态字段导致工作项无法流转 | 试迁移或批量迁移后 | 暂停迁移，联合工作流负责人修正状态映射 |
回退后的数据清理要留下记录：清理了哪些批次、涉及多少工作项、清理前后的数据状态。重新映射时，把本次回退原因写入映射表的备注列，避免同类问题再次发生。整个迁移过程中，映射表、语义对照卡、抽样核验记录和回退记录应保持版本一致，任何规则变更都对应一次核验更新。
常见问题
源系统和目标系统的字段名相同、枚举值也相同，还需要做语义比对吗？
需要。枚举值相同只能说明取值范围一致，业务定义、必填规则和关联对象仍可能不同。例如两个系统都有“高、中、低”三档，但一个用于记录缺陷影响范围，另一个用于记录处理优先级，迁移后数据的业务含义就变了。建议至少核对业务定义和必填规则两项，确认后再按一对一直接映射处理，并在映射表中记录确认人。
业务负责人无法确认某个字段的含义时，迁移应该怎么推进？
该字段应暂停映射，不要用技术人员的推测代替业务确认。可以先把字段列入待确认清单，记录已收集到的定义文档、取值样例和界面提示，升级至熟悉该业务的产品或业务负责人判断。其余字段的映射和核验可以继续推进，待确认字段在确认前不进入批量迁移范围，避免错误数据写入目标系统后再清理。
无法映射的字段内容，除了写入备注还有别的处理方式吗？
常见处理方式有几种：写入目标系统的备注字段、作为附件随工作项保留、在目标系统新建独立的自定义字段承载，或在迁移报告中登记为未映射字段并说明原因。选择哪种取决于内容的使用频率和后续查询需求。无论选哪种，映射表中都要保留该字段的记录和转换规则，不能直接删除，以便迁移后追溯。
抽样核验通过后，批量迁移还需要注意什么？
抽样通过说明规则在样本范围内有效，批量迁移时仍要保留批次标识和迁移日志，便于出现问题时按批次定位和回退。迁移过程中建议分批执行，每批完成后抽查少量数据，确认与试迁移结果一致再继续下一批。全部完成后，把映射表、语义对照卡、抽样核验记录和回退记录归档为同一版本，作为后续核查材料。
如果目标系统是 ONES，字段映射和核验记录可以放在哪里管理？
可以把映射表作为迁移项目的文档沉淀，每个字段的确认状态和核验记录关联到对应工作项，迁移执行人、业务确认人和核验人按角色更新状态。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并支持迁移问题属性和属性值、附件、评论等信息，字段配置也在可迁移的系统配置范围内。字段级转换规则的具体配置方式，建议在实施前向原厂确认，并以目标系统实际字段配置为准。
