Jira 自定义字段迁移的关键，是先按业务含义给字段分类，再建立源字段到目标字段的映射规则，用小批量数据试迁移验证，最后按校验清单确认取值完整、语义一致后才全量切换。同名字段含义不同时以业务含义为准，无法一一对应的先归入暂存或合并方案，并保留可回退的源数据。下文按盘点、准备、映射、试迁移、校验、回退六个环节展开，涉及 ONES 时仅说明其在字段配置与迁移协作中可承接的管理动作。
要点总览（TL;DR）
- 先按使用频率、业务关键性和流程引用情况把 Jira 自定义字段分为必迁、可合并、可废弃三类，再进入映射设计。
- 字段映射以业务含义为准，用“源字段—目标字段—转换规则—责任人—验证状态”五列表推进，同名异义、类型不一致、一对多与多对一逐项定规则。
- 试迁移要覆盖空值、超长文本、多选全选、已停用选项等边界数据，失败项按类型不符、选项缺失、权限不足三类归因，通常跑两到三轮。
- 校验分字段级与业务级两层：比对数量、取值分布与空值率，再确认关键流程和报表在目标侧可正常读取，校验报告作为切换依据。
- 切换前保留源数据快照并约定窗口，出现关键字段大面积丢失或语义错位时暂停，修正映射后重新小批量试迁移再扩大批次。
迁移范围：哪些 Jira 自定义字段需要迁
这一步要回答两个问题：迁什么、先迁什么。源系统是 Jira，迁移对象是自定义字段本身及其承载在工单上的取值，不包括 Jira 日常使用教程或与字段无关的配置。目标系统的字段类型与容量边界需要在动手前确认，未核实的部分标注为待验证项，不默认全部兼容。
字段范围不宜按“Jira 里有多少个字段就搬多少个”来确定。建议从三个维度给每个字段打分：使用频率（近半年有多少工单填过该字段）、业务关键性（是否影响流转、审批、统计口径）、流程引用情况（是否被工作流条件、屏幕方案、过滤器或报表引用）。据此把字段划成三类：
| 分类 | 判定依据 | 处理方式 |
|---|---|---|
| 必迁 | 仍被流程或报表引用，或承载关键业务判断 | 进入映射表，逐字段设计转换规则 |
| 可合并 | 与另一字段语义重叠，或使用频率低但偶有历史数据 | 合并到目标侧一个字段，保留原值来源说明 |
| 可废弃 | 长期空置、流程已不引用、仅为历史遗留 | 不迁入目标系统，源数据保留在归档中备查 |
盘点产物是一张字段清单，至少包含字段名、字段类型、使用场景、引用位置、迁移分类五列。清单完成后先与业务负责人过一遍“可废弃”一栏，避免把仍有人在用的字段误判为废弃。目标侧的类型与容量边界（如单选项数量上限、文本长度限制、用户字段是否要求账号先存在）在这一步同步确认，确认不了的记为待验证项，带入试迁移环节验证。
迁移前要准备哪些输入与依赖
字段映射不是一个人对着 Jira 后台就能完成的工作，它依赖几类输入材料和配合方。材料缺失时不要凭印象补规则，先把缺口列出来，能通过导出补齐的补齐，补不齐的转为待确认项。
- 字段清单与选项值清单：每个自定义字段的类型、全部选项值（含已停用但历史工单仍在用的选项）、默认值设置。选项值清单常被忽略，而它恰恰是试迁移中最容易出问题的地方。
- 屏幕与工作流引用关系：字段出现在哪些屏幕方案、哪些工作流条件或校验中。这决定了字段迁过去之后，目标侧是否还需要配置对应的可见性与流转条件。
- 样例工单数据与取值分布：抽取一批覆盖各类字段的工单，统计每个字段的填充率、空值率、取值分布。取值分布是后续校验的基线，没有基线就无法判断迁移后是否“语义一致”。
- 目标系统字段配置权限与管理员配合：确认谁有权在目标系统创建自定义字段、调整字段类型、配置必填与默认值。字段创建往往需要管理员角色，普通项目成员无法完成，提前约定配合人和响应时间。
把这些整理成一张输入清单与依赖确认表，逐项标注“已具备、待补齐、待确认”三种状态。待确认项中涉及目标系统能力边界的，例如某类字段在目标侧是否存在等价类型，应在试迁移前向目标系统的管理员或厂商确认，而不是等到全量迁移时才发现。
同名字段含义不同时怎么做字段映射
映射的核心判断标准是业务含义，字段名只是线索。Jira 里叫“优先级”的字段，在目标系统里可能对应“严重程度”；Jira 里两个不同字段（如“模块”和“组件”）在目标侧可能只有一个“所属模块”。遇到这类情况，先问这个字段在业务上回答什么问题、被谁在什么环节使用，再决定它落到目标侧哪个字段。
建议用一张五列的映射表推进：源字段、目标字段、转换规则、责任人、验证状态。转换规则一列要写到可执行的程度，例如“单选转多选，原值作为其中一个选项保留”“日期统一转为目标系统时区后写入”“用户字段先完成账号映射再写入，映射不到的统一落到待分配账号”。
| 情形 | 处理策略 | 需人工确认的点 |
|---|---|---|
| 同名异义 | 以业务含义重新匹配目标字段，必要时改名 | 字段名相同但取值口径不同的，逐一确认 |
| 类型不一致（单选与多选） | 明确选项集合的包含关系，多选转单选时定优先级规则 | 多选值超过一个时保留哪一个 |
| 日期与时间 | 统一时区与格式后再写入 | 原系统时区设置是否与业务预期一致 |
| 用户字段 | 先完成账号映射表，再迁移取值 | 离职账号、外部协作者账号的归属 |
| 文本长度超限 | 截断并记录原文，或改为长文本类型 | 截断是否影响业务判断 |
| 一对多、多对一 | 记录拆分或合并规则，单独列出待确认清单 | 合并后原值如何追溯 |
必填与默认值在目标侧需要重新补齐。Jira 中某字段在特定项目必填，迁到目标系统后如果全局设为必填，会影响其他项目的工单创建；如果设为非必填，历史数据的完整性又缺少约束。处理办法是按项目或工作项类型分别配置，并在映射表中记录每个字段在目标侧的必填范围。默认值同理，原默认值若在新系统中已无对应选项，需要指定替代值或改为空。
无法一一对应的字段不要强行塞进某个目标字段。可以设一个暂存字段集中存放，标注来源字段名，待业务确认后再决定合并、拆分或废弃。这样既保证数据不丢，也避免错误映射污染目标系统的统计口径。
试迁移：小批量验证映射是否成立
映射表设计得再细，也要用真实数据跑一遍。试迁移的目的不是验证“能不能迁”，而是暴露映射规则在边界数据上的问题。样本工单的选取要覆盖每一类字段，并刻意包含边界取值：空值、超长文本、多选全选、已停用的历史选项、离职用户填写的用户字段、跨时区创建的日期。
执行顺序建议固定下来并逐条记录：先迁字段配置（字段本身、选项、必填与默认值），再迁样本工单的字段取值，最后核对目标侧的显示与筛选是否正常。每一步记录执行时间、执行人、影响的数据条数。失败项按三类归因，便于分头处理：
- 类型不符：源字段类型在目标侧无等价类型，或转换规则未覆盖某种取值形态。
- 选项缺失：源选项值在目标侧不存在，常见于已停用选项或拼写差异。
- 权限不足：执行迁移的账号无权创建字段、写入某类工作项，或目标项目未开放对应字段。
试迁移记录与问题清单要能直接回填到映射表的“验证状态”一列。每修复一条规则，标记对应字段为“已修正待复验”，并安排下一轮小批量复跑。试迁移通常需要两到三轮，轮次多少取决于字段数量和定制程度，不必追求一轮通过。
核验与证据：怎么判断字段迁移成功
判断字段迁移是否成功，看两层：字段级的数据对不对，业务级的用法通不通。两层都通过，才具备全量切换的条件。
字段级校验做三组对比，以试迁移前统计的取值分布为基线：
- 数量：每个字段有值的工单数与源侧一致，差异逐条说明原因。
- 取值分布：各选项的占比与源侧对比，偏差超出约定阈值的选项单独核查。
- 空值率：迁移后空值率不应无故升高，升高通常意味着转换规则丢弃了部分取值。
业务级校验换一个视角：让实际使用这些字段的人来确认。关键流程能否在目标侧按原条件流转，依赖该字段的报表和过滤器能否正常出数，必填约束是否在正确的项目生效。业务级校验发现的问题往往比字段级更隐蔽，例如某字段数值都对，但目标侧的选项排序导致看板分组错乱。
校验结果整理成字段迁移校验报告，包含基线数据、迁移后数据、差异清单、差异原因与处理结论。报告是切换决策的依据，也是出问题时判断影响范围的底稿。校验未通过的字段，不进入全量迁移批次。
回退与停止条件：什么情况下暂停迁移
迁移过程中需要有明确的暂停线，而不是等到全量切换后才发现问题。以下情形出现时应立即停止当前批次：关键字段出现大面积丢失（例如某必迁字段空值率显著高于基线）、字段语义错位导致业务判断失真（例如优先级与严重程度取值互换）、目标侧关键流程因字段缺失无法流转。
回退的前提是源数据可恢复。切换前保留 Jira 侧的数据快照或完整备份，明确快照的时间点与覆盖范围；约定切换窗口，窗口内暂停源系统的写入，避免迁移期间产生新数据造成两边不一致。回退动作本身也要预演一次，确认恢复流程的耗时在可接受范围内。
问题修复后不直接进入全量迁移，而是回到映射表修正规则，重新执行一轮小批量试迁移，复验通过后再扩大批次。批次可以按项目或按字段组分批推进，每批都保留独立的校验记录，这样即使某一批出问题，影响范围也可控。
如果迁移目标已经确定为 ONES，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件与历史记录，并在迁移 Jira 数据到 ONES Project 时迁移问题类型、工作流、字段配置、权限配置等系统配置，以及问题数据的属性和属性值。字段类型的具体覆盖范围、选项值与必填约束的转换规则，仍需在试迁移中逐项验证；对于依赖插件或定制的字段场景，迁移前应逐项评估，不假设全部一一对应。这套分阶段验证与回退安排，正好对应上文从盘点、映射到试迁移、校验的推进节奏。
常见问题
Jira 自定义字段数量很多，能不能先全量迁过去再慢慢清理？
不建议。全量迁移会把长期空置、流程已不引用的字段一并带入目标系统，字段列表变长后，配置屏幕、工作流条件和报表时更容易选错字段，后续清理还要再动一次数据。更稳妥的做法是在盘点阶段就按使用频率、业务关键性和流程引用情况分类，把可废弃字段留在源系统归档备查，只把必迁和可合并字段带入映射表。字段数量多时，可以先迁被流程和报表引用的字段，其余字段分批处理。
源字段和目标字段类型不同，比如 Jira 的多选迁到目标侧只有单选，取值怎么处理？
先确认两个选项集合的包含关系，再定转换规则。如果源侧多选值在目标侧都能找到对应选项，需要明确多选值超过一个时保留哪一个，常见做法是按业务优先级取第一个，其余值记入备注或暂存字段以便追溯。如果目标侧选项集合更小，缺失的选项要么在目标侧补充创建，要么映射到语义最接近的选项，并在映射表中记录对应关系。这类规则要在试迁移中用多选全选的样本工单验证，确认没有取值被静默丢弃。
试迁移要跑几轮才算够，样本工单选多少合适？
轮次取决于字段数量和定制程度，常见是两到三轮，不必追求一轮通过。样本工单的数量以覆盖每一类字段和边界取值为准，而不是按固定比例抽取：每类字段至少要有正常取值、空值、边界值（超长文本、多选全选、已停用选项、离职用户填写的用户字段）各若干条。每轮试迁移后把问题回填到映射表的验证状态列，修复规则后复跑受影响的字段，复验通过再扩大批次。
字段级校验数据都对上了，业务侧还是反馈不好用，问题可能出在哪？
常见原因是字段配置层面的差异，而不是取值本身。例如目标侧的选项排序与源侧不同，导致看板分组或筛选顺序变化；必填范围配置过宽，影响了其他项目的工单创建；字段可见性没有跟随原屏幕方案配置，使用者在新建工单时看不到该字段。这类问题在数量与取值分布对比中看不出来，需要让实际使用字段的人参与业务级校验，按关键流程走一遍、打开依赖该字段的报表确认出数正常。
迁移中途发现问题决定回退，需要提前做哪些准备？
回退的前提是源数据可恢复，所以切换前要保留 Jira 侧的数据快照或完整备份，明确快照时间点与覆盖范围，并约定切换窗口，窗口内暂停源系统写入，避免迁移期间产生新数据造成两边不一致。回退动作本身建议预演一次，确认恢复流程耗时在可接受范围内。问题修复后回到映射表修正规则，重新执行小批量试迁移，复验通过再扩大批次，而不是直接进入全量迁移。
