本文给出一份假设情景下的 Confluence 迁移方案示例，覆盖盘点、结构映射、分批执行与切换验收四个环节，并逐项解释字段的填写依据。示例中的团队规模、空间数量和页面规模均为演示设定，不对应真实客户案例。迁移过程中产生的批次任务、负责人和验收记录，可以在 ONES 工作项与文档中统一跟踪。
要点总览（TL;DR）
- 一份可用的 Confluence 迁移方案围绕四件事展开：盘点空间与页面划分优先级、确定目标平台与结构映射、按试点—分批—全量推进、用内容完整、链接可用、权限对齐、用户可用四项证据判断切换。
- 方案字段各有决策含义：按空间划分范围对应权限边界与内容所有者，页面树层级决定链接重写比例，试点批次用于产出问题清单和操作规范，回退点设在不可逆动作之前。
- 换团队复用时主线不变，需要调整规模、权限复杂度、附件体量、停机窗口和宏插件依赖等变量，并把批次拆成可跟踪任务、留存验收记录。
- 示例适用于以页面文档为主、权限以空间授权为主的迁移；强依赖宏插件、复杂权限继承、超大附件或极短停机窗口的情形需要重新评估方案。
示例目标：这次迁移要解决什么问题
先交代示例成立的前提。假设某中型研发团队使用 Confluence 多年，形成了产品、研发、测试、运维四个主要知识空间，日常文档以需求说明、技术方案、接口文档、测试用例和运维手册为主。团队约 120 人，Confluence 中累计约 40 个空间、6000 个页面，附件以截图、设计稿和表格文件为主，权限按空间授权、少量页面单独授权。团队决定将知识库迁移到新的平台，同时借迁移机会清理过期内容、统一目录结构。
基于这个背景，本次迁移的范围口径可以写成：首批纳入 12 个活跃空间、约 3500 个页面，附件按总量约 80GB 估算；剩余空间先冻结写入，待内容所有者确认后再决定迁移或归档。权限方面，迁移用户、用户组、空间权限与页面权限，迁移后逐空间核对成员可见范围。
成功标准建议写成可核验的四条：
- 内容完整：纳入范围的空间与页面全部到位，页面正文、附件、图片和批注无缺失；
- 链接可用：页面间互链、目录导航和常用外部链接在迁移后可正常打开；
- 权限对齐：各空间成员可见范围与迁移前一致，敏感页面无越权暴露；
- 用户可用：各空间内容所有者完成抽查，关键岗位用户能在新平台完成日常查阅与编辑。
这四条标准同时构成后文验收环节的检查项。需要说明的是，示例中的数量与体量用于演示方案写法，实际项目应按盘点结果替换。
完整示例：一份 Confluence 迁移方案长什么样
下面是一份已填写的方案框架，读者可以按同样结构替换为自己的信息。方案分为基本信息、迁移范围、结构映射、批次计划、角色分工和风险回退六个部分。
方案基本信息
| 字段 | 示例填写内容 |
|---|---|
| 方案名称 | 研发知识库 Confluence 迁移方案（第一期） |
| 迁移负责人 | 知识管理岗 1 人，负责计划、协调与验收组织 |
| 时间窗口 | 第 1 周盘点，第 2 周映射与试点，第 3—5 周分批迁移，第 6 周验收切换 |
| 涉及团队 | 产品、研发、测试、运维四个内容团队，平台管理员 1 人 |
| 目标平台 | 新的知识库平台，按空间建立知识库，按页面树保留层级 |
迁移范围清单
| 空间 | 页面数（约） | 附件 | 评论/批注 | 历史版本 | 处理方式 |
|---|---|---|---|---|---|
| 产品空间 | 900 | 有 | 保留 | 仅保留当前版本 | 首批迁移 |
| 研发空间 | 1500 | 有 | 保留 | 仅保留当前版本 | 首批迁移 |
| 测试空间 | 700 | 有 | 保留 | 仅保留当前版本 | 第二批迁移 |
| 运维空间 | 400 | 有 | 保留 | 仅保留当前版本 | 第二批迁移 |
| 其余空间 | 约 2500 | — | — | — | 冻结写入，评估后归档或后续迁移 |
目标平台与结构映射规则
- 空间映射为知识库：一个 Confluence 空间对应一个新平台知识库，空间名称与简介沿用；
- 页面树映射为目录层级：顶层页面作为知识库一级目录，子页面按原层级下挂，深度超过五层的分支在映射时合并或上提；
- 页面标题保持原样，重名页面在标题后追加所属模块名以便区分；
- 页面互链在迁移后按新地址重写，无法自动对应的链接列入人工核对清单；
- 附件随页面迁移，超大附件单独列出并确认存放位置；
- 评论与批注随页面保留，作为历史讨论记录。
迁移批次与时间表
| 批次 | 范围 | 时间 | 完成标志 |
|---|---|---|---|
| 试点 | 研发空间中一个二级目录，约 150 个页面 | 第 2 周 | 结构、链接、权限抽查通过，形成问题清单 |
| 第一批 | 产品空间、研发空间剩余页面 | 第 3—4 周 | 内容所有者抽查通过，问题闭环 |
| 第二批 | 测试空间、运维空间 | 第 5 周 | 同上，并完成全量链接核对 |
| 验收切换 | 全部首批范围 | 第 6 周 | 四项成功标准全部满足，旧平台转只读 |
角色分工
| 角色 | 职责 | 产出 |
|---|---|---|
| 迁移负责人 | 制定计划、划分批次、协调资源、组织验收 | 方案、批次计划、验收结论 |
| 内容所有者 | 确认本空间迁移范围、清理过期页面、抽查迁移结果 | 范围确认单、抽查记录 |
| 平台管理员 | 配置用户与用户组、执行迁移、处理权限与链接问题 | 迁移执行记录、问题处理记录 |
| 验收人 | 按成功标准逐项核验并签字确认 | 验收清单 |
风险与回退安排
- 内容缺失风险：每批次迁移后由内容所有者抽查不少于 10% 的页面，发现缺失即暂停该批次；
- 链接失效风险：迁移后运行链接检查，人工核对清单在切换前清零；
- 权限错配风险：迁移后逐空间比对成员列表，敏感空间由负责人二次确认；
- 回退点：试点批次与第一批次结束后各设一个回退点，旧平台保持可写；验收切换前旧平台转为只读并保留至少一个月，作为回退依据。
逐项解释：每个字段为什么这样填
方案中的字段不是格式要求，每个字段背后都对应一个决策。理解填写逻辑，才能在换场景时做出合理调整。
范围字段：为什么先按空间划分而不是按页面全量迁移
空间是 Confluence 中权限、目录和团队归属的基本单位，按空间划分范围，可以直接对应到内容所有者和权限边界，便于分派责任和分批执行。按页面全量迁移看似彻底，但会把大量过期页面、草稿和无人维护的内容一并带入新平台，增加核对工作量，也让权限核对失去清晰的边界。示例中先迁 12 个活跃空间、其余空间冻结写入，就是用范围控制换取可控的验收节奏。
映射字段：页面树层级与链接重写的关系
页面树决定目录层级，也决定页面地址。层级在迁移中发生变化，页面互链就需要重写；层级保留得越完整，链接自动对应的比例越高。示例中规定深度超过五层的分支合并或上提，是为了避免新平台目录过深影响浏览，同时接受这部分页面需要人工核对链接。映射规则写得越具体，迁移后的链接问题越少。
批次字段：试点批次的选择依据
试点批次应选择结构有代表性、内容所有者配合度高、影响面可控的目录。示例选择研发空间中的一个二级目录，约 150 个页面，既能覆盖常见的页面类型、附件和权限情形，又不会在出问题时波及全团队。试点批次的产出不是迁移完成，而是一份问题清单和修正后的操作规范，后续批次按这份规范执行。
角色字段：内容所有者与平台管理员如何区分
内容所有者对本空间内容负责，判断哪些页面该迁、哪些该清理、迁移结果是否可用；平台管理员对迁移动作负责，执行迁移、处理权限配置和链接问题。两者职责分开，验收时才不会出现“执行的人自己验收自己”的情况。验收人独立于前两者，按成功标准逐项核验。
风险字段：回退点设置在哪里
回退点应设在不可逆动作之前。示例把回退点放在试点和第一批次结束后，因为这两次迁移暴露的问题最多，修正成本也最低；验收切换前旧平台转只读并保留一个月，是在确认新平台可用之前保留最后一道退路。回退点需要明确触发条件，例如抽查缺失率超过约定阈值即暂停并回退。
可迁移规律：换一个团队怎么改这份示例
这份示例的主线可以复用：盘点范围、确定映射、试点验证、分批执行、按标准验收。换团队时，主线不变，需要调整的是变量和配套的管理动作。
需要按实际情况调整的变量
- 规模：空间数、页面数和附件体量决定批次数量与每批时间，页面过万时建议增加批次并延长试点周期；
- 权限复杂度：存在大量页面级单独授权时，权限核对要单独安排时间，并指定敏感空间负责人；
- 附件体量：超大附件需要提前确认存放位置和访问方式，必要时单独列出清单；
- 停机窗口：旧平台冻结写入的时间点要与业务节奏匹配，避开版本发布和审计节点；
- 宏与插件依赖：强依赖特定宏或插件的页面，需要在盘点阶段单独标记，逐项评估替代方式。
迁移过程中的管理动作
迁移不是一次性的技术操作，而是一段有明确分工和节奏的项目。建议把每个批次拆成可跟踪的任务：范围确认、内容清理、执行迁移、抽查核对、问题修复、批次验收，每项任务有负责人、截止时间和完成标志。问题记录要能追溯到具体页面和具体批次，验收结论要留档，便于切换后复盘。
在需要统一跟踪迁移任务与验收结论时，可以用 ONES 工作项承载批次任务，把负责人、截止时间和状态放在同一处；用 ONES 文档记录范围确认单、抽查记录和验收结论，让内容所有者与平台管理员围绕同一份材料协作。若目标平台选择 ONES Wiki，官方资料说明可将 Confluence 空间、页面、附件和权限结构迁移过来，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注在迁移范围内，并支持批量迁移与数据包导入。常用宏的具体覆盖范围、历史版本与页面树层级的迁移口径，需要按实际使用情况逐项确认。
适用边界：这份示例在什么情况下要改
这份示例适用于以页面文档为主、结构相对清晰、权限以空间授权为主的知识库迁移。页面类型集中、附件以常规文件为主、团队对停机窗口有一定容忍度时，按示例主线执行即可。
以下情形需要重新评估方案：
- 强依赖宏或插件的页面占比较高，迁移前需要逐项评估替代方式，不能假设所有插件都能一一对应；
- 权限继承关系复杂，存在大量页面级授权和跨空间引用，权限核对的工作量要单独估算；
- 附件体量超大或包含大量视频、设计源文件，需要提前确认存储与访问方案；
- 停机窗口极短或不允许冻结写入，需要设计增量同步与切换方案，示例中的批次节奏不再适用。
本文是方案写法示例，不构成任何具体产品的兼容性承诺或迁移工具说明。具体平台支持的版本范围、宏覆盖清单、历史版本处理方式和迁移限制，应以实际查证的产品文档和迁移前评估结果为准。示例中的团队规模、空间数量与时间安排均为演示设定，读者应按自身盘点结果替换。
常见问题
迁移方案里先迁哪些空间、后迁哪些空间，按什么顺序排比较稳妥？
常见的排序依据有三条：内容活跃度、权限复杂度、对业务的影响面。活跃度高、结构清晰、内容所有者配合度高的空间适合放进试点或第一批，用来暴露问题并形成操作规范；权限复杂或涉及敏感信息的空间放在后续批次，留出单独的权限核对时间；仍在频繁更新的空间要避开版本发布和审计节点。示例中先迁产品与研发空间、后迁测试与运维空间，就是按活跃度和影响面排的顺序。
旧平台什么时候冻结写入比较合适，冻结期间用户还能查资料吗？
冻结写入的时间点通常放在全量迁移完成、抽查问题基本闭环之后，与业务节奏错开。冻结期间旧平台一般转为只读，用户仍可查阅历史内容，但新增和编辑转到新平台进行。示例把冻结写入安排在验收切换前，并保留旧平台只读至少一个月作为回退依据。如果业务不允许冻结写入，就需要设计增量同步与切换方案，批次节奏也要相应调整。
页面里用了大量宏和插件，迁移前应该怎么评估？
建议在盘点阶段把宏和插件的使用情况单独统计：按宏类型列出使用页面数和所在空间，区分展示类、交互类和集成类。展示类宏通常有替代写法，交互类和集成类需要逐项确认目标平台的处理方式。评估结论要落到页面清单上，标记哪些页面需要改写、哪些需要保留原样或单独处理。具体平台支持哪些宏、覆盖到什么程度，应以实际查证的产品文档为准，不宜在方案阶段作确定承诺。
迁移验收由谁签字，验收不通过时怎么处理？
验收人应独立于迁移执行方，按事先写好的成功标准逐项核验，内容所有者提供本空间的抽查记录作为依据。验收不通过时，先区分问题类型：内容缺失和链接失效属于可修复问题，回到对应批次修复后重新抽查；权限错配需要平台管理员与空间负责人共同确认；如果问题集中在结构映射层面，则要回到映射规则调整后重跑受影响批次。验收结论和问题处理记录都应留档，便于切换后复盘。
团队规模不大、空间数量少，这份示例可以简化到什么程度？
规模较小时可以压缩批次数量，把试点与第一批合并，但盘点、映射、抽查、验收这几个动作建议保留。角色上可以一人兼多职，内容所有者与平台管理员的职责仍要分开表述，避免执行与验收由同一人完成。时间表可以按周压缩，回退点至少保留一个。附件体量小、权限以空间授权为主时，权限核对和附件清单的工作量会明显下降，方案篇幅也可以相应精简。
