Confluence 迁移方案的关键，是把“搬内容”拆成可核验的阶段：登记来源、目标与对象范围，准备导出权限和目标侧配置，制定字段与结构映射规则，用小范围试迁移验证工具链，再以数量比对、抽样核对和权限抽查完成验收，最后分批切换并保留回退窗口。迁移方向、对象范围和验收口径要在动手前写清楚；零损、一键、完全兼容这类承诺，都需要用试迁移结果来验证。
要点总览（TL;DR）
- 迁移按“范围登记—输入依赖—字段映射—试迁移—验收—切换回退”推进，每个阶段都有可核验的产出物，不以“搬完了”作为完成标准。
- 同名不同义的字段优先保留原值并加前缀，必要时拆成两个字段，由业务方确认后固化映射规则版本。
- 试迁移先选结构复杂、宏多、权限特殊、附件大的页面，阻断级问题清零、复跑通过后再放大到全量或分批迁移。
- 验收以页面与附件数量比对、关键页面抽样核对、链接有效性检查和权限抽查为证据，不通过按问题类型回到映射或迁移环节返工。
- 切换分批进行并保留源侧只读窗口，出现数据缺失、权限错乱或关键页面不可用时按预案回退，修复后重走试迁移再安排切换。
迁移从哪里到哪里：来源、目标与对象范围
迁移开始前，先把“从哪搬、搬到哪、搬什么”写成一份登记表。这份表既是后续排期和验收的依据，也能避免把替换选型和迁移执行混在一起：选型回答用哪个平台，迁移回答具体哪些内容以什么规则过去。
来源侧需要登记到可操作的粒度，至少包括：Confluence 的部署形态（Cloud 或 Data Center/Server）、版本号、站点地址、涉及的空间清单及每个空间的大致页面量。版本信息直接影响可用的导出方式和迁移工具兼容性，不能只写“Confluence 全站”。
目标侧要明确平台名称和承载形态（云服务或私有部署），以及目标空间如何划分。承载形态决定了网络连通、账号同步和附件存储的配置方式，这些前提在 S2 中展开。
对象范围建议逐类勾选，形成下表：
| 对象类别 | 是否迁移 | 说明 |
|---|---|---|
| 空间与页面层级 | 是 | 记录空间数量、页面总数、最大层级深度 |
| 页面正文与图片 | 是 | 含正文中的内嵌图片 |
| 附件 | 是 | 登记附件总数量与总体积，识别超大附件 |
| 评论/批注 | 待定 | 按业务价值决定是否迁移，或归档保留在源侧 |
| 标签 | 待定 | 若目标侧标签体系不同，需在映射阶段处理 |
| 历史版本 | 待定 | 通常只保留当前版本，历史版本在源侧留存 |
| 权限 | 是 | 空间权限与页面权限均需登记，映射到目标权限模型 |
| 宏与插件内容 | 逐项评估 | 列出使用中的宏类型和出现次数 |
“不迁或暂缓迁”的清单同样要写出来，例如已废弃空间、测试空间、含敏感信息不宜外迁的页面、依赖特定插件的定制页面。这份清单需要业务方签字确认，避免迁移中途反复扩大范围。
迁移前要准备哪些输入和依赖
范围确定后，列出启动迁移所缺的输入和依赖，逐项确认责任人和完成时间。常见缺口集中在权限、配置和体量估算三处。
- 源侧导出权限与管理员配合：确认执行账号具备空间导出权限，涉及全站导出时需 Confluence 管理员配合；若使用迁移工具，确认工具所需的 API 访问方式已开通。
- 目标侧前置配置：目标空间结构先建好，账号体系（本地账号或企业目录同步）先打通，权限模型（角色、用户组、空间成员）先定义。账号未对齐就迁移，权限映射会大面积返工。
- 网络与存储：确认源到目标的网络连通方式；按附件总体积估算传输时间和目标侧存储容量，超大附件考虑单独通道或分批传输。
- 业务方输入：内容优先级排序（哪些空间先迁）、停写窗口（迁移期间源侧是否冻结编辑）、验收参与人名单。
把这些内容整理成一份输入与依赖清单，标注“已具备/待补齐/阻塞”三种状态。存在阻塞项时，迁移不应进入试迁移阶段。
同名字段含义不同时怎么做映射
字段映射的目标，是让目标平台上的每个字段都有明确来源和处理规则。做法是先建映射表，再处理冲突，最后固化版本。
映射表建议包含以下列：源字段、源字段含义与取值示例、目标字段、目标字段含义、映射类型（直接对应/转换/拆分/合并/丢弃/人工确认）、冲突处理、责任人。页面标题、层级、标签、状态、负责人这几类字段优先纳入。
同名不同义是最容易出问题的情况。例如源侧的“状态”表示页面评审进度，目标侧的“状态”表示文档发布状态，两者名称相同但语义不同。处理方式有四种，按优先级选择：
- 保留原值并加前缀：如把源状态值写入“原Confluence状态”字段，避免与目标状态混淆。
- 拆分为两个字段：语义确实需要并存时，分别承载评审进度和发布状态。
- 值域转换：建立取值对照表，如“草稿→编辑中”，转换规则写入映射表。
- 人工确认：无法自动判断的，标记出来由业务方逐条确认，确认结果回写映射表。
宏、模板和附件链接需要单独处理。宏按类型列出清单，能转换的转换为目标平台的等效内容，不能转换的降级为纯文本或截图并加说明；模板转换为目标侧的页面模板；附件链接在迁移后重新生成，不能沿用源站绝对地址。涉及插件或定制场景时，迁移前逐项评估，避免假设所有插件都能一一对应。
映射规则要有版本号和责任人。每次试迁移后修订规则，记录修订内容和影响范围，避免多轮修改后无法追溯某条规则为何这样定。
试迁移怎么选样本、跑流程
试迁移的作用是用最小成本暴露映射规则和工具链的问题。样本选择遵循“先难后易”：结构层级深、宏使用多、权限设置特殊、附件体积大的页面优先纳入，再搭配一两个结构简单的普通空间作对照。
试迁移的执行步骤建议固定下来：
- 冻结样本空间的编辑，记录迁移前基线（页面数、附件数、层级结构、权限清单）。
- 按映射表执行迁移，记录工具版本、参数、开始与结束时间。
- 逐页比对：正文完整性、图片显示、附件可下载、宏转换结果、链接可跳转。
- 抽查权限：用不同角色的账号登录目标侧，确认可见范围与源侧一致。
- 把问题按类型归档：映射规则错误、工具能力不足、源数据本身异常、目标配置缺失。
问题清单要带严重级别和处理结论。映射规则类问题回改 S3 的映射表后重跑；工具能力类问题评估替代方案或接受降级；源数据异常的先在源侧修复。试迁移通过、可以放大的判断条件建议写成：阻断级问题为零，映射规则修订后复跑通过，权限抽查无越权或漏权，业务方确认样本内容可用。满足这些条件再进入全量或分批迁移。
验收校验：用什么证据判断迁移成功
验收不能凭“看起来搬完了”下结论，要用可复核的证据。建议从四个维度取证：
| 校验维度 | 方法 | 通过标准 |
|---|---|---|
| 页面数量 | 源侧与目标侧按空间统计页面总数比对 | 差异在事先约定的容差内，差异项逐条说明原因 |
| 附件数量与体积 | 按空间统计附件数量和总体积 | 数量一致，抽样附件可正常下载打开 |
| 层级结构 | 抽取若干深层页面，核对父页面路径 | 层级关系与源侧一致 |
| 关键页面内容 | 业务方按清单逐页人工核对正文、表格、图片、宏 | 无内容缺失，降级处理处有说明 |
| 链接有效性 | 抽查页面内链和跨空间链接 | 可跳转，失效链接有清单和修复计划 |
| 权限与可见范围 | 用管理员、空间成员、普通用户三类账号抽查 | 无越权可见，无应可见而不可见 |
验收不通过时，按问题类型走返工路径：数量差异回到迁移执行环节补迁；内容缺失回到映射规则修订；权限错乱回到目标权限配置核对后重做权限映射；链接失效进入修复清单单独处理。返工后重新抽取同类样本复核，不能只修单页就整体放行。验收核对表和抽样记录要留存，作为切换决策的依据。
切换、回退与停止条件
切换采用分批方式，按空间或业务部门划分批次，每批设置停写窗口。窗口内源侧冻结编辑，执行增量迁移，完成后通知用户切换访问入口。批次之间留出观察期，确认无集中问题再启动下一批。
源侧在切换后保留只读状态一段时间，保留期长短由业务方根据查阅需求确定。保留期内源站不再接受编辑，但可查询，作为回退基础。
回退条件要提前写死，触发即执行，不临场讨论。常见触发条件包括：关键页面在目标侧缺失或内容严重损坏；权限错乱导致敏感内容越权可见；核心业务空间无法正常访问且短时间内无法修复。回退动作包括恢复源侧编辑权限、通知用户切回、冻结目标侧对应批次数据。
回退后先做原因分析，明确是映射规则、工具执行还是目标配置的问题，修复后重新走试迁移验证，再安排下一次切换。停止迁移的判断同样要写进预案：若试迁移多轮仍存在阻断级问题且无可行替代方案，应暂停全量迁移，重新评估目标平台或迁移范围，而不是带着已知缺陷强行推进。
迁移过程中的协作与状态跟踪怎么落地
迁移涉及盘点、映射、试迁移、验收、切换多个阶段，跨业务方、IT 和管理员多方协作，任务分派和状态记录需要落到可跟踪的工作项上，否则问题容易在口头沟通中丢失。
落地方式可以按以下结构组织：把每个空间的迁移拆成独立工作项，关联负责人、批次和计划完成时间；映射表、验收核对表、问题清单作为文档与对应工作项关联，规则修订时同步更新文档版本；问题从发现、分派、修复到复核关闭，走统一的状态流转，阻断级问题单独标记；试迁移通过、验收通过、切换完成这些节点设置评审记录，记录参与人和结论。
在 Confluence 迁移到 ONES Wiki 的场景中，迁移任务、映射文档和验收记录可以在 ONES 中作为工作项与文档关联跟踪，页面正文、附件、图片、常用宏及批注可按迁移能力处理，用户、用户组、空间权限与页面权限也在迁移数据范围内；批量迁移与数据包导入两种方式可按空间体量选择。具体兼容版本、宏覆盖清单和实施排期，建议在迁移前与厂商逐项确认，再写入范围登记表。
常见问题
Confluence 迁移时，历史版本、评论和标签要不要一起迁？
这三类对象建议在范围登记阶段逐项决定，而不是默认全迁或全不迁。历史版本通常只保留当前版本，旧版本留在源侧只读留存，能显著降低迁移体量和比对工作量；评论和批注按业务价值判断，评审讨论密集的空间可以迁移，纯归档空间可留在源侧；标签若目标侧标签体系不同，需要在映射阶段做值域转换或合并。无论怎么定，都要写进对象范围表并由业务方确认，避免迁移中途反复扩大范围。
试迁移跑了几轮还有问题，什么情况下应该暂停而不是继续放大？
先看问题类型。映射规则错误和源数据异常属于可修复问题，回改映射表或源侧修复后复跑即可；工具能力不足要看是否有可接受的降级方案。如果多轮试迁移后仍存在阻断级问题，例如关键页面内容无法完整迁移、权限映射无法对齐，且没有可行的替代处理方式，应暂停全量迁移，重新评估目标平台或缩小迁移范围。带着已知缺陷强行推进，问题会在全量阶段成倍放大，回退成本更高。
源侧停写窗口要留多长，切换后源站还要保留多久？
停写窗口取决于该批次的数据增量和附件体量，建议按试迁移实测的迁移耗时加一定缓冲来确定，并在窗口开始前通知用户。切换完成后源侧保留只读状态一段时间，保留期长短由业务方的查阅和回退需求决定，保留期内源站不接受编辑但可查询，作为回退基础。保留期结束前要确认目标侧验收通过、用户已完成入口切换，再决定是否关闭源站。
迁移任务和映射文档分散在多人手里，怎么保证问题不丢？
把每个空间的迁移拆成独立工作项，关联负责人、批次和计划完成时间；映射表、验收核对表和问题清单作为文档与对应工作项关联，规则修订时同步更新文档版本；问题从发现、分派、修复到复核关闭走统一状态流转，阻断级问题单独标记。在 Confluence 迁移到 ONES Wiki 的场景中，迁移任务、映射文档和验收记录可以在 ONES 中作为工作项与文档关联跟踪，具体配置按团队实际流程确定。
Confluence 里的宏和插件内容迁移后怎么处理？
先按类型列出使用中的宏清单和出现次数，再逐项判断：能转换的转换为目标平台的等效内容，不能转换的降级为纯文本或截图并加说明，模板转换为目标侧的页面模板。Confluence 数据迁移 ONES Wiki 支持迁移页面正文、附件、图片、常用宏及批注，但“常用宏”的具体覆盖范围需在迁移前逐项核对。涉及插件或定制场景时，迁移前逐项评估，避免假设所有插件都能一一对应。
