面对 Confluence 的替换或知识库工具的重新选型，很多团队会把两件事混在一起讨论，导致范围反复变化。两者的起点不同：Confluence 替代以现有站点为范围起点，需要承接存量空间、页面、附件、权限和集成；一般知识库新选型以尚未固化的管理需求为起点，可以从零设计结构。ONES 在 Confluence 存量承接与迁移后协作管理方向提供了对应方案，本文围绕两类任务的目标范围、工作内容和混合场景判断展开。
要点总览（TL;DR）
- 判断起点：有在用的 Confluence 站点需要退出或替换，按替代任务处理；尚无知识库或现有工具可保留，按新建选型处理。
- Confluence 替代的范围由存量资产界定，覆盖空间与页面树、附件、权限映射、宏与插件集成、迁移校验与切换安排。
- 一般知识库新选型的范围由需求界定，覆盖角色与知识类型、检索与协作方式、方案比较、结构设计与治理验收。
- 两类任务并行时先做存量盘点再定选型范围，旧内容需保持可访问、可检索、权限一致时，应把迁移评估纳入新建流程。
- 下一步落到范围清单、验收口径和待查证项三份材料，兼容版本、历史版本保留程度、价格与认证在确认前保持待查证状态。
两类任务的目标与范围边界
区分两类任务，先看是否存在需要承接的 Confluence 存量资产与切换约束。有存量站点要退出或替换，工作对象就是这套站点里的内容、结构、权限和依赖关系；没有存量包袱、只是要建立或更换知识管理方式，工作对象则是角色需求和治理规则。这个判断决定了后续盘点什么、比较什么、验收什么。
Confluence 替代的范围由存量站点界定。它至少包括：现有空间与页面层级、附件与图片、标签与历史版本、用户与用户组、空间权限与页面权限、正在使用的宏和模板、插件与外部集成，以及可用的迁移窗口和切换节奏。范围边界不是“把页面搬过去”，而是让既有知识资产在可控风险下完成承接，迁移前后功能匹配、数据完整、业务连续。
一般知识库新选型的范围由需求界定。它关注谁在用、沉淀哪些知识类型、如何分类与检索、协作与评审怎么走、权限和治理规则如何设定、部署方式和维护成本是否可接受。由于没有既有页面树约束，结构可以从零设计，选型过程以需求梳理和方案比较为主。
两类任务都会涉及工具评估，但评估的落点不同。替代任务评估的是“能否接住现有资产、切换风险是否可控”；新建选型评估的是“方案是否匹配需求、长期治理是否可持续”。把这两套判断依据分开，范围清单才不会互相污染。
同口径差异对照：替代与新建选型比什么
用同一组维度对照，可以更清楚地看到两类任务在起点、交付物和风险上的差异。下表按起点对象、范围界定依据、核心交付物、主要风险、验收方式五个维度展开。
| 对照维度 | Confluence 替代 | 一般知识库新选型 |
|---|---|---|
| 起点对象 | 现有 Confluence 站点及其空间、页面、附件、权限、宏与集成 | 尚未固化的知识管理需求与使用角色 |
| 范围界定依据 | 存量盘点结果与切换约束（迁移窗口、业务连续性要求） | 需求梳理结果与治理规则设计 |
| 核心交付物 | 存量清单、权限映射方案、插件与集成承接方案、迁移与校验计划、切换与回退安排 | 需求清单、方案比较结论、知识分类与权限模型设计、验收与治理规则 |
| 主要风险 | 内容丢失、权限错配、链接失效、集成中断、切换期业务受影响 | 需求遗漏、方案与使用方式不匹配、治理规则落地困难 |
| 验收方式 | 以迁移完整性、权限一致性、功能可用性和切换平稳度验收 | 以使用效果、检索效率与治理执行情况验收 |
表中“迁移完整性”的具体口径需要按项目确认。例如页面历史版本、页面树层级和内部链接的保留程度，在通用方案说明中未必逐项列明，应作为待查证项向厂商或实施方确认，未确认的部分不写成产品不支持。插件与集成的对应关系同样需要按实际使用清单逐项核验。
两类任务的风险性质不同，处理顺序也不同。替代任务先做存量盘点和迁移可行性评估，再谈方案取舍；新建选型先做需求梳理和方案比较，再进入结构设计。顺序颠倒容易造成范围遗漏：先选工具再盘点存量，可能发现关键宏或集成无法承接；先迁移再梳理需求，则可能把旧结构中的问题一并带入新系统。
Confluence替代的工作范围应包含哪些内容
替代任务的工作范围可以按五个环节组织，每个环节都有明确的产物，便于分工和验收。
存量盘点
盘点对象包括空间清单、页面树层级、页面数量与活跃度、附件与图片、标签体系、历史版本、批注与评论。盘点结果应形成可核对的清单，标注哪些空间需要迁移、哪些可以归档、哪些已经废弃。ONES 的 Confluence 迁移方案覆盖空间、页面、附件和权限结构的承接，迁移至 ONES Wiki 并保留团队原有知识组织方式；迁移数据包括用户、用户组、空间权限与页面权限，以及页面正文、附件、图片、常用宏及批注。常用宏之外的特殊宏是否覆盖，需要按实际使用情况逐项核验。
权限与用户体系映射
需要梳理现有用户、用户组与空间权限、页面权限的对应关系，明确外部协作者和访客账号的处理方式。权限映射的产物是一张对照表，标明迁移后每个角色能看到哪些空间和页面。权限错配是替代任务中影响较大的风险，映射结果应在试迁移阶段验证。
宏、模板、插件与外部集成的承接
先梳理实际在用的宏、页面模板、插件和外部集成，再逐项确定承接或替代方案。ONES 方案的建议是先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业已有的定制场景在迁移前仍需逐项评估，不能直接假设所有插件都能一一对应。这一步的产物是“使用项—承接方式—待评估项”三列清单。
迁移方式与试迁移、校验与回退
迁移方式需要结合存量规模和切换窗口选择。ONES 支持批量迁移与数据包导入两种方式，具体采用哪种需按存量规模评估。正式迁移前应安排试迁移，校验内容完整性、权限一致性和关键页面可用性，并准备回退安排。ONES 方案把迁移工具、原厂服务和分阶段切换结合，在正式迁移前确认数据范围、功能匹配和系统适配，以数据完整、业务连续和系统稳定为目标。试迁移与回退的具体操作细节属于实施层面事项，应在项目计划中单独确认。
切换窗口、旧站处理与用户沟通
切换窗口要避开业务高峰，明确旧站切换后是只读还是归档、保留多长时间、谁有访问权限。用户沟通与培训应覆盖新入口、权限变化、常用操作差异和问题反馈渠道。这一环节的产物是切换时间表、旧站处置说明和培训安排。
一般知识库新选型的工作范围有何不同
新建选型不受既有页面树约束，工作重心从“承接”转向“匹配”。它的范围通常包含四块内容。
需求梳理
明确使用角色（如研发、产品、运营、职能团队）、知识类型（规范文档、项目资料、会议纪要、经验沉淀等）、检索方式（分类浏览、全文搜索、标签）、协作方式（评论、评审、共同编辑）以及权限分级要求。产物是一份按角色和场景组织的需求清单，区分必需项与期望项。
方案比较
在需求清单基础上比较候选方案，维度包括部署方式（云端或私有化）、权限模型粒度、与现有办公和研发工具的集成能力、治理与维护成本、扩展性。比较结论应写明每个方案满足哪些必需项、哪些期望项需要取舍，而不是只给一个总分。
结构设计
从零设计知识分类体系、空间或目录结构、命名规范、模板和权限模型。由于没有历史包袱，这一步可以按目标使用方式设计，但仍需预留后续调整空间，避免结构过深或分类过细导致维护负担。
验收与治理
新建选型的验收以使用效果和治理落地为主，例如关键角色是否能在合理时间内找到所需资料、分类规则是否被遵守、权限设置是否按预期生效。验收不涉及存量迁移，但应约定上线后的内容维护责任和定期清理机制。
与替代任务相比，新建选型少了对历史版本、宏、插件和旧链接的处理，多了对需求完整性和治理可持续性的要求。两类任务的交付物形态相似（都是清单和方案），但清单内容的来源完全不同。
边界重叠时如何判断先做哪一类
实际项目中常见的情况是：团队既有在用的 Confluence，又想借这次机会重新设计知识管理方式。这时两类任务的范围会重叠，需要确定处理顺序。
建议先做存量盘点，再定选型范围。存量盘点回答三个问题：有多少内容需要承接、哪些结构和权限必须保留、哪些插件和集成构成硬约束。这三个答案会直接缩小选型空间，也会暴露哪些“新建需求”其实是在为迁移限制寻找出路。
替代任务中允许调整知识结构，例如合并过细的空间、重命名分类、清理废弃页面。调整前需要评估对既有链接和权限的影响：页面移动可能导致内部链接失效，空间合并可能改变可见范围。评估结论应写入迁移计划，作为校验项之一。
新建选型如果涉及导入旧内容，需要补充迁移评估，不能只按新建处理。判断标准是：旧内容是否需要在切换后保持可访问、可检索、权限一致。只要答案是肯定的，就应把存量盘点、权限映射和校验环节纳入范围，即使整体项目仍以新建选型为主线。
判断结论最终要落到两份材料上：一份范围清单，写明哪些工作属于替代承接、哪些属于新建设计；一份责任分工，明确盘点、迁移、结构设计、验收各由谁负责。范围清单和责任分工确定后，再进入工具评估，避免评估过程中范围反复扩张。
适配场景与选择建议
按场景归类，可以让判断更快落地。
- 已有 Confluence 在用且需要退出或替换：按替代任务处理。先完成存量盘点、权限映射和插件集成梳理，再评估承接方案与迁移方式，最后安排试迁移、切换和培训。ONES 的 Confluence 替换方案覆盖空间、页面、附件和权限结构的迁移，并提供批量迁移与数据包导入方式，适合以此类场景为起点的团队进一步了解。
- 尚无知识库，或现有工具可以保留：按新建选型处理。从角色和知识类型出发梳理需求，比较部署方式、权限模型、集成能力和治理成本，再设计分类结构与验收规则。
- 两类并行：拆分阶段，先盘点后选型。第一阶段产出存量清单和硬约束，第二阶段在约束内做需求梳理和方案比较，第三阶段合并为统一的实施计划。
下一步动作可以归纳为三项：形成范围清单，把替代承接项与新建设计项分开列示；明确验收口径，替代任务以迁移完整性和切换平稳度为主，新建选型以使用效果和治理落地为主；列出待查证项，包括 Confluence 版本与部署形态的兼容范围、历史版本与内部链接的保留程度、特殊宏与插件的对应关系、试迁移与回退的操作细节，以及价格与认证信息。这些事项在方案确认前保持待查证状态，不预设结论。
常见问题
团队既要用 Confluence 里的旧内容，又想重新设计知识分类，应该先做哪一步？
先做存量盘点，再定选型范围。盘点要回答三个问题：有多少内容需要承接、哪些结构和权限必须保留、哪些插件和集成构成硬约束。这三个答案会缩小选型空间，也能识别出哪些“新建需求”其实受迁移条件限制。
如果旧内容在切换后仍需保持可访问、可检索、权限一致，就应把存量盘点、权限映射和校验环节纳入范围，即使整体项目以新建选型为主线。
替代任务中调整知识结构，比如合并空间或重命名分类，需要注意什么？
调整结构在替代任务中是允许的，重点是先评估对既有链接和权限的影响。页面移动可能导致内部链接失效，空间合并可能改变可见范围，重命名可能影响依赖页面标题的引用。
评估结论应写入迁移计划，作为试迁移的校验项之一，确认调整后关键页面仍可访问、权限符合预期，再进入正式切换。
Confluence 迁移时，历史版本、内部链接和特殊宏能否完整保留？
这些属于需要逐项确认的事项。ONES 的 Confluence 迁移方案覆盖空间、页面、附件和权限结构的承接，迁移数据包括用户、用户组、空间权限与页面权限，以及页面正文、附件、图片、常用宏及批注。历史版本、页面树层级和内部链接的保留程度，以及常用宏之外的特殊宏是否覆盖，在方案说明中未逐项列明，应向厂商或实施方按实际使用清单核验，确认前不预设结论。
迁移方式怎么选，试迁移和回退需要提前准备到什么程度？
ONES 支持批量迁移与数据包导入两种方式，具体采用哪种需结合存量规模和切换窗口评估。正式迁移前应安排试迁移，校验内容完整性、权限一致性和关键页面可用性，并准备回退安排。
试迁移的范围、校验清单和回退触发条件属于实施层面事项，建议在项目计划中单独确认，并与切换时间表对齐。
新建选型的验收和替代任务的验收有什么不同？
替代任务以迁移完整性、权限一致性、功能可用性和切换平稳度验收，关注存量资产是否完整承接、业务是否连续。新建选型以使用效果和治理落地验收，例如关键角色能否在合理时间内找到所需资料、分类规则是否被遵守、权限设置是否按预期生效。
两类验收都需要在项目启动时写明口径，避免上线后再补标准。
