Confluence 空间迁移的核心，是把一个空间拆成可逐项核对的迁移单元：先盘点页面树、附件、权限与宏引用，再确定目标结构和字段映射，用少量页面试迁，按页面数、附件完整性、链接与权限逐项校验，最后分批切换并保留回退窗口。本文按这一顺序给出盘点表、映射表、试迁记录、核验清单与回退预案的写法，迁移方向为 Confluence 到已确定的目标平台，不承诺零损或一键完成。
要点总览（TL;DR）
- Confluence 空间迁移先做对象盘点：页面树、附件、评论与批注、标签、权限组、宏与外部链接逐项登记，并写明哪些空间、归档页纳入本次范围。
- 迁移前确认 Confluence 导出或 API 权限、管理员配合事项，以及目标平台的目录与页面层级设计结论，未就绪项不进入试迁。
- 字段映射表按“源字段—目标字段—转换规则—无法自动映射项及处理”组织，宏与附件链接逐项评估替代或降级，权限组单独映射并列出例外。
- 试迁选有代表性、影响面小的子空间，按结构→页面→附件→权限→链接执行，用失败项和修补工作量修正映射表与批次划分。
- 核验按页面数量与层级、附件可打开性、链接抽检、四类角色可见范围逐项比对并留存记录；分批切换保留只读期与快照，关键页面缺失、权限越权、附件大面积不可用时暂停并评估回退。
迁移范围：一个 Confluence 空间里到底要搬什么
“迁移一个空间”在实际操作中往往包含多种对象，盘点时如果只统计页面数，试迁阶段就容易在附件、权限或宏上返工。建议在动手前先建立一份空间迁移对象盘点表，把每个空间拆成六类对象分别登记：页面树、附件、评论与批注、标签、权限组、宏与外部链接。每一类都记录来源位置、目标落位方式和是否纳入本次迁移。
盘点口径需要提前统一，否则不同人统计出的数字无法对齐。页面数按当前可见页面计，归档页、草稿页、模板页单独标注状态；附件按文件条目计，同一文件在多个页面重复引用时注明引用次数；权限组记录组名与成员规模，不展开到个人；宏按类型汇总，标注哪些宏承载了业务逻辑（如状态宏、任务宏、内容引用宏），哪些只是排版用途。外部链接单独列一张清单，便于切换后做跳转检查。
范围边界同样要写进盘点表。本次迁移覆盖哪些空间、是否包含归档页、历史版本是否迁移、评论是否保留，这些结论一旦确定就作为后续映射和验收的依据。对于暂不迁移的空间，在表中标注“保留在 Confluence 只读”或“后续批次”，避免切换后出现两套系统都有人编辑的混乱。
| 盘点项 | 登记内容 | 是否纳入本次迁移 | 备注 |
|---|---|---|---|
| 空间名 | 空间标识、负责人、页面总数 | 是/否 | 按批次标注 |
| 页面树 | 层级深度、归档页数量、模板页数量 | 是/否 | 归档页单独统计 |
| 附件 | 附件条目数、总容量、重复引用情况 | 是/否 | 大文件单独列出 |
| 评论与批注 | 评论条数、批注条数 | 是/否 | 按目标平台支持情况定 |
| 标签 | 标签种类与使用频次 | 是/否 | 用于目标侧分类设计 |
| 权限组 | 组名、成员规模、空间级与页面级权限 | 是/否 | 映射到目标角色 |
| 宏与外部链接 | 宏类型清单、外链数量 | 是/否 | 逐项评估替代或降级 |
迁移前输入：账号、导出权限与目标结构
迁移中途卡住，多数情况源于前置条件没有逐项确认。开始前应形成一份前置条件清单，每项标注负责人、是否就绪以及缺失时的影响，把“等权限”这类隐性等待显性化。
Confluence 侧需要确认的是导出或 API 访问权限，以及管理员配合事项。空间管理员能否导出完整空间、是否具备读取附件与权限配置的权限、导出过程是否需要 IT 开通白名单，这些都要提前验证一次。目标平台侧需要的是目录、空间与页面层级的设计结论：新平台按什么维度划分空间，页面层级保留几层，命名规范是否调整。这个结论未定就启动迁移，试迁结果无法复用。
字段与元数据映射所需的信息也要在此时收集齐全，包括作者账号对应关系、创建与更新时间、标签体系、页面状态字段。迁移窗口与停机安排同样属于前置输入：是选择周末集中切换，还是工作日并行使用一段时间，直接决定试迁和分批切换的节奏。
- Confluence 导出或 API 权限已开通，并完成一次小范围导出验证
- 目标平台空间与页面层级设计已评审通过
- 作者账号、标签、页面状态的对应关系已收集
- 迁移窗口、停机或并行使用安排已通知相关团队
- 每项条件明确负责人与缺失影响，未就绪项不进入试迁
字段与结构映射：同名字段含义不同怎么处理
映射表的价值在于把“看起来一样”的字段差异写清楚。页面标题通常可以直接对应，但需要处理重名与特殊字符；页面层级要决定是保留原有深度还是压缩层数；正文格式涉及富文本、代码块、表格的转换规则，复杂排版建议在试迁中实际验证后再定规则。
元数据的落位方式需要逐项确认。作者字段在目标侧可能对应账号或显示名，创建时间是否保留原值、标签是否转为目标平台的分类或属性、页面状态（草稿、发布、归档）如何表达，都应在映射表中写明转换规则。对于无法自动映射的项，单独列人工处理方式，例如由空间负责人确认后再补录。
宏、嵌入内容与附件链接是映射中最容易出问题的部分。状态宏、任务宏、内容引用宏这类承载业务逻辑的宏，需要评估目标平台是否有对应能力，没有对应能力时采用降级方案，例如转为普通文本加说明、转为目标平台的任务或表格。附件链接在迁移后路径会变化，需要在核验阶段抽检。权限组到目标平台角色的映射要单独成表，并列出例外清单，例如跨部门共享页面、外部协作者可见页面，这些例外需要人工确认。
| 源字段/对象 | 目标字段/对象 | 转换规则 | 无法自动映射项及处理 |
|---|---|---|---|
| 页面标题 | 页面标题 | 直接对应，重名加空间前缀 | 特殊字符人工确认 |
| 页面层级 | 目录/页面树 | 保留原层级，超过五层时压缩 | 深层页面人工复核 |
| 正文格式 | 富文本 | 表格、代码块按规则转换 | 复杂排版试迁验证 |
| 作者 | 账号或显示名 | 按账号对应表转换 | 离职账号转显示名 |
| 创建时间 | 创建时间 | 保留原值 | 无 |
| 标签 | 分类或属性 | 按标签对照表转换 | 未登记标签人工归类 |
| 状态宏、任务宏 | 对应能力或普通文本 | 有对应能力则转换，否则降级 | 逐项登记降级方式 |
| 权限组 | 角色 | 按权限映射表转换 | 跨部门共享页面人工确认 |
当迁移目标确定为 ONES Wiki 时，上述映射工作有对应的承载方式。据 ONES 官方资料，Confluence 的空间、页面、附件和权限结构可以迁移至 ONES Wiki，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注在支持范围内，迁移方式支持批量迁移与数据包导入。常用宏的具体范围、评论与历史版本的迁移口径，需要在迁移评估中逐项确认，映射表里的降级项仍要人工登记。
试迁移：先搬一个子空间验证什么
试迁移的样本应满足两个条件：结构上有代表性，影响面上足够小。可以选择一个包含多级页面、若干附件、两到三个权限组、使用了几种常用宏的子空间，避开正在高频编辑的核心空间。样本确定后，按结构、页面、附件、权限、链接的顺序执行，每一步记录结果，而不是一次性导入后统一排查。
执行过程中重点观察四类问题：页面层级是否与预期一致，正文格式转换后表格和代码块是否可读，附件是否完整且能打开，权限组映射后不同角色看到的范围是否符合预期。宏的降级效果要在这一步实际查看，不能只看导入日志。失败项和人工修补工作量逐条记录，例如“某类宏需人工改写 12 处”“三个附件因命名冲突需重命名”。
试迁结束后，用记录结果反向修正映射表与批次划分。如果某类页面修补成本明显偏高，可以调整转换规则或把相关空间拆成更小批次；如果权限映射出现越权，先修正映射表再进入全量。试迁记录本身也是后续验收的基线，保留样本范围、成功与失败项、修补动作和映射表修订点。
核验与证据：迁移完成后按什么判断通过
核验要按同一口径逐项比对，并把结果留存为验收证据。页面数量与层级一致性是第一项，用盘点表的总数与迁移后实际数量对照，层级抽查若干条深层路径。附件核对数量、可打开性和文件名，重点检查重名文件和特殊字符文件名。链接检查分内部链接、跨空间引用和外部链接三类，内部链接抽检比例可以高一些，外部链接以清单方式逐条确认。
权限可见性抽检需要不同角色实际登录查看，而不是只看配置表。选择管理员、空间成员、只读成员、非成员四类角色，分别确认能看到和不能看到的页面范围，发现越权立即记录并处理。所有核验项都应有明确的通过标准，例如“页面数量差异为零”“附件可打开率 100%”“抽检链接无失效”，未通过项写明处理结论和责任人。
| 核验项 | 核对方法 | 通过标准 | 未通过处理 |
|---|---|---|---|
| 页面数量与层级 | 与盘点表总数对照，抽查深层路径 | 数量一致，层级符合映射规则 | 定位缺失页面并补迁 |
| 附件 | 数量比对，逐个打开抽检 | 数量一致，可打开，文件名正确 | 重新上传或修正命名 |
| 内部链接与跨空间引用 | 按清单抽检 | 无失效链接 | 修正链接或登记待处理 |
| 外部链接 | 逐条确认 | 可访问或已登记失效原因 | 更新链接 |
| 权限可见性 | 四类角色实际登录查看 | 可见范围与映射表一致 | 修正角色映射后复检 |
核验记录建议按批次归档，包含核验时间、核验人、抽检范围和结论。当迁移目标为 ONES Wiki 时，页面与附件在目标空间中的组织方式、权限配置结果都可以直接在目标侧逐项查看，核验记录也可以作为文档沉淀在同一知识库中，便于后续批次复用同一套口径。
分批切换与回退：什么情况下暂停或回退
切换按空间或部门分批推进，每批完成后保留一段 Confluence 只读期，让用户在新平台使用、在旧平台查证。只读期内源空间保持可访问但不可编辑，同时保留源空间快照，记录每批的切换时间点和涉及范围。这样即使发现问题，也能定位到具体批次。
回退触发条件需要提前写死，避免切换现场临时判断。关键页面缺失、权限越权导致非授权用户可见、附件大面积不可用，这三类情况出现时应暂停当前批次并评估回退。回退操作包括恢复源空间可编辑状态、暂停后续批次、修正映射表后重新试迁。对于影响面小的个别问题，可以在新平台直接修补，不必整体回退，但要在切换记录中注明。
- 按空间或部门划分批次，每批设置明确的开始与完成时间
- 切换后保留 Confluence 只读期与源空间快照
- 关键页面缺失、权限越权、附件大面积不可用时暂停并评估回退
- 旧链接跳转方案与用户通知在切换前确定，切换后当天发出
- 每批记录切换时间点、核验结论与遗留问题
旧链接处理容易被忽略。Confluence 页面地址在切换后失效，需要在目标平台建立跳转说明或在新页面中标注原地址，用户通知中同时给出新入口和查询方式。ONES 的 Confluence 迁移方案把迁移工具、原厂服务和分阶段切换结合起来，并在正式迁移前确认数据范围、功能匹配和系统适配，这一思路与本文的分批切换和回退安排一致；具体批次设计与回退阈值仍需按项目实际情况确定。
常见问题
Confluence 空间迁移时，历史版本、评论和标签要不要一起搬？
这三类对象的处理口径需要在盘点阶段就定下来，并写进盘点表的“是否纳入本次迁移”一栏。历史版本影响存储容量和迁移耗时，评论与批注涉及目标平台的支持方式，标签则关系到目标侧的分类设计。建议按业务价值排序：承载决策记录的评论优先保留，标签优先转为目标平台的分类或属性，历史版本按需保留最近若干版本或整体不迁。
口径一旦确定，就作为映射表和验收清单的依据，避免试迁后再改范围导致返工。若迁移目标为 ONES Wiki，据官方资料，批注在支持迁移的范围内，评论与历史版本的具体口径需在迁移评估中确认。
试迁移要选多大的子空间，样本太小会不会验证不出问题？
样本的判断标准是“结构有代表性、影响面足够小”，而不是单纯看页面数量。一个合适的样本通常包含多级页面、若干附件、两到三个权限组，并使用了几种常用宏，同时避开正在高频编辑的核心空间。样本太小可能覆盖不到深层页面和权限例外，样本太大则修补成本高、周期长。
如果第一次样本没有覆盖到某类宏或跨部门共享页面，可以补做一次小范围试迁，把新发现的问题补进映射表，再进入全量批次。
迁移后 Confluence 旧链接失效，用户还在收藏夹里访问怎么办？
旧链接处理要在切换前确定方案，并与用户通知一起发出。常见做法是在目标平台建立跳转说明页，或在新页面上标注原地址，通知中同时给出新入口和查询方式。切换后保留一段 Confluence 只读期，让用户在新平台使用、在旧平台查证，可以减少找不到页面的情况。
外部链接和跨空间引用建议单独列清单，切换后逐条确认，失效项登记原因和责任人，避免长期悬空。
分批切换时，什么情况应该整体回退，什么情况可以在新平台直接修补？
回退触发条件建议提前写死：关键页面缺失、权限越权导致非授权用户可见、附件大面积不可用，这三类情况出现时暂停当前批次并评估回退。回退操作包括恢复源空间可编辑状态、暂停后续批次、修正映射表后重新试迁。
影响面小的个别问题，例如少量链接失效或个别页面排版异常，可以在新平台直接修补，不必整体回退，但要在切换记录中注明问题、处理方式和时间点，便于后续批次复用经验。
迁移目标确定为 ONES Wiki 时，哪些映射工作可以借助官方迁移能力，哪些仍需人工确认？
据 ONES 官方资料，Confluence 的空间、页面、附件和权限结构可以迁移至 ONES Wiki，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注在支持范围内，迁移方式支持批量迁移与数据包导入。这意味着账号对应、权限组映射和正文转换有对应的承载方式。
仍需人工确认的部分包括：常用宏的具体范围与降级方式、评论与历史版本的迁移口径、跨部门共享页面等权限例外，以及复杂排版的转换效果。这些项应在试迁中实际查看并登记，不能只依赖导入日志。
