Confluence 迁移切换需要按阶段推进：先确定源站、目标与迁移边界，再完成盘点与字段映射，用样本空间试迁移验证规则，随后在冻结写入的窗口内分批切换，并按清单核验证据；回退条件应在切换前书面约定。迁移后的文档与工作项需要衔接时，可在 ONES 中统一承载。
要点总览（TL;DR）
- 迁移切换按“定范围—做映射—样本试迁移—按清单验收—预设回退”五个阶段推进，每个阶段设通过条件后再进入下一阶段。
- 同名字段不默认等价：标题、层级、标签、权限组逐项确认两端含义，含义不同的单独列出处理规则并留对照记录。
- 样本空间优先选结构复杂、宏使用密集、权限交叉的空间，试迁移结果用于修正映射规则，通过后冻结为正式版本。
- 切换当天先冻结源站写入并通知团队，按批次迁移、逐批核验，源站保持只读直至回退窗口结束。
- 回退条件在切换前书面约定，按差异清单分布判断部分回退或整体回退，回退后修订规则并重新通过样本验证再切换。
迁移范围：先确定源站、目标与切换边界
迁移范围决定后续盘点、映射和验收的工作量，也决定切换窗口能否收敛。第一步应把“迁什么、迁到哪、哪些不迁”写成清单，由项目负责人和业务方共同确认后冻结，后续新增空间走变更流程，不临时扩大范围。
源站信息至少记录三项：Confluence 的部署形态（Cloud 或 Data Center）、版本号、当前使用的插件与外部集成。部署形态影响导出方式、API 可用性和迁移工具的接入条件；版本号影响页面存储格式与宏的兼容情况。这些信息建议在项目启动会上由运维或平台管理员提供，并附截图存档。
对象范围按空间逐项登记，每个空间标注是否迁移、迁移优先级和负责人。页面、附件、评论、历史版本分别列示，因为不同对象的迁移成本和校验方式不同。历史版本通常占用大量存储且校验复杂，是否保留应单独决策；评论和批注涉及协作上下文，建议纳入范围并明确保留形式。
目标平台一侧要确定目标空间结构：是沿用源站空间划分，还是按业务域重新组织。结构重组会改变页面层级和链接，需要在映射阶段同步设计，不能留到切换当天处理。若目标为 ONES Wiki，官方资料说明可迁移空间、页面、附件和权限结构，并保留团队原有的知识组织方式，具体范围仍应在正式迁移前确认。
明确不迁移的内容同样重要。常见项包括已归档且无人维护的空间、嵌入外部系统的页面片段、依赖定制插件的动态内容、仅作临时草稿的页面。每一项不迁移内容都要写明理由和后续处置方式，例如归档保留只读、由业务方另行导出、在目标端重建。
| 源对象 | 目标对象 | 是否迁移 | 说明 |
|---|---|---|---|
| 空间 A（研发文档） | 目标空间“研发” | 是 | 含页面、附件、评论 |
| 空间 B（已归档制度） | — | 否 | 源站保留只读，不进入本次切换 |
| 页面历史版本 | 待定 | 待确认 | 按存储与校验成本单独决策 |
| 外部嵌入看板 | 目标端链接或重建 | 部分 | 嵌入内容改为链接引用 |
切换前输入：盘点、映射与依赖确认
切换前的准备工作产出两份核心文档：盘点表和字段映射表。盘点表回答“有什么”，映射表回答“怎么对应”。两份文档都应在试迁移前完成初版，并在试迁移后修订。
盘点表按空间组织，每个空间记录页面数量、附件总大小与数量、评论数、权限组数量、使用的宏类型及出现次数、外部链接数量。宏的盘点尤其关键，因为宏往往决定页面能否在目标端正常呈现。官方资料说明 ONES Wiki 支持迁移页面正文、附件、图片、常用宏及批注，宏的覆盖范围为常用宏，非常用宏和定制场景需要在迁移前逐项评估，不能假设所有插件都能一一对应。
字段与结构映射要逐项确认含义，而不是按名称直接对应。同名字段在两端含义不同时，单独列出处理规则。常见差异包括：
- 标题：源端允许的字符与长度限制可能与目标端不同，需制定截断或改写规则，并保留原标题到新标题的对照记录。
- 层级：源端页面树深度较大时，目标端可能按空间加目录组织，需要确定父页面归属规则。
- 标签：源端标签用于检索和分类，目标端若以目录或属性替代，应建立标签到目录的映射表。
- 权限组：源端按用户组授权，目标端权限模型可能区分空间权限与页面权限。官方资料说明 ONES Wiki 迁移数据包括用户、用户组、空间权限与页面权限，映射时需确认用户组是否同名同义、是否存在跨组继承差异。
宏与外部嵌入需要给出替代或降级方案。可用的处理方式包括：目标端有等价宏的直接替换；无等价宏的转为静态内容或附件；动态嵌入改为链接引用并注明原系统地址；无法处理的宏列入差异清单，由页面负责人确认接受降级或重建。
| 源字段/结构 | 目标字段/结构 | 映射规则 | 需确认事项 |
|---|---|---|---|
| 页面标题 | 页面标题 | 保留原文，超长时截断并记录 | 目标端长度限制 |
| 页面树层级 | 空间目录/父页面 | 按一级目录对应空间分组 | 深度超过限制的页面归属 |
| 标签 | 目录或属性 | 建立标签到目录对照表 | 多标签页面的主分类选择 |
| 用户组权限 | 空间权限/页面权限 | 同名组直接对应，异名组人工确认 | 继承关系差异 |
| 常用宏 | 目标端等价宏 | 逐类替换 | 非常用宏的降级方式 |
迁移工具与账号权限是常被低估的依赖。需要提前确认：迁移采用批量迁移还是数据包导入，官方资料说明两种方式均支持，具体选择结合数据规模与实施安排确定；执行账号是否具备源站全量读取权限和目标端空间管理权限；迁移期间是否需要临时提升权限；网络与存储是否满足附件批量传输。上述条件未落实前，不应安排正式切换窗口。
试迁移：用样本空间验证映射规则
试迁移的目的是验证映射规则是否成立，而不是提前完成正式迁移。样本空间选得越接近最坏情况，正式切换的意外越少。
样本空间建议覆盖三类特征：结构复杂，页面层级深、父子关系多；宏使用密集，包含表格、状态、展开、嵌入等常见类型；权限复杂，存在多用户组交叉授权和页面级例外。若源站空间数量较多，可各选一个典型空间组成样本集，总量控制在可在一至两天内完成核验的规模。
试迁移按固定顺序执行并全程记录：先迁移用户与用户组，再迁移空间与权限结构，然后迁移页面与附件，最后处理宏与链接。每一步记录开始时间、执行人、对象数量、异常数量和截图。记录格式统一，便于与正式切换的结果对比。
试迁移发现的问题按四类归集：映射规则错误，例如标签对应错目录；工具或权限限制，例如某类附件无法批量传输；内容降级，例如宏无等价替换；源数据本身的问题，例如断链或空页面。前两类必须修正规则后重跑样本，后两类进入差异清单由业务方确认。
试迁移通过标准应事先写明，例如：样本空间页面数量与源端一致；附件可下载且大小一致；权限抽查无越权访问；关键页面在目标端可正常阅读和编辑；差异清单中的每一项都有处理结论。达到标准后，映射规则冻结为正式切换版本，后续修改需走变更评审。
切换执行：冻结、迁移与切换窗口
切换当天的主要风险来自源站仍在被写入。冻结写入是保证数据一致性的前提，冻结时间点和通知方式必须提前确定。
冻结安排包括：提前至少三个工作日通知所有使用团队，说明冻结起止时间和期间的新内容暂存方式；冻结开始后源站转为只读，禁止新建和编辑页面；指定一名管理员保留恢复写入的权限，用于回退。冻结时长根据数据量和试迁移耗时估算，并预留核验时间。
迁移执行按批次划分，通常先迁移权限与空间结构，再按空间或业务域分批迁移页面与附件。批次顺序优先安排关键业务空间，使其尽早进入核验；低优先级空间放在后续批次。每批完成后记录数量与异常，不等待全部批次结束才开始核验。
| 角色 | 职责 | 切换窗口内动作 |
|---|---|---|
| 执行人 | 运行迁移、处理异常 | 按批次执行并记录结果 |
| 验证人 | 核对页面、附件、权限、链接 | 逐批抽检并填写核对表 |
| 决策人 | 判断继续、暂停或回退 | 依据失败判定标准做决定 |
| 业务代表 | 确认关键页面可用 | 抽查本部门高频页面 |
切换完成后，源站保持只读并保留至回退窗口结束。只读期间不删除源站数据，不回收账号权限，确保回退时可直接恢复写入。回退窗口的长度由项目组约定，覆盖验收核验和业务方确认的时间。
迁移后的文档如果需要在项目协作中与需求、任务、缺陷关联，可在 ONES 中将 Wiki 页面与工作项放在同一平台内衔接，减少文档与执行记录分散在两处的情况。这一衔接属于迁移后的使用安排，不改变本次切换的范围和验收标准。
核验与证据：切换后如何判定成功
验收以核对表为准，逐项记录结果和证据，避免以“看起来正常”作为通过依据。核对项应覆盖数量、结构、内容、权限和链接五个方面。
- 页面数量与层级：按空间比对源端与目标端的页面总数，抽查页面树的父子关系，确认标题与源端一致或已按映射规则改写并留有对照记录。
- 附件完整性：比对附件数量与总大小，随机抽取各类格式附件执行下载和打开，确认文件可读、图片可显示。
- 权限验证：用不同权限组的测试账号访问敏感页面，确认无越权可见、无应见不可见；检查页面级权限例外是否生效。
- 链接可用性：抽检内链是否指向目标端对应页面，外链是否仍可访问；断链记入差异清单并标注处理责任方。
- 内容呈现：抽查含宏、表格、代码块的页面，确认渲染正常或已按降级方案处理。
证据留存采用三种形式：核对表记录每项的数量、抽查样本和结论；截图保存关键页面、权限设置和附件下载结果；差异清单逐条记录问题描述、影响范围、处理结论和责任人。差异清单是回退判断的直接依据，也是复盘材料。
验收结论分为通过、有条件通过和不通过。有条件通过适用于差异项不影响关键业务、且已有明确修复计划的情况；不通过则触发回退评估。结论由决策人签署，并同步给业务方。
回退与停止条件：什么情况下终止切换
回退条件应在切换前书面约定，切换过程中按条件执行，避免临时争论。失败判定标准建议量化为可核对的事实，而不是主观感受。
常见触发条件包括：关键业务页面在目标端不可用或内容缺失；权限错配导致敏感内容被非授权人员可见，或应可见人员无法访问；数据缺失比例超出项目组预设阈值，例如页面或附件缺失数量超过约定比例；迁移批次连续失败且无法在窗口内修复。阈值由项目组根据业务重要性设定，官方资料未提供统一的量化标准，不应引用未经确认的数字。
回退操作的核心是恢复源站写入。具体步骤为：暂停后续批次迁移；由保留权限的管理员解除源站只读；通知用户回到源站继续工作；在目标端标注迁移状态，避免两边同时编辑造成分叉；保留已迁移数据用于问题分析，不立即删除。
部分回退与整体回退的取舍依据影响范围。若问题集中在个别空间或个别批次，可只回退该部分，其余已验收批次保留；若权限模型或结构映射出现系统性错误，影响多个空间，则应整体回退，修正规则后重新安排切换窗口。判断时以差异清单的分布为准，不以单点问题扩大回退范围。
回退后应完成复盘：确认问题根因属于映射规则、工具限制还是源数据；修订映射表和试迁移样本；补充核对项；重新约定切换窗口和冻结时间。再次切换前，修订后的规则需重新通过样本验证，不能直接沿用上次的试迁移结论。
常见问题
源站是 Confluence Cloud 还是 Data Center，切换规则要分别设计吗？
需要分别确认，但不必写成两套完全不同的流程。部署形态影响导出方式、API 可用性和迁移工具的接入条件，因此范围清单里应记录部署形态与版本号，映射和试迁移阶段据此选择迁移方式。若同一项目内两种形态并存，建议按形态分批安排切换窗口，避免同一批次混用不同导出路径导致核验口径不一致。
试迁移通过了，正式切换时还需要重新验证映射规则吗？
试迁移通过后映射规则可以冻结为正式版本，但正式切换仍要按批次核验。原因在于正式数据量更大、批次更多，试迁移未覆盖的空间可能存在新的宏类型或权限组合。建议把试迁移的核对项直接沿用为正式核验清单，并在每批完成后记录数量与异常，发现新问题按变更评审处理，不临时改动已冻结的规则。
冻结写入期间，业务团队有新内容要写怎么办？
冻结前应约定临时暂存方式，例如在目标端草稿区或指定文档中先行记录，待切换完成并验收后再归入正式空间。冻结通知至少提前三个工作日发出，说明起止时间和暂存位置。冻结期间源站只读，仅保留一名管理员具备恢复写入的权限用于回退，其他账号不开放编辑。
部分空间迁移失败，是整体回退还是只回退受影响部分？
依据差异清单的分布判断。问题集中在个别空间或个别批次，且其余批次已通过验收时，可只回退该部分，保留已验收数据；若权限模型或结构映射出现系统性错误、影响多个空间，则整体回退，修正规则后重新安排窗口。判断标准应在切换前写入回退预案，切换过程中由决策人按标准执行，避免临时扩大或缩小回退范围。
迁移后文档需要和需求、任务关联，切换阶段要提前做什么？
切换阶段只需在范围清单中标注哪些页面需要与工作项关联，不改变本次迁移的验收标准。迁移完成后，可在 ONES 中将 Wiki 页面与需求、任务、缺陷放在同一平台内衔接，减少文档与执行记录分散。若关联关系影响页面结构设计，应在映射阶段同步确认，不留到切换当天处理。
