Jira 迁移数据冻结的目标，是让源端在迁移窗口内保持同一份可追溯的快照。做法是先划定冻结范围，再按“只读公告—停止写入—导出快照—核对基线—试迁移—正式迁移—差异复核—解冻”的顺序推进，每一步留下导出时间、记录数、附件数和字段抽样等证据，并提前约定回退点。冻结期间源端保持只读，迁移完成后才恢复写入。
要点总览（TL;DR）
- 冻结范围要落到对象清单：项目、问题与子任务、评论与历史、附件、工作流状态、自定义字段、用户与权限，逐项标注数量口径和是否纳入本次迁移。
- 执行顺序是只读公告—停止写入—导出快照—核对基线—试迁移—正式迁移—差异复核—解冻，每一步保留时间戳和产出物。
- 冻结是否有效靠证据判断：导出日志、记录数与附件数对比、字段值抽样、附件可打开性检查，差异按数量、字段映射、附件缺失、权限四类记录并确认修复。
- 解冻的前置条件是正式迁移完成且核验全部通过；关键数据缺失或映射错误无法短期修复时触发回退，源端恢复写入并通知相关方。
- 按项目分批冻结可以先用试点项目验证流程，代价是冻结窗口拉长、需要维护多批快照记录；一次性全量冻结窗口更短，但对业务侧影响更集中。
冻结什么：Jira 迁移的源目标与范围界定
冻结范围要落到对象清单上，而不是笼统地说“冻结 Jira”。先确认源端实例的部署形态与版本（Jira Server、Data Center 或 Cloud），记录实例地址、版本号和当前用户数，再与目标系统建立对应关系：哪个 Jira 项目迁到目标系统的哪个项目空间，哪些用户组对应哪些角色。这份对应关系是后续导出、核验和解冻判断的共同依据。
冻结对象建议按以下类别逐项列出，并标注数量口径：
| 对象类型 | 数量口径 | 是否纳入本次迁移 | 备注 |
|---|---|---|---|
| 项目 | 项目数、项目键列表 | 是/否 | 按项目分批时注明批次 |
| 问题与子任务 | 按项目统计的问题总数、子任务数 | 是/否 | 含已关闭问题 |
| 评论与历史记录 | 评论条数、变更历史条数 | 是/否 | 历史记录影响审计追溯 |
| 附件 | 附件个数、总容量 | 是/否 | 需检查可打开性 |
| 工作流状态 | 状态数、流转规则数 | 是/否 | 与目标状态映射相关 |
| 自定义字段 | 字段数、字段类型分布 | 是/否 | 含字段配置方案 |
| 用户与权限 | 用户数、用户组数、权限方案数 | 是/否 | 含项目角色 |
按项目或问题类型分批冻结是常见取舍。项目数量多、业务节奏不同的团队，可以先冻结一个试点项目，验证导出、映射和核验流程后再扩展到其他项目；代价是冻结窗口被拉长，期间需要维护多批次的快照记录。一次性全量冻结的窗口更短，但对业务侧的影响更集中，需要提前协调停写时段。两种方式都应在范围清单里写明批次划分和每批的冻结起止时间。
同时要明确不在本次冻结范围内的内容。历史归档项目、已停用项目、Jira 插件的私有数据、与外部系统的实时集成数据，通常需要单独评估。ONES 的迁移实践也提示，企业已有的定制场景和插件依赖需要在迁移前逐项评估，不能直接假设所有插件都能一一对应。把这些排除项写进清单，可以避免迁移中途因范围争议反复调整冻结状态。
冻结前要准备什么：输入、依赖与责任分工
冻结动作启动前，需要把时间、权限、人员和基线数据四类输入准备到位。缺少任何一项，冻结都容易变成“公告发了但数据还在变”的状态。
时间安排方面，先确定冻结窗口的起止时间，包括只读公告的发布时间、停止写入的生效时间、导出执行时间、试迁移与正式迁移的时间段，以及预计解冻时间。窗口长度要覆盖导出、核对、试迁移和差异修复，不能只按导出耗时估算。业务侧沟通应说明冻结期间哪些操作会受限、遇到紧急问题走什么通道，并指定业务确认人。
权限与工具方面，准备具备管理员权限的账号，确认导出方式（系统自带导出、迁移工具或原厂服务）、导出文件的存储位置和访问控制。导出文件包含问题、附件和用户信息，存储位置需要符合团队的数据管理要求。若使用 ONES 的 Jira 迁移能力，迁移范围覆盖用户、用户组、系统配置以及项目、问题类型、工作流、字段配置、权限配置等，具体配置项需要在准备阶段逐项确认。
责任分工建议至少明确三个角色：迁移负责人统筹窗口安排和导出执行；业务确认人负责确认冻结范围、抽样结果和差异处理结论；目标系统配置人负责目标端的字段、状态、权限配置和试迁移环境准备。角色可以兼任，但每项任务要有唯一负责人。
基线数据在导出前采集，作为后续核验的对照。基线清单至少包括：各项目问题总数与子任务数、附件个数与总容量、关键自定义字段的抽样值、用户数与用户组数、工作流状态列表。基线采集时间要记录到分钟，并与导出时间戳区分开。
| 检查项 | 负责人 | 完成时点 | 产出物 |
|---|---|---|---|
| 冻结窗口与只读公告确认 | 迁移负责人 | 冻结前 3 个工作日 | 公告文本、窗口时间表 |
| 管理员权限与导出方式确认 | 迁移负责人 | 冻结前 2 个工作日 | 权限清单、导出方案 |
| 目标端字段与状态映射初稿 | 目标系统配置人 | 冻结前 2 个工作日 | 映射表初稿 |
| 基线数据采集 | 迁移负责人 | 停止写入前 | 基线记录表 |
| 业务确认人指定与通知 | 迁移负责人 | 冻结前 3 个工作日 | 联系人清单 |
冻结怎么执行：从只读公告到快照导出的操作顺序
执行顺序的核心是让“停止写入”先于“导出快照”，并让每个动作都有时间戳和产出物。推荐按以下步骤推进：
- 发布冻结公告并设定只读起始时间。公告写明冻结范围、只读开始时间、预计解冻时间、紧急问题联系人和处理通道。只读起始时间应留出缓冲，避免公告刚发就立即停写导致业务侧来不及处理在途事项。
- 停止写入。通过权限配置限制普通用户在冻结范围内的创建与编辑操作，保留管理员和迁移负责人的必要权限。同时暂停与冻结项目相关的自动化规则、通知和外部集成写入，防止后台任务在导出期间修改数据。停写生效后，记录生效时间和操作人。
- 执行导出并记录导出时间戳与导出范围。导出前再次确认导出范围与冻结范围清单一致，导出完成后记录导出开始与结束时间、导出文件名称、文件大小和覆盖的项目列表。
- 导出后立即核对记录数与附件数。将导出结果与基线数据对比，问题数、子任务数、评论数、附件个数出现差异时先暂停后续步骤，查明是基线采集口径问题还是导出遗漏。
- 安排试迁移与正式迁移。试迁移在冻结窗口内先行执行，用试点项目验证字段映射、状态流转和附件还原；试迁移通过后再执行正式迁移。试迁移与正式迁移之间如需修复映射配置，应在目标端调整，避免重新打开源端写入。
每一步的产出物包括公告记录、停写操作记录、导出日志、基线对比结果和试迁移核验记录。这些产出物既是冻结有效的证据，也是解冻判断的输入。ONES 的迁移方案建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，这一建议与上述“先试迁移再正式迁移”的顺序一致。
冻结期间如何核验：证据、抽样与差异处理
核验要回答两个问题：源端在冻结期间是否真的没有变动，迁移到目标端的数据是否与快照一致。前者靠停写记录和导出时间戳，后者靠数量对比、字段抽样和附件检查。
核验证据建议覆盖四类：导出日志与时间戳，证明快照的时点；记录数对比，包括问题、子任务、评论、附件和用户数；字段值抽样，选取关键自定义字段和状态字段逐条比对；附件可打开性检查，随机抽取附件确认能正常下载和打开。权限差异单独核对，包括项目角色、用户组和字段级权限。
抽样比例按数据量和风险确定。问题数量在千级以内时，可按项目抽取固定条数，覆盖不同问题类型和状态；数量更大时，按问题类型、状态、创建时间段分层抽样，每层抽取若干条。抽样对象应包含边界情况：最近修改的问题、附件较多的问题、使用特殊字符的字段值、已关闭和已重新打开的问题。
差异按四类记录：数量差异（源端与目标端记录数不一致）、字段映射差异（字段值被截断、选项值未匹配、日期时区偏移）、附件缺失（附件数量不足或无法打开）、权限差异（用户看不到应有项目或看到不应有项目）。每类差异记录发现时间、涉及对象、影响范围和责任人。
| 差异类型 | 典型表现 | 处理方式 | 确认人 |
|---|---|---|---|
| 数量差异 | 问题数或评论数与基线不符 | 核对导出范围与过滤条件，必要时重新导出 | 迁移负责人 |
| 字段映射差异 | 选项值未匹配、文本截断、日期偏移 | 调整映射规则后对受影响记录重新迁移 | 目标系统配置人 |
| 附件缺失 | 附件数不足或文件无法打开 | 检查导出包完整性，补导缺失附件 | 迁移负责人 |
| 权限差异 | 用户组与项目角色不对应 | 核对用户组映射表，修正目标端权限配置 | 业务确认人 |
差异修复后要重新核验受影响范围，并在核验记录表中登记修复结果和复核人。冻结期间的状态跟踪、核验记录和差异清单需要有一个统一承载位置，便于迁移负责人、业务确认人和目标系统配置人交接。ONES 支持围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，迁移过程中的核验记录和差异处理也可以在同一平台内跟踪，减少记录分散在多个表格中的情况。
什么时候解冻或回退：停止条件与恢复写入的判断
解冻的前置条件是正式迁移完成并通过核验：数量对比无未解释差异、字段抽样结果确认、附件检查通过、权限核对完成，且业务确认人签字确认。四项条件未全部满足时，源端继续保持只读，避免迁移未完成就恢复写入造成源端与目标端数据分叉。
回退的触发条件需要提前写清楚，常见的有：关键项目数据缺失且短期无法补齐；字段映射错误影响核心业务字段且修复方案需要重新设计；附件大批量无法还原；目标端权限配置无法在窗口内完成。触发回退时，由迁移负责人决定并通知业务确认人，源端恢复写入的操作包括解除创建与编辑限制、恢复自动化规则和通知，并记录恢复时间。
解冻后如果存在源端与目标端并行期，需要约定数据归属：新产生的问题和评论写入哪一端、源端只读期间积压的变更如何处理、并行期结束后源端是否转为归档只读。并行期越长，两端数据合并的成本越高，建议在解冻前就确定并行期的结束时间和切换规则。
| 判断项 | 触发条件 | 操作 | 责任人 |
|---|---|---|---|
| 解冻 | 正式迁移完成且核验全部通过 | 恢复源端写入，发布解冻通知 | 迁移负责人 |
| 延长冻结 | 差异修复未完成但可在窗口内解决 | 保持只读，更新预计解冻时间并通知业务侧 | 迁移负责人 |
| 回退 | 关键数据缺失或映射错误无法短期修复 | 恢复源端写入，暂停目标端切换，记录回退原因 | 迁移负责人与业务确认人 |
| 并行期结束 | 目标端稳定运行且业务侧确认 | 源端转为归档只读，明确数据归属 | 业务确认人 |
冻结、核验、解冻三个环节的记录应形成一条可追溯的链条：谁在什么时间停了写、导出了什么范围、核验发现了哪些差异、差异如何修复、最终由谁确认解冻。把这些记录放在统一的项目空间里跟踪，交接和复盘时可以直接按时间线查看，不必再向多方收集零散表格。
常见问题
冻结期间业务侧有紧急问题必须改 Jira，怎么处理？
冻结期间源端保持只读，紧急变更不建议直接放开写入，否则导出快照与源端数据会分叉。可行的做法是预先在公告里约定紧急通道：由迁移负责人评估影响，把紧急问题记录在冻结期间的变更清单里，等解冻后在源端或目标端补录，并注明补录时间和原因。如果紧急事项确实无法延后，需要由迁移负责人和业务确认人共同决定是否暂停本次迁移、恢复写入并重新安排窗口，同时记录这次中断对已导出快照的影响范围。
试迁移发现字段映射错误，需要重新导出源端数据吗？
通常不需要重新导出。字段映射错误属于目标端配置问题，应在目标系统调整映射规则，再对受影响的记录重新执行迁移，源端继续保持只读即可。需要重新导出的情况是导出范围本身有误，比如漏掉了某个项目或过滤条件不对，这时才回到导出步骤，并重新记录导出时间戳和范围。判断依据是差异类型：字段映射差异改配置，数量差异先核对导出范围与过滤条件。
冻结窗口应该留多长？只按导出耗时估算够不够？
不够。窗口要覆盖只读公告缓冲、停止写入、导出、基线核对、试迁移、正式迁移、差异修复和复核确认，导出只是其中一段。窗口过短会让差异修复没有余地，容易在核验未完成时被迫解冻；窗口过长则业务停写影响扩大。建议先按试点项目的实际耗时估算单批窗口，再结合批次划分确定总时长，并在公告中写明预计解冻时间，出现延期时及时更新通知。
解冻后源端和目标端并行一段时间，数据应该写在哪一端？
并行期的数据归属要在解冻前就约定清楚，常见做法是以目标端为唯一写入端，源端转为只读归档，只保留查询和追溯用途；源端只读期间积压的变更，在解冻前统一补录到目标端并登记。如果业务上确实需要两端同时写入，就要明确哪些类型的数据写哪一端、合并的时点和责任人，否则两端数据会越走越远。并行期越长，合并成本越高，建议同时确定并行期的结束时间和源端转归档只读的时点。
Jira 里的插件数据和定制字段，冻结时要不要一起纳入范围？
插件私有数据和定制字段需要单独评估，不建议默认全部纳入冻结范围。ONES 的迁移实践提示，企业已有的定制场景和插件依赖要在迁移前逐项梳理，不能直接假设所有插件都能一一对应。实际做法是先盘点插件实际使用情况，区分哪些数据有业务价值、哪些只是配置残留，把确认要迁移的部分写进范围清单并标注数量口径，其余部分列为排除项，避免迁移中途因范围争议反复调整冻结状态。
