Confluence 迁移切换规则要回答五个判定问题：何时切、切什么、谁批准、怎么验、何时退。它适用于来源和目标平台已经确定、进入切换阶段的团队。规则需要把来源侧写入冻结、分批放行、核验证据和回退窗口写成可执行的条件，避免一次性全量切换后问题难以定位。下文按范围界定、前置依赖、分批执行、核验留证、回退停止和协作落地六个环节展开，并说明这些规则如何借助 ONES 的工作项与文档承载。
要点总览（TL;DR）
- 切换规则要写成可判定的条件：何时切、切什么、谁批准、怎么验、何时退，逐批复用而不是每次临场决定。
- 按空间、团队或业务域划分批次，低依赖空间先试点；每批设置独立冻结窗口，全量迁移后完成增量追平再进入审批。
- 放行门槛用核验项量化：页面数量与关键页面抽样、附件可打开性、权限可见范围、链接可用性，核验记录作为签字依据。
- 回退条件提前量化并约定来源侧只读保留时长，触发回退或核验连续不通过时暂停后续批次，评审后再恢复排期。
- 把批次、核验项和审批登记为工作项，方案与证据在文档中保留版本，形成可追溯的切换档案。
来源、目标与切换范围怎么界定
切换规则的第一项工作是把迁移方向和覆盖对象写清楚。来源是 Confluence，需要区分云版与数据中心版：两者在导出方式、API 能力和权限模型上存在差异，冻结手段和导出路径要分别核实。目标是已经确定的替代平台，本文不讨论选型问题。如果目标为 ONES Wiki，官方资料说明可迁移空间、页面、附件和权限结构，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注也在迁移范围内；常用宏的具体覆盖清单仍需在实施前逐项确认。
范围界定要落到对象类型和批次两个维度。对象类型维度回答“这次切什么”，建议逐项标注纳入状态：
| 对象类型 | 是否纳入本次切换 | 说明 |
|---|---|---|
| 空间与页面正文 | 纳入 | 按批次划分，逐批冻结与迁移 |
| 附件与图片 | 纳入 | 核验数量、大小与可打开性 |
| 评论与批注 | 视目标平台支持情况确定 | 需在实施前确认映射方式 |
| 空间权限与页面权限 | 纳入 | 切换后抽查可见范围 |
| 内部链接与外部引用 | 纳入核验 | 检查跳转是否可达 |
| 历史版本 | 按需确定 | 保留策略需与业务方确认 |
批次维度回答“分几次切”。常见做法是按空间、团队或业务域划分，把访问频率低、依赖关系少的空间放在前面作为试点批次，把跨团队共用、外部引用多的空间放在后面。每个批次都要列出纳入清单和暂不纳入清单，暂不纳入的对象要写明原因和后续安排，避免切换当天出现“以为已经迁移”的遗漏。版本与导出方式属于实施前必须核实的前提条件，规则文本中应标注“待核实”而不是直接假定可用。
切换前需要哪些输入与依赖
切换规则能否执行，取决于前置输入是否齐备。建议在规则发布前完成一张前置条件核对表，每项标注责任人与完成状态，未完成项对应的批次不得进入冻结。核对表至少覆盖以下内容：
- 空间盘点与结构映射结果：已确认每个空间的目标位置、页面层级对应关系，以及字段和模板的转换方式。映射结果不完整时，核验阶段无法判断“迁移是否正确”。
- 来源侧写入冻结方案：明确冻结的开始时间点、冻结范围（整个实例还是单个空间）、冻结期间哪些角色可以例外写入，以及冻结如何通知到全体使用者。
- 目标平台准备状态：账号是否已开通、用户组与权限模型是否按映射结果配置、目录结构是否已建好。权限模型未就绪就切换，核验时无法区分“迁移遗漏”和“配置缺失”。
- 通知、培训与支持窗口：切换期间使用者去哪里提问、遇到问题找谁、支持窗口覆盖哪些时段。分批切换时，每批都要有对应的通知节奏。
- 迁移工具或导出导入方式的可用性验证：试迁移是否跑通、单批数据量是否在工具可处理范围内、失败重试的处理方式是否明确。ONES 的迁移方式包括批量迁移与数据包导入，具体操作方式与限制需在实施前核实。
这些输入之间存在依赖顺序：盘点与映射是冻结方案的前提，冻结方案又是批次时间窗口的前提。规则中可以把依赖关系写成“前置项未关闭则批次不启动”的判定语句，让执行人不必临场判断。
分批切换的执行规则怎么定
分批切换的核心是把“冻结—迁移—追平—审批—放行”串成一条每批可复用的流程。建议每批设置独立的时间窗口，窗口内完成以下动作：
- 冻结来源侧写入：在约定时间点对批次内空间执行冻结，通知使用者停止编辑。冻结的解除条件要写清楚——通常在核验通过并完成放行后解除，或回退完成后解除。
- 执行全量迁移：按已确认的映射结果迁移页面、附件、权限等对象。全量迁移期间来源侧保持只读，避免迁移过程中数据继续变化。
- 增量追平：对冻结前最后一段时间内产生的变更做补充迁移，直到来源侧与目标侧的内容一致。增量追平的具体机制需与迁移工具或服务方确认，规则中应写明“追平完成的判定方式”，例如差异清单清零。
- 审批放行：由指定审批角色依据核验结果签字放行。审批人应对本批次的范围和核验项有判断能力，通常由空间负责人加迁移负责人共同确认。
- 解除冻结并切换入口：放行后解除来源侧只读，把使用者引导到目标平台，并公告本批次完成。
切换期间新旧平台并行读写的处理需要提前约定。较稳妥的做法是：冻结后来源侧只读、目标侧可写，使用者从目标平台继续工作；如果业务上必须保留来源侧写入，则要明确哪些内容会在追平阶段被覆盖，以及冲突时以哪一侧为准。并行期越长，追平成本越高，规则中应给出并行期的上限。
| 批次 | 时间窗口 | 冻结动作 | 审批人 | 放行条件 |
|---|---|---|---|---|
| 试点批次（低依赖空间） | 示例：第 1 周周二至周四 | 周二 18:00 起来源侧只读 | 空间负责人 + 迁移负责人 | 核验清单全部通过 |
| 第二批（部门级空间） | 示例：第 2 周 | 窗口首日 18:00 起只读 | 同上 | 核验通过且试点批次无遗留问题 |
| 后续批次（跨团队共用空间） | 按前批结果排期 | 同上 | 同上，增加业务方代表 | 核验通过且回退条件未触发 |
表中时间仅为演示情景，实际排期应结合空间数量、工具处理能力和业务低峰期确定。ONES 方案层面建议把迁移工具、原厂服务和分阶段切换结合起来，并在正式迁移前确认数据范围、功能匹配和系统适配，这一做法与上述分批放行思路一致。
切换后的核验项与证据怎么留
核验是放行的门槛，也是回退判断的依据。每批切换后应按同一口径执行核验，并把结果留存为可追溯的证据。建议的核验项包括：
- 页面数量与关键页面抽样比对：对比来源侧与目标侧的页面总数，并对每个空间抽取关键页面逐项检查标题、层级和正文内容。
- 附件数量、大小与可打开性：核对附件总数与总容量，抽样打开常见格式的附件，确认下载和预览正常。
- 权限继承与可见范围抽查：选取若干页面，用不同角色的账号验证可见性是否符合原空间权限设置，重点检查是否存在越权可见。
- 内部链接与外部引用可用性：检查页面间跳转、目录链接和外部引用是否可达，记录失效链接清单并明确修复责任。
- 核验记录留存：每项核验保留执行人、执行时间、抽样范围和结果，截图或导出报告作为附件归档，作为审批签字的依据。
核验清单应给出明确的通过标准，例如“关键页面抽样全部一致”“附件可打开率 100%”“无越权可见项”。标准写成可判定的条件，审批人才能据此签字，回退条件也才有量化基础。核验未通过时，先区分是迁移遗漏还是配置问题，前者进入修复重迁，后者进入配置修正，两类问题的处理路径不同。
回退与停止条件怎么设
回退规则要在切换开始前写好，而不是等问题出现再讨论。触发条件建议量化，并与核验项对应：
| 触发条件 | 判定口径 | 处置动作 |
|---|---|---|
| 核验不通过比例超限 | 抽样页面不一致比例超过约定阈值 | 暂停放行，修复后重新核验 |
| 关键页面缺失 | 任一关键业务页面在目标侧无法找到 | 立即停止本批，评估回退 |
| 权限越权 | 抽查发现非授权账号可见受限内容 | 立即停止本批，优先修复权限 |
| 附件大面积不可打开 | 抽样可打开率低于约定阈值 | 暂停放行，排查迁移完整性 |
回退窗口与来源侧保留时长要一并约定。常见做法是来源侧在切换后保留一段只读期，期间数据不删除，回退时可直接恢复访问；只读期结束后再按归档策略处理。回退执行步骤应写明责任人、操作顺序和验证方式，例如：确认回退决定→恢复来源侧写入→通知使用者返回原平台→记录回退原因与影响范围→安排复盘。停止后续批次的条件同样要写清楚，例如本批触发回退或核验连续两次不通过时，后续批次暂停，待评审确认修复方案后再恢复排期。
规则如何落到协作与文档管理上
切换规则本身需要被跟踪，否则批次、核验和审批容易散落在聊天记录和临时表格里。落地方式可以分三层：
第一层是把批次登记为可跟踪的工作项。每个批次一个工作项，字段包括批次名称、覆盖空间、冻结时间、审批人、核验状态和回退标记。核验项和回退条件作为子项或检查项挂在批次下，完成一个勾选一个，状态变化自动反映批次进度。这样切换负责人看到的是整体排期，而不是逐条追问。
第二层是用文档承载方案与证据。切换方案、核验清单、回退预案放在同一文档空间，保留版本记录；每批的核验记录和审批签字作为文档附件或子页面归档，形成可追溯的切换档案。文档版本与批次工作项关联后，评审时可以直接对照“当时依据的是哪一版规则”。
第三层是在评审节点完成放行与同步。审批人在批次工作项上完成放行签字，结果同步给相关团队；触发回退时，回退决定和原因同样记录在工作项和文档中，供后续批次参考。ONES 的工作项与文档能力可以承载上述流程：批次作为工作项跟踪状态，切换方案与核验记录在文档中留存版本，审批结果与回退记录形成可追溯的切换档案。对于目标平台为 ONES Wiki 的团队，迁移后的知识内容与切换档案可以放在同一协作环境中管理，减少切换期在多个系统之间来回查找的成本。
规则落地后还需要一次演练验证：选取一个低风险空间走完冻结、迁移、核验、放行全流程，检查工作项字段是否够用、核验清单是否有歧义、回退步骤是否可执行。演练中发现的问题在正式批次前修订进规则文档，并保留修订记录。
常见问题
Confluence 云版和数据中心版的切换规则要分开写吗？
建议分开写，至少在冻结方式和导出路径两处分别核实。云版与数据中心版在导出方式、API 能力和权限模型上存在差异，同一套冻结动作未必两边都适用。规则文本可以先给出通用框架，再为两种部署形态各列一份前提核实清单，标注哪些动作已确认、哪些待实施前验证。目标平台一侧的迁移范围也应以实际核实结果为准，例如 ONES Wiki 的官方资料说明可迁移空间、页面、附件和权限结构，常用宏的具体覆盖清单仍需逐项确认。
增量追平期间来源侧还能继续编辑吗？
通常不建议。冻结后来源侧保持只读，目标侧开放写入，使用者从目标平台继续工作，这样追平阶段只需处理冻结前最后一段时间的变更。如果业务上必须保留来源侧写入，规则中要写明哪些内容会在追平阶段被覆盖、冲突时以哪一侧为准，并给出并行期上限。并行期越长，追平成本和冲突概率越高。追平完成的判定方式也要提前约定，例如以差异清单清零为准，具体机制与迁移工具或服务方确认。
核验没通过时，应该修复重迁还是直接回退？
先区分问题类型再决定。迁移遗漏类问题，例如页面缺失、附件未迁全，通常进入修复重迁；配置类问题，例如权限映射错误、目录结构不符，进入配置修正后重新核验。只有触发预先量化的回退条件时才启动回退，例如关键业务页面在目标侧无法找到、抽查发现非授权账号可见受限内容。两类问题的处理路径不同，规则中应分别写明责任人和处理时限，避免核验不通过后停在原地。
来源侧只读期应该保留多久？
没有统一时长，取决于回退窗口和归档策略。常见做法是切换后来源侧保留一段只读期，期间数据不删除，回退时可直接恢复访问；只读期结束后再按归档策略处理。规则中要写清只读期的起止时间、由谁决定延长或结束，以及只读期内是否允许例外写入。只读期覆盖回退窗口即可，过长会增加双环境维护成本，过短则回退时缺少可用数据。
切换规则怎么跟踪，避免批次和审批散落在聊天记录里？
把规则拆成可跟踪的对象：每个批次一个工作项，记录覆盖空间、冻结时间、审批人、核验状态和回退标记；核验项与回退条件作为子项挂在批次下，完成一项更新一项。切换方案、核验清单和回退预案放在同一文档空间并保留版本，每批的核验记录与审批签字归档为附件或子页面。ONES 的工作项与文档能力可以承载这套流程，评审时能直接对照当时依据的规则版本。正式批次前建议选一个低风险空间走完整流程演练，检查字段是否够用、清单是否有歧义。
