Jira 迁移数据冻结是在正式导出与导入之间设置一段停止写入的窗口，目的是让导出包对应一个确定的数据时点。执行时先划定冻结对象与起止时间，再按“通知—只读—导出—校验—解冻或切换”的顺序推进；冻结范围要对齐迁移工具实际读取的范围，冻结期内的必要变更登记为增量，核验通过后再恢复写入或进入切换。
要点总览（TL;DR）
- 冻结范围以迁移工具实际读取的对象为准：项目与问题、评论与附件、状态与工作流字段、用户与权限映射信息，逐项对照确认，避免冻结范围小于读取范围。
- 冻结窗口长度由数据量、导出耗时、校验耗时和异常处理余量倒推，附件多、单文件大的实例需要更长窗口，并与业务方确认可接受的中断时长。
- 冻结期内按通知、切换只读、执行导出、完整性初检的顺序操作，必要变更统一登记为增量，切换后按登记表补迁或人工核对。
- 核验以问题总数与项目分布、附件数量与大小、评论数、状态分布等可复现证据为准，抽样比对验证字段映射，差异逐条闭环后才解冻或切换。
- 导出失败、差异超出可接受范围或目标环境不可用时立即停止，恢复 Jira 写入并通知业务方，整理原因后重新排期，不复用未确认的旧导出包。
冻结哪些数据：来源、目标与范围界定
冻结的方向必须明确：Jira 是数据来源，替换后的研发管理平台是接收方。冻结动作发生在 Jira 一侧，即停止对将被迁移的数据写入；目标系统在导入阶段通常处于准备或试运行状态，不承担冻结期的业务写入。方向颠倒会让团队误以为目标系统需要停用，也会让冻结清单失去依据。
冻结对象应按迁移工具会读取的数据逐项列出，常见包括：
- 项目与问题：项目基本信息、问题主记录、问题类型、问题键与创建/更新时间。
- 评论与附件：评论正文与作者、附件文件及其大小、附件与问题的对应关系。
- 状态与工作流字段：状态值、状态流转历史、工作流配置、字段配置与字段值。
- 用户与权限映射所需信息：用户、用户组、权限配置，以及问题级安全设置等影响可见性的信息。
有些数据可以不进入冻结范围，但需要写明处理方式。例如已归档且不再变更的历史项目，可以在冻结前确认其最后修改时间，按静态数据单独导出；外部集成实时写入的数据（如监控告警自动建单、外部表单提交）应在冻结前关闭或改为暂存，冻结结束后再决定是否补录。把“不冻结”当成“不迁移”是常见误解，边界说明里要同时写清这两件事。
冻结范围与迁移工具读取范围对齐，可以用一张对照表核对：左列写迁移工具文档或试迁移中确认会读取的对象，右列写本次冻结清单中的对应项，逐项标注“已覆盖”“不适用（附原因）”“待确认”。试迁移是验证这张表最直接的方式：用一小批项目跑一遍导出，检查导出包中出现的对象类型，再回填对照表。对照表中出现“待确认”的项，应在冻结开始前解决，避免冻结范围小于读取范围。
交付物是一份冻结对象清单与范围边界说明，包含冻结项、排除项、排除原因和处理方式，并由迁移负责人和 Jira 管理员共同确认。
冻结前要准备什么：输入、依赖与时间窗
冻结窗口长度没有通用标准，应由三项耗时倒推：数据量与导出耗时、校验耗时、异常处理余量。问题数和附件体积往往决定导出时长，附件多、单文件大的实例需要更长的导出与传输时间；校验耗时取决于核验项数量和抽样规模。排期时先估算导出与校验的基准时长，再留出一定比例的缓冲，用于处理导出失败重跑或差异复核。窗口过短会迫使团队在核验未完成时解冻，窗口过长则影响业务正常提报，需要与业务方共同确认可接受的中断时长。
启动冻结前需要准备以下输入和依赖：
- 迁移工具及其版本，以及该版本对 Jira 版本的兼容说明；具体兼容范围应向工具提供方确认，不凭经验假定。
- 目标系统环境：导入用的环境地址、账号与空间，是否已按试迁移结果完成配置准备。
- 账号权限：执行导出的 Jira 管理员账号、可读取全部待迁移项目的权限，以及目标系统的导入权限。
- 通知渠道：面向业务方的公告渠道、冻结期问题反馈入口、例外申请的联系人。
冻结公告需要写明起止时间（含时区）、受影响的项目与操作范围、冻结期间哪些动作仍可进行（如查看、搜索）、例外申请方式与审批人。公告应提前发出，给业务方留出在冻结前完成紧急提报的时间。
冻结前还应完成两项动作：一是数据清理，例如关闭长期挂起的无效问题、合并重复项目、确认附件无缺失，减少导出包中的噪声；二是备份，对 Jira 数据库与附件目录做一次完整备份，并记录备份时间点。备份既是回退的基础，也是核验时对照的参照。排期表与依赖清单应把上述输入逐项列为“已就绪/待办”，全部就绪后再进入冻结。
冻结窗口内怎么执行：只读、导出与增量登记
冻结期内的操作按固定顺序进行，每一步都有明确的完成标志：
- 发出冻结开始通知，确认业务方已收到，记录通知时间。
- 将 Jira 切换为只读或收回写入权限，验证普通用户无法新建、编辑、评论和上传附件，记录切换时间点。
- 执行导出，记录导出开始与结束时间、导出工具版本、导出参数和导出包存放位置。
- 对导出包做完整性初检，如文件可解压、记录数可读取，然后进入核验环节。
角色分工建议如下：Jira 管理员负责只读切换、权限调整和导出执行；迁移负责人负责整体排期、核验组织和差异裁决；项目负责人确认本项目数据范围与业务优先级；业务方联系人负责传达公告、收集例外申请。分工写进执行记录，出现问题时能快速找到对应责任人。
冻结期间如果出现必须变更的情况，例如线上故障需要补录问题、合规要求必须更新某条记录，处理方式是登记而非放开写入：由业务方联系人提交例外申请，说明对象、内容和紧急程度，迁移负责人审批后，由管理员在受控条件下操作，并在增量变更登记表中记录变更时间、对象、操作人和原因。切换后按登记表逐条补迁或人工核对。登记表本身要能回答三个问题：改了什么、什么时候改的、由谁确认已补录。
导出包需要与时间戳、版本号建立对应记录：导出包文件名中包含导出日期与批次号，执行记录中写明对应的 Jira 版本、迁移工具版本和只读切换时间。这样在核验发现差异时，可以判断差异来自导出时点之前的数据，还是冻结期内的增量变更。
冻结后如何核验：证据与通过标准
核验的目标是用可复现的证据判断导出包是否完整，而不是凭导入过程没有报错就认定通过。建议按以下核验项逐项比对来源与导出结果：
| 核验项 | 比对方式 | 通过标准示例 |
|---|---|---|
| 问题总数与项目分布 | Jira 中各项目问题计数与导出包统计对比 | 各项目计数一致，差异项已逐条说明 |
| 附件数量与大小 | 附件文件数、总字节数与导出包对比 | 数量一致，大小差异在可解释范围内 |
| 评论数 | 按项目统计评论条数对比 | 计数一致或差异已登记 |
| 状态分布 | 各状态下的问题数对比 | 分布一致，状态映射无遗漏 |
| 字段与配置 | 问题类型、工作流、字段配置清单对比 | 清单逐项对应，未对应项有处理结论 |
抽样比对用于验证内容层面的正确性，计数一致不能保证字段值映射正确。抽样可按项目分层：每个项目抽取一定数量的问题，覆盖不同问题类型、不同状态和含附件的记录，检查标题、描述、自定义字段值、评论和附件是否可读且内容对应。抽样比例按数据量和风险等级设定，数据量大时可采用分层抽样，高风险项目提高抽样量。抽样发现的问题要区分是单条记录问题还是系统性映射问题，后者需要扩大抽样或全量复核。
差异记录应包含差异项、来源值、导出值、初步原因和处理路径。处理路径通常有三类：重导（导出包本身缺失或损坏）、补录（冻结期增量或个别遗漏）、人工确认（差异可解释且业务方认可）。每条差异都要有结论和确认人，未闭环的差异不能带入切换。
核验通过的判定条件是：核验项全部完成比对，差异均已记录并有处理结论，抽样结果未发现系统性映射错误。满足条件后才解冻 Jira 写入或进入切换；任一条件不满足，应停留在核验阶段处理，不提前恢复写入。
冻结执行记录、增量登记和核验结果需要在一个团队可访问的位置留存，便于迁移期间和切换后追溯。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并迁移用户、用户组及问题类型、工作流、字段配置、权限配置等系统配置，这些对象正好对应上述核验项；团队可以把冻结记录与核验结论作为迁移工作项或文档沉淀在研发管理平台中，与迁移批次对应管理。具体工具能力与版本兼容范围以官方说明和实际环境确认为准。
何时解冻或回退：停止条件与恢复路径
冻结前就应约定停止条件，触发后立即停止推进，不在异常状态下继续导出或切换。常见触发条件包括：导出失败且短时间内无法修复；核验差异超出事先约定的可接受范围，例如问题计数差异无法解释或附件大面积缺失；目标环境不可用，导入无法进行；关键权限或账号在冻结期内失效，导致导出无法完成。
触发停止后的回退动作按顺序执行：
- 暂停导出或导入操作，保留当前导出包和日志，不做覆盖。
- 恢复 Jira 写入，撤销只读设置或恢复用户权限，验证普通用户可以正常新建和编辑。
- 通过原通知渠道告知业务方冻结已解除、恢复时间和后续安排。
- 整理异常记录，明确原因和修复动作，再重新排期冻结。
重新排期时注意几点：上次导出包不要直接复用，除非确认数据未变；增量登记表中的变更需要在新的冻结窗口前处理完毕；如果异常由数据量或附件体积引起，应调整窗口长度或分批迁移，而不是压缩核验时间。回退不是失败，而是把问题暴露在切换之前。
如果核验通过并进入切换，过渡期通常安排为：目标系统开始承接新业务写入，Jira 保持只读一段时间供查询和对照，冻结期登记的增量按登记表补迁或人工核对，确认无遗漏后再决定 Jira 的归档或下线时间。旧系统只读保留的时长按团队查询需求和合规要求确定，并在切换公告中写明。回退与恢复操作清单应包含触发条件、执行人、验证方式和通知对象，与冻结排期表一并归档。
常见问题
冻结期间业务方确实需要提报紧急问题，怎么处理才不影响迁移？
处理原则是登记而非放开写入。由业务方联系人提交例外申请，写明对象、内容和紧急程度，迁移负责人审批后由管理员在受控条件下操作，同时在增量变更登记表中记录变更时间、对象、操作人和原因。切换后按登记表逐条补迁或人工核对。这样既保留了业务连续性，也能让核验时区分差异来自导出时点之前的数据还是冻结期内的增量。
问题计数一致，是否就可以判定导出包完整？
计数一致只说明记录条数对得上，不能保证字段值映射正确。还需要抽样比对内容层面：按项目分层抽取不同问题类型、不同状态和含附件的记录，检查标题、描述、自定义字段值、评论和附件是否可读且内容对应。抽样发现的问题要区分单条记录问题还是系统性映射问题，后者需要扩大抽样或全量复核。
冻结窗口排多长比较合适？
没有通用标准，应按三项耗时倒推：数据量与导出耗时、校验耗时、异常处理余量。问题数和附件体积往往决定导出时长，校验耗时取决于核验项数量和抽样规模。先估算基准时长，再留出缓冲用于导出失败重跑或差异复核。窗口过短会迫使团队在核验未完成时解冻，窗口过长则影响业务正常提报，需要与业务方共同确认可接受的中断时长。
核验发现差异后，什么情况下重导、什么情况下补录？
按差异来源判断：导出包本身缺失或损坏，走重导；冻结期增量或个别记录遗漏，走补录；差异可解释且业务方认可，走人工确认。每条差异都要记录来源值、导出值、初步原因、处理路径和确认人，未闭环的差异不能带入切换。
回退后重新冻结，上次的导出包还能用吗？
通常不复用，除非确认数据未变。重新排期前要处理完增量登记表中的变更，并检查异常原因：如果由数据量或附件体积引起，应调整窗口长度或分批迁移，而不是压缩核验时间。上次导出包和日志保留备查，但不作为新批次的核验依据。
冻结执行记录和核验结果放在哪里便于追溯？
放在团队可访问、能按迁移批次对应管理的位置。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并迁移用户、用户组及问题类型、工作流、字段配置、权限配置等系统配置，这些对象与上述核验项对应；团队可以把冻结记录与核验结论作为迁移工作项或文档沉淀在研发管理平台中。具体工具能力与版本兼容范围以官方说明和实际环境确认为准。
