迁移字段映射要解决的核心问题，是让源系统里的数据在目标系统中保持原有业务含义。字段名相同并不代表含义一致，例如“状态”在源端可能表示缺陷处理阶段，在目标端却对应任务进度。处理这类情况，需要先盘点实体与字段，再按业务定义、取值范围和必填约束逐项比对，形成可评审的字段映射表，并用抽样数据试迁移验证。映射表维护与评审环节可以放在 ONES 的工作项与文档中承载，本文聚焦数据内容映射的方法与落地步骤。
要点总览（TL;DR）
- 字段映射按业务含义建立，字段名只作检索线索；逐项比对业务定义、取值范围、枚举项和必填性，任一维度不一致就进入同名异义处理。
- 同名异义有拆分、合并、转换、弃用四种处理方式，字段映射表要写明转换规则、默认值与空值处理、责任人和评审状态。
- 映射规则用抽样试迁移验证，样本覆盖常规、边界和异常数据，逐字段比对源端值、预期值和目标端实际值，差异记入清单并归因。
- 试迁移出现批量错误或必填约束冲突时先暂停，按批次清理试迁移数据；规则变更后受影响字段必须重新核验。
- 进入正式迁移前确认映射表版本最新、核验记录完整、差异清单关闭、回退方案与责任人明确。
迁移字段映射要解决什么问题：来源、目标与范围
字段映射的第一步是把迁移方向固定下来：从哪个系统、哪个版本迁到哪个系统、哪个版本。方向一旦写清楚，后续所有字段比对才有统一基准。建议在项目启动文档中写明源端系统名称与版本、目标端系统名称与版本、迁移执行窗口，以及本次迁移覆盖的组织范围。版本信息缺失时，先向系统管理员确认，避免用旧版字段定义去比对新版目标结构。
接着确定纳入映射的实体清单。研发数据迁移通常涉及需求、缺陷、任务、用户、用户组、附件、评论等对象，不同实体的映射复杂度差别很大。实体清单要逐项列出，并标注每个实体是否包含历史数据、是否包含自定义字段。清单之外的对象明确写入“不在本次范围”，例如某些已停用的项目空间或临时导入的测试数据。
字段映射还需要与流程、插件行为迁移划清边界。字段映射处理的是数据内容如何落到目标字段，流程状态机、自动化规则、插件触发的行为属于相邻主题，应单独安排评估。边界划分清楚后，映射工作不会因为流程差异反复返工，评审时也更容易判断问题归属。
本节的交付物是一份“来源—目标—实体范围清单”，至少包含以下列：源系统及版本、目标系统及版本、实体名称、数据量级、是否含自定义字段、是否在本次范围、范围外原因、确认人。清单经项目负责人和目标系统管理员签字确认后，作为后续输入准备的依据。
映射前需要准备哪些输入与依赖
字段映射的质量取决于输入是否完整。开工前应收集四类材料：源端字段清单与数据字典、目标端字段定义与约束、业务口径说明、以及各字段含义的确认责任人。缺少任何一类，映射表都会出现“填了但没人能确认”的条目。
源端字段清单应包含字段标识、显示名称、数据类型、枚举值列表、是否必填、历史使用情况。数据字典则补充字段的业务解释和典型取值。目标端材料需要包含字段类型、长度限制、必填约束、枚举项、默认值规则，以及目标系统中该字段参与哪些校验。两边材料放在一起，才能逐项比对。
业务口径说明由熟悉原系统使用方式的产品或业务负责人确认。同名异义的判断往往依赖这类说明，例如源端“优先级”只有高、中、低三档，目标端有五个档位，转换规则需要业务方决定中间档如何归并。确认人要落实到具体姓名和角色，避免评审时出现“大家都觉得可以”。
用户身份与组织结构的对照基础同样属于前置依赖。用户、用户组、角色在迁移中需要建立对照关系，源端账号与目标端账号的对应规则、离职用户和历史操作人的处理方式，都应在映射开始前确定。对照基础未就绪时，可以先完成业务实体字段的映射，用户相关映射单独挂起，并在计划中标注依赖项。
依赖缺失时的处理方式要提前约定：关键输入缺失，例如目标端字段定义未确认，应暂停对应实体的映射；非关键输入缺失，例如个别字段的业务说明待补，可以先按“待确认”状态记录，限定补齐时间，不阻塞整体进度。本节交付“映射输入清单与责任分工表”，逐项记录材料名称、提供人、确认人、到位状态和缺失时的处理方式。
同名字段含义不同时怎么建立映射
建立映射的判断依据是业务含义，字段名只作为检索线索。对每一对候选字段，按四个维度逐项比对：业务定义、取值范围、枚举项、必填性。四个维度全部一致，才可以建立直接映射；任一维度不一致，就进入同名异义的处理流程。
同名异义常见四种处理方式。拆分，指源端一个字段在目标端对应多个字段，例如源端“处理人”同时承载开发负责人和测试负责人，目标端拆成两个角色字段，需要按历史数据中的角色信息分流。合并，指源端多个字段落到目标端一个字段，例如多个来源的“备注”合并到统一描述字段，需要约定拼接顺序和分隔符。转换，指含义接近但取值体系不同，例如状态枚举、优先级档位、严重程度分级，需要建立枚举对照表。弃用，指源端字段在目标端没有业务对应，且历史值不影响后续使用，应记录弃用原因并保留原始数据备查。
字段映射表建议采用以下列结构，便于逐项比对和评审：
| 列名 | 填写要求 |
|---|---|
| 序号 | 唯一编号，便于差异清单引用 |
| 源实体 / 源字段 | 字段标识与显示名称，注明数据类型 |
| 目标实体 / 目标字段 | 字段标识与显示名称，注明类型与必填约束 |
| 业务含义比对 | 分别写源端与目标端的业务定义，指出差异点 |
| 映射类型 | 直接映射、拆分、合并、转换、弃用 |
| 转换规则 | 枚举对照、拼接规则、截断规则或计算公式 |
| 默认值与空值处理 | 源端为空时目标端填什么，异常值如何标记 |
| 责任人 | 规则提出人与业务确认人 |
| 评审状态 | 待评审、已确认、需修改 |
默认值、空值与异常值需要单独约定。源端为空不等于目标端可以留空，目标端必填时应给出默认值及其业务合理性说明；源端出现枚举外的异常值时，应记录为待处理清单，不擅自归入某个档位。转换规则涉及截断时，要写明截断长度和截断后的提示方式。
映射规则完成后进入评审。评审由业务确认人、目标系统管理员和迁移执行人共同参加，逐条确认映射类型与转换规则，重点检查拆分与合并条目。评审通过的条目状态改为“已确认”，有争议的条目保留“需修改”并指定补齐时间。评审记录与映射表版本一并归档，后续规则变更以此为基础。
试迁移与映射结果核验
映射规则是否正确，要靠数据验证。试迁移从源端抽取样本数据，按映射表转换后导入目标系统的测试环境，再逐字段比对结果。抽样范围应覆盖三类数据：常规数据、边界数据、异常数据。常规数据验证主流程，边界数据验证枚举转换和长度限制，异常数据验证空值与非法值的处理约定。
样本量按实体分别确定。数据量小的实体可以全量试迁移；数据量大的实体按字段复杂度分层抽样，每个枚举字段至少覆盖全部枚举项，每个转换规则至少覆盖若干条真实记录。抽样清单要记录样本标识，确保核验时可以回溯到源端原始记录。
核验采用逐字段比对方法：对每条样本，记录源端值、映射规则预期结果、目标端实际值，三者一致记为通过，不一致记入差异清单。差异清单包含样本标识、字段、源端值、预期值、实际值、差异类型和初步归因。差异类型可分为规则错误、数据异常、目标端约束冲突、执行遗漏四类，便于分类处理。
差异归因后修正映射规则，修正范围可能涉及转换规则、默认值约定或枚举对照表。规则修改后，受影响字段的样本需要重新试迁移并重新核验，不能只改表不验证。核验记录应包含试迁移批次、执行时间、样本数量、通过率、差异数量及处理状态，作为进入正式迁移的证据。
进入正式迁移的通过条件建议明确为：所有已确认映射条目均有核验记录；差异清单中的问题已关闭或有经确认的处置方案；必填字段在样本中无空值导入失败；枚举转换在全部枚举项上验证通过。条件满足后由项目负责人和目标系统管理员共同确认，再安排正式迁移窗口。
映射出错时的回退与停止条件
试迁移阶段发现问题，先暂停而不是继续推进。典型暂停情形包括：关键实体出现批量映射错误，例如状态枚举整体错位；目标端必填约束导致大量记录导入失败；用户对照关系未确认就导入业务数据；差异清单中高优先级问题未关闭。出现这些情形时，暂停后续批次，保留现场记录，组织规则评审。
试迁移数据的清理要提前约定方式。测试环境中的试迁移数据应按批次标识隔离，回退时按批次删除或还原到迁移前快照。清理完成后确认目标端数据状态与试迁移前一致，再开始下一轮验证。清理记录与回退操作人一并留档，避免多轮试迁移数据混在一起影响判断。
映射规则变更后必须重新核验。变更影响哪些字段、哪些样本需要重跑、由谁确认，都应在变更记录中写明。规则变更未重新核验的字段，不得进入正式迁移范围。对于反复出现差异的字段，应回到业务口径确认环节，检查源端字段的实际使用方式是否与文档描述一致。
正式迁移前设置最终确认点，检查内容包括：映射表版本为最新且全部条目已确认；试迁移核验记录完整；差异清单已关闭；回退方案与责任人明确；正式迁移窗口与业务方沟通完成。任一检查项不满足，推迟正式迁移。本节交付“回退与停止条件清单”，逐条写明触发条件、暂停范围、回退方式、重新核验要求和确认人，作为迁移执行的检查依据。
常见问题
源端和目标端字段名一样，能不能直接建立映射？
不能仅凭字段名判断。字段名相同只说明命名接近，映射是否成立要看四个维度：业务定义、取值范围、枚举项、必填性。四个维度全部一致才可以建立直接映射；任一维度不一致，就要按同名异义处理，选择拆分、合并、转换或弃用，并在字段映射表中写明转换规则和确认人。
源端字段在目标端找不到对应字段，应该怎么处理？
先确认该字段在源端的实际使用情况：是否有历史值、是否被报表或查询引用、业务方是否还需要这些信息。目标端确实没有业务对应且历史值不影响后续使用时，按弃用处理，在映射表中记录弃用原因，并保留原始数据备查。如果字段承载的信息仍被业务需要，则应考虑合并到目标端的相近字段，或推动目标端补充字段配置，具体方式由业务确认人和目标系统管理员共同决定。
试迁移要抽多少数据才算够？
样本量按实体分别确定，没有统一数字。数据量小的实体可以全量试迁移；数据量大的实体按字段复杂度分层抽样。关键约束是覆盖度：每个枚举字段至少覆盖全部枚举项，每条转换规则至少覆盖若干条真实记录，同时纳入边界数据和异常数据。样本清单要记录标识，确保核验时能回溯到源端原始记录。
映射规则评审通过后又发现错误，需要全部重跑吗？
不需要全部重跑，但受影响字段的样本必须重新试迁移并重新核验。规则变更时在变更记录中写明影响哪些字段、哪些样本需要重跑、由谁确认。未重新核验的字段不得进入正式迁移范围。如果同一字段反复出现差异，应回到业务口径确认环节，检查源端字段的实际使用方式是否与文档描述一致。
从 Jira 迁移到 ONES 时，字段映射的范围包括哪些内容？
根据 ONES 公开的迁移方案说明，从 Jira 迁移到 ONES Project 时，迁移内容包括问题数据（属性和属性值、附件、评论等），以及项目、系统配置（问题类型、工作流、字段配置、权限配置等）和用户、用户组。字段级的具体映射规则与转换方式需要在迁移方案中逐项确认。企业已有的定制场景，迁移前仍需逐项评估，避免假设所有插件都能一一对应。
