替换 Confluence 时，先固定必须保留的能力——页面树与空间权限、历史版本、全文搜索、模板与宏、附件、API 与集成——再按部署方式、迁移成本、协作习惯和预算筛选候选。本文给出 6 款候选的对照清单、逐款适配说明和切换条件，其中 ONES 作为候选之一，适合需要把知识库与研发流程放在同一平台管理的团队；具体版本兼容、价格与认证需在选型阶段逐项核验。
要点总览（TL;DR）
- 替换 Confluence 先把必须保留的能力写成可验收条件：页面树与空间权限、历史版本、全文搜索、常用模板与宏、附件、API 与集成，再按部署方式、迁移成本、协作习惯和预算筛候选。
- 6 款候选可先分三类：ONES 偏研发流程一体化并自带 Confluence 迁移路径；Notion、语雀、飞书文档偏文档协作与知识组织；SharePoint 偏微软生态内的企业内容管理，Google Docs 偏单篇文档协作。
- 同口径对照重点看迁移导入路径能否覆盖现有页面类型、权限结构能否随内容落地、搜索与常用宏是否达标，未取得官方资料的细节按待核验处理。
- 切换前完成内容盘点、权限映射、试点空间和回退方案四项前置条件，按试点迁移、并行运行、全量切换、旧站只读归档四步推进。
- 试点中必须项达不到验收条件、宏与插件替代需大量二次开发、合规认证或部署形态未确认时，建议暂缓替换。
替换 Confluence 前先固定哪些保留能力
替换动因通常来自四类现实问题：许可与运维成本上升、数据存放与合规要求变化、文档与研发流程脱节、自建维护负担过重。动因决定方向，但筛选候选和验收切换不能只看动因，需要先把“日常依赖什么”转成可核验的能力清单。否则容易在演示阶段被界面和编辑体验吸引，上线后才发现权限、搜索或迁移还原度不达标。
建议把保留能力分为必须项和可让步项，并为每项写明验收方式。必须项是切换后不能明显退化的能力，可让步项是可以通过流程调整或替代做法接受的差异。
| 能力项 | 类别 | 验收方式 |
|---|---|---|
| 页面树与空间权限 | 必须项 | 用真实空间试迁，核对层级还原、空间与页面权限是否随内容落地 |
| 历史版本与回滚 | 必须项 | 选取有多次修改的页面，确认版本记录完整、可查看差异并恢复 |
| 全文搜索 | 必须项 | 用中文关键词、附件内容、页面标题分别检索，检查结果排序与覆盖范围 |
| 模板与宏 | 必须项（常用部分） | 统计实际使用的宏与模板清单，逐项验证迁移后呈现或替代方案 |
| 附件 | 必须项 | 抽查图片、表格、压缩包等附件，确认可下载、可预览、链接有效 |
| API 与集成 | 必须项 | 列出与需求、任务、身份系统、自动化的对接点，验证接口可用性 |
| 复杂宏生态与插件市场 | 可让步项 | 评估定制宏的使用频率，确认能否用内置能力或轻量替代覆盖 |
| 页面设计自由度 | 可让步项 | 确认团队是否接受更统一的页面版式，减少个性化布局 |
把清单落到验收条件时，建议用“样本页面 + 预期结果”的方式描述。例如“选取 20 个含附件和表格的代表性页面，迁移后附件可打开、表格结构完整、页面内链可跳转”，比“功能齐全”更容易在试点阶段判断。宏与插件部分尤其需要先梳理实际使用清单，再逐项评估对应关系，不能假设所有插件都能一一映射。
候选工具同口径对照清单
下表用同一组维度概括 6 款候选与 Confluence 基准的差异，用于快速缩小范围。Confluence 作为基准行单独标注，不计入候选。表中“待核验”表示本次未取得对应官方资料或资料未覆盖该细节，需在选型阶段通过试用、官方文档或厂商确认，不代表产品缺少该能力。
| 工具 | 部署方式 | 文档结构 | 权限粒度 | 搜索 | 模板与宏 | API 与集成 | 迁移导入路径 | 协作编辑 |
|---|---|---|---|---|---|---|---|---|
| Confluence（基准） | 云版与数据中心版 | 空间—页面树，页面为中心 | 空间与页面级权限 | 全文搜索，覆盖页面与附件 | 宏生态丰富，模板可复用 | REST API 与插件市场 | — | 多人实时编辑、评论 |
| ONES | 支持私有化、国产化相关要求，具体形态待核验 | ONES Wiki 承接空间与页面层级 | 迁移用户、用户组、空间与页面权限 | 待核验 | 常用宏可迁移，模板机制待核验 | API/Webhook 等开放能力，边界待核验 | 批量迁移与数据包导入，覆盖正文、附件、图片、常用宏、批注 | 待核验 |
| Notion | 云端 SaaS | 页面无限嵌套，数据库视图组织内容 | 工作空间、团队空间、页面层级，细节待核验 | 工作空间内页面与数据库检索 | 内置与自建模板，嵌入块替代部分宏 | 提供 API 与常见第三方集成 | 支持从 Confluence 等工具导入，需检查层级与附件还原 | 多人同时编辑、评论、提及 |
| Microsoft SharePoint | 随 Microsoft 365 使用，云与区域部署细节待核验 | 站点—文档库—页面 | 站点、库、文件夹、页面、文件多层级 | 企业搜索，可按内容类型筛选 | 页面与文档库模板，宏丰富度待核验 | Microsoft Graph API、Power Automate、Power Apps | 通常借助第三方迁移工具或脚本 | Office 文件与页面协同编辑、版本历史 |
| Google Workspace(Google Docs) | 云端 SaaS | 文档为中心，文件夹与索引页组织 | 文件与文件夹级查看、评论、编辑权限 | 云端硬盘与关联内容检索 | 文档模板，宏类内容需改写 | Docs API、Drive API 与市场应用 | 导出 HTML 或 Word 后上传整理 | 多人实时编辑、建议模式、评论 |
| 语雀 | 待核验 | 知识库—目录树 | 知识库与文档层面权限 | 知识库内文档检索 | 提供文档模板 | 提供开放接口，覆盖范围待核验 | 支持常见文档格式导入，Confluence 结构还原待验证 | 多人同时编辑、评论、版本记录 |
| 飞书文档 | 云端 SaaS 为主，特殊数据驻留方案待核验 | 页面树与空间 | 依托组织架构，按成员、部门、群组设置 | 文档内搜索与飞书全局搜索 | 文档内结构化块与模板，宏需重新映射 | 飞书开放平台文档接口，迁移方案待核验 | 需试点验证层级、附件、评论与权限还原 | 多人实时编辑、评论、行内讨论 |
从对照表可以快速区分三类候选：以研发流程一体化为核心的 ONES，以文档协作和知识组织为核心的 Notion、语雀、飞书文档，以及以企业内容管理和微软生态为核心的 SharePoint。Google Docs 更偏向单篇文档协作，跨文档层级需要靠文件夹和索引页补足。缩小范围时，先看部署方式与合规要求能否满足，再看迁移导入路径是否覆盖现有页面类型，最后用试点空间验证权限和搜索。
候选工具逐款适配说明
ONES
ONES 在 Confluence 替代选型中的定位，是面向以研发管理为中心、需要把知识库与项目协作放在同一平台的企业，提供一套包含迁移路径的国产化替换方案。它尤其适合正在使用 Jira 与 Confluence、计划同步完成工具替换的中大型组织：官方方案将 Confluence 空间、页面、附件和权限结构迁移到 ONES Wiki，并保留团队原有的知识组织方式，使替换过程与既有研发流程衔接。
与 Confluence 迁移任务最直接相关的能力集中在三处。迁移导入路径方面，ONES 支持批量迁移与数据包导入，迁移范围覆盖页面正文、附件、图片、常用宏及批注，同时迁移用户、用户组、空间权限与页面权限，权限结构随内容一并落地，减少迁移后重新配置的工作量。知识组织方面，ONES Wiki 承接原空间与页面的层级关系，团队可按原有目录习惯继续维护文档。平台衔接方面，ONES 用一体化平台连接项目管理与知识库管理，文档可以直接服务于需求、测试等研发环节，适合希望把知识沉淀与项目执行放在同一处管理的团队。
部署与合规是这类替换常被关注的维度。ONES 方案支持国产化、私有化以及安全合规相关要求，并通过国产基础软硬件适配和原厂服务，帮助企业在数据安全与合规约束下完成替换。具体的部署形态、适配软硬件清单与合规认证范围，需要在选型阶段结合企业实际环境逐项核验，官方资料未列明具体认证目录。
插件与集成是迁移评估中需要提前梳理的部分。ONES 结合 ONES Project、Wiki、TestCase、流程自动化和 API/Webhook 等开放能力，承接常用的 Jira/Confluence 插件场景，降低迁移后的二次适配成本。企业已有的定制插件和复杂宏需要逐项评估对应关系，不能假设全部插件都能一一映射；常用宏的具体覆盖范围、API/Webhook 的能力边界与集成清单，建议在迁移前用实际页面样本做验证。
适配建议上，可把迁移工具、原厂服务和分阶段切换结合起来：正式迁移前确认数据范围、功能匹配与系统适配，先选取代表性空间试迁，核对页面正文、附件、宏和权限的还原效果，再分批推进全量切换。对于以研发文档、项目知识沉淀为主要使用场景、并希望同步替换 Jira 的团队，ONES 的迁移路径与一体化结构较为契合；若企业知识库大量依赖高度定制的宏或第三方插件，应把对应能力的核验放在迁移决策之前。
Notion
Notion在Confluence替代选型中通常对应“文档、知识库与轻量项目协作放在同一工作空间”的需求。它适合希望把团队 wiki、会议记录、项目说明和任务清单集中管理的团队，尤其是产品、研发、运营等跨职能小组；如果组织需要严格的页面层级、细粒度权限审批或大规模历史内容治理，选型时需要重点核验对应能力。
从文档结构看，Notion 以页面为基本单位，页面可以无限嵌套，并通过数据库视图把同一批内容组织成表格、看板、日历或列表。迁移 Confluence 空间时，这种结构适合把原本按空间和页面树组织的知识重新梳理为“团队主页—项目主页—具体文档”的层级，同时用数据库承载需求清单、会议台账或文档索引。需要留意的是，页面嵌套和数据库视图的灵活性会带来信息架构设计成本，迁移前宜先确定命名规则、页面归属和归档方式，避免内容散落在多个入口。
协作编辑方面，Notion 支持多人同时编辑页面、评论和提及成员，页面内可嵌入任务、文件和外部内容。对于 Confluence 中常见的会议纪要、方案评审和项目周报，团队可以在同一页面完成撰写、讨论和待办跟进。模板能力可以通过内置模板或团队自建模板实现，把周报、需求文档、复盘记录等固定格式沉淀下来。与 Confluence 的宏体系相比，Notion 的嵌入块和数据库视图覆盖常见展示需求，复杂宏或特定页面布局在迁移时需要逐项核对呈现效果。
权限粒度是选型核验的重点。Notion 的工作空间、团队空间和页面层级提供访问控制，企业版还涉及更细的管理能力；具体到“页面级只读”“数据库行级权限”“外部访客范围”等要求，应结合当前套餐和官方文档确认。搜索能力覆盖工作空间内的页面和数据库内容，迁移后可通过统一入口检索；如果历史内容量大，建议在迁移前清理重复页面、补齐标题和关键词，减少检索噪声。
迁移导入路径方面，Notion 提供从 Confluence 等工具导入的入口，常见做法是导出 Confluence 空间为 HTML 或压缩包后导入，再检查页面层级、附件、图片和表格的还原情况。迁移前宜选取一个代表性空间做小范围试导，确认页面链接、附件路径和权限继承是否符合预期。API 与集成方面，Notion 提供 API 和常见第三方集成，适合把文档与项目管理、自动化流程连接起来；具体集成范围和数据同步频率需按实际工具链核验。
适配建议：如果团队的核心诉求是让知识文档和任务清单在同一空间内协作，并愿意投入时间设计页面结构和模板，Notion 可以作为 Confluence 的替代方案之一。落地时先明确空间划分和权限模型，选一个空间试迁移，再逐步推广；对权限、审计、大规模内容治理有硬性要求的组织，应在选型阶段把这些条件列为核验项，结合试用结果判断。
Microsoft SharePoint
Microsoft SharePoint是微软面向企业内容管理与团队协作的平台，通常随 Microsoft 365 一起使用，适合已经采用微软办公体系、需要把文档、知识库、流程和权限管理放在同一平台上的组织。把它列入 Confluence 替代清单，主要原因是它覆盖文档协作、页面化知识组织、企业搜索和权限控制等与 Confluence 重叠的场景，同时能与 Word、Excel、Teams、Outlook 等工具形成连贯的日常使用路径。
在文档结构上，SharePoint 通过站点、文档库和页面组织内容。团队可以为部门、项目或主题建立独立站点，用页面承载说明性内容，用文档库承载文件，并通过元数据、视图和内容类型对资料分类。对于知识库类需求，这种结构适合把“页面阅读”和“文件沉淀”放在一起管理；代价是信息架构需要提前规划，站点和库的数量、命名、导航层级要有统一约定，否则内容容易分散在多个站点中。选型时可以重点核验：现有 Confluence 空间如何映射为站点或文档库，页面层级和标签体系如何落地。
权限粒度是 SharePoint 的强项之一。它支持在站点、库、文件夹、页面和单个文件等层级设置访问权限，并可与 Microsoft 365 组、Entra ID 安全组结合，按组织架构或项目角色分配访问范围。对于需要区分部门、外部合作方或敏感资料的企业，这种细粒度控制有实际价值。使用条件是权限模型需要治理：继承关系、共享链接和外部访问策略要提前设计，避免出现权限过宽或维护成本上升。选型时应核验默认共享设置、外部共享策略以及权限审计能力。
搜索、模板与集成方面，SharePoint 提供企业搜索，可检索站点内容、文档和页面，并支持按内容类型、修改时间等条件筛选；页面和文档库可以配置模板，供团队按统一格式创建内容；通过 Microsoft Graph API、Power Automate 和 Power Apps，可以把审批、通知、数据同步等动作接到现有业务流程中。与 Confluence 相比，SharePoint 的模板和宏体系更偏向微软生态内的页面与文档组合，复杂页面布局和富交互宏的丰富度需要按实际页面样例核验。迁移导入路径通常需要借助第三方迁移工具或脚本，把 Confluence 空间、页面和附件导入 SharePoint 站点，选型时应确认页面层级、内链、附件和权限的保留程度。
协作编辑方面，SharePoint 文档库中的 Office 文件支持多人同时编辑和版本历史，页面也支持协同编辑与版本记录，适合文档与知识内容并行维护的团队。适配建议是：如果组织已经使用 Microsoft 365，且知识库需要与文档、流程、权限体系紧密结合，SharePoint 可以作为 Confluence 的替代方向；实施时先选一个部门或项目做站点结构和权限模型试点，验证搜索效果、页面模板和迁移结果，再逐步扩展。部署方式与合规细节在本次资料中未展开，选型阶段需要向微软或授权服务商核验云版本、区域部署和合规认证等具体条件。
Google Workspace(Google Docs)
Google Workspace（Google Docs）适合已经把日常办公放在 Google 生态里的团队，用来承接原先由 Confluence 承载的文档协作与知识沉淀。它的核心对象是文档、表格、幻灯片和云端硬盘中的文件，页面层级由文件夹与文档之间的链接组织，适合以项目资料、会议记录、流程说明、产品需求等文档型内容为主的团队。对于希望减少自建服务器维护、让成员在浏览器里直接编写和共享资料的场景，这套工具的上手路径较短。
在协作编辑方面，Google Docs 支持多人同时编辑同一文档，光标位置、评论和修改建议实时可见，成员可以通过评论指派任务、用建议模式提出修改，再由文档所有者接受或拒绝。这套机制适合需求评审、方案讨论和制度起草这类需要反复交换意见的工作。文档的版本记录会保留修改历史，可以查看不同时间点的内容并恢复，减少误改带来的返工。与 Confluence 的页面树相比，Google Docs 更偏向单篇文档的协作，跨文档的层级浏览需要借助文件夹结构和共享链接来补足，团队在迁移时应先约定目录命名和索引页的做法。
搜索能力依托 Google 的云端搜索，可以在云端硬盘中按文件名、正文关键词和文件类型查找，也能在 Gmail、日历等关联内容中检索。对于文档数量较多的团队，建议在迁移前统一文档标题规则，并在关键文档中维护标签或索引页，让搜索结果更容易被定位。权限方面，Google Drive 支持按文件或文件夹设置查看、评论、编辑权限，并可限制链接分享范围，适合按项目或部门划分访问边界。涉及敏感资料时，需要结合组织的共享政策核验外部分享、链接有效期等设置，避免默认开放范围过宽。
模板与集成是这套工具在日常使用中的实际抓手。Docs 提供会议纪要、项目计划、报告等模板，团队也可以把常用格式固化为自定义模板，减少每次新建文档时的重复排版。通过 Google Workspace Marketplace 可以接入项目管理、签名、图表等第三方应用，API 方面提供 Docs API、Drive API 等接口，便于把文档创建、内容读取和权限管理接入内部系统。迁移导入时，可以把 Confluence 导出的 HTML 或 Word 文件上传到云端硬盘，再按文件夹整理；页面间的链接和附件需要逐项检查，宏类内容通常要改写成文档内的表格、链接或嵌入内容。迁移前建议先选一个空间做试点，确认目录结构、权限继承和搜索效果后再批量推进。
适配建议上，如果团队已经使用 Gmail、日历和 Meet，Google Docs 能减少账号与通知体系的割裂，日常文档协作可以直接在浏览器和移动端完成。需要重点核验的是数据存放区域、合规认证和保留策略，这些信息在选型阶段应向供应商确认；同时要评估大量历史页面迁移后的目录维护成本，以及是否需要配合第三方工具做批量导入和链接修复。对于以文档协同为主、接受用文件夹加索引页组织知识的团队，这套方案可以作为 Confluence 的替代路径之一。
语雀
语雀适合希望用中文知识库承载团队文档、项目资料与制度沉淀的组织，尤其适合内容协作频繁、需要把零散文档整理成结构化知识体系的团队。在 Confluence 替代选型中，语雀的评估重点可以放在文档组织方式、协作编辑体验和权限管理上，同时把迁移导入路径与 API 集成能力列为选型时需要实际核验的事项。
文档结构与知识组织是语雀与 Confluence 使用场景最接近的部分。语雀以知识库为单位组织内容，知识库内通过目录树管理文档层级，适合把项目文档、产品说明、会议记录和团队规范分门别类地沉淀。对于从 Confluence 迁移过来的团队，这种“空间—页面树”的对应关系比较直观，迁移后可以沿用按项目或按部门划分知识库的习惯。选型时建议确认目标版本对知识库数量、目录层级和文档类型的支持范围，并结合团队现有页面数量规划知识库拆分方式。
协作编辑与权限粒度直接影响日常使用。语雀支持多人同时编辑文档，评论、提及和版本记录等能力可以覆盖评审与修改留痕的常见需求。权限方面，语雀提供知识库和文档层面的权限设置，团队可以按成员、部门或群组分配查看与编辑权限。对于 Confluence 中依赖页面级权限控制的场景，选型时需要逐项核对语雀在文档级、知识库级权限上的具体配置方式，确认能否满足敏感资料的分级管理要求。
模板与搜索关系到迁移后的使用效率。语雀提供文档模板，团队可以把常用的周报、需求文档、会议纪要等格式固化为模板，减少重复搭建结构的时间。搜索能力覆盖知识库内文档内容，便于在资料积累后快速定位。选型时建议用团队真实文档做一次搜索与模板试用，确认中文分词、附件内容检索等细节是否符合预期。
迁移导入与 API 集成是本次选型需要重点核验的环节。语雀支持从常见文档格式导入内容，但 Confluence 页面导出后的结构、附件和权限能否完整还原，需要在实际迁移前用小批量页面做验证。API 与集成方面，语雀提供开放接口，具体能覆盖哪些自动化场景、是否支持与现有身份系统和研发工具链对接，应以官方文档和实际测试为准。价格与部署方式同样建议在选型阶段向官方确认，再结合团队规模和安全要求做决定。
适配建议上，如果团队以中文内容协作为主、希望用知识库方式沉淀项目与制度资料，语雀可以作为重点评估对象；迁移前先完成小范围页面导入和权限配置验证，再分批推进全量迁移，能够降低切换过程中的不确定性。
飞书文档
飞书文档是飞书套件中的在线协作文档产品，适合已经在使用飞书办公、希望把知识库、项目文档和日常协作放在同一工作台内完成的团队。在 Confluence 替代选型中，它对应的典型对象是重视实时协作、文档与聊天及日历任务联动、并愿意以云端 SaaS 方式承载知识内容的组织。对于需要把大量历史页面从 Confluence 迁出的团队，飞书文档可以作为候选之一，但迁移路径与集成细节应在选型阶段逐项核验。
文档结构与协作编辑是它承接 Confluence 知识库场景的核心。飞书文档以页面树和空间组织内容，支持多人同时编辑、评论、提及和行内讨论，文档可嵌入表格、看板、任务列表等块，适合把会议纪要、需求说明、项目复盘写成可协作的活文档。与 Confluence 以页面为中心、依赖宏扩展内容的模式相比，飞书文档更强调文档内直接承载结构化块和轻量任务，团队在迁移时需要把原有宏和页面模板重新映射为对应的块或模板。
权限与搜索方面，飞书文档依托飞书组织架构做可见范围控制，可按成员、部门、群组或指定人员设置文档权限，支持对外分享链接并设置访问范围。搜索覆盖文档标题与正文，并可在飞书全局搜索中跨消息、文档、日历等对象检索。选型时应重点核验两点：一是细粒度权限能否满足原有 Confluence 空间的分层管理习惯，二是跨空间、跨团队的搜索范围与结果排序是否符合知识库使用预期。
API 与集成、迁移导入是本次资料未充分覆盖的部分。飞书开放平台提供文档相关接口，具体到批量导出、页面结构保留、附件处理和权限映射的完整迁移方案，需要在选型时向厂商确认或通过试点验证。若团队已有 Confluence 页面数量大、宏依赖多，建议先用一批代表性页面做导入测试，观察层级、附件、评论和权限的还原程度，再决定迁移批次和人工整理工作量。
适配建议：已经在飞书内沟通协作的团队，可以把飞书文档作为知识库与项目文档的统一入口，减少在多个工具间切换；对权限分层要求严格、或需要复杂宏渲染和深度自定义页面的团队，应把权限模型和宏替代方案列为核验重点。部署方式上，飞书文档以云端服务为主，适合接受 SaaS 模式的团队；若有特殊的数据驻留或合规要求，需在选型阶段确认可用方案。整体上，飞书文档适合把协作效率放在首位、并愿意在迁移时做内容结构梳理的组织。
切换条件与选择建议
切换是否值得推进，取决于保留能力清单的覆盖度和迁移成本，而不是候选工具的功能数量。可以按团队类型先确定方向：研发流程一体化需求强的团队，优先评估能把知识库与项目、测试、需求管理放在同一平台的候选；纯文档协作团队，优先看编辑体验、模板和搜索；有私有化与合规要求的组织，把部署形态和认证清单放在筛选前面；预算敏感的团队，先核算许可、迁移人工和后续运维的总成本，再比较报价。
无论选择哪款工具，切换前需要完成四项前置条件：
- 内容盘点：统计空间数量、页面数量、附件体积、宏与插件使用清单，识别需要人工处理的页面类型。
- 权限映射：把现有空间与页面权限对应到目标工具的权限模型，确认用户组和外部访问范围如何落地。
- 试点空间：选取一个有代表性的空间试迁，验证页面层级、附件、宏、搜索和权限的还原效果。
- 回退方案：保留旧站只读访问和导出能力，明确试点不达标时的回退步骤和责任人。
分阶段路径建议按四步推进：
- 试点迁移：迁移 1 至 2 个代表性空间，核对内容还原和权限配置，记录需要人工处理的页面清单。
- 并行运行：新工具承接新增文档，旧站保持只读，团队在过渡期同时可查历史内容。
- 全量切换：按空间分批迁移剩余内容，完成权限复核和搜索验证后关闭旧站编辑入口。
- 旧站只读归档：保留旧站访问一段时间，处理遗漏链接和引用，确认无业务依赖后再下线。
以下情形建议暂缓替换：保留能力清单中的必须项在试点中无法达到验收条件；宏与插件依赖复杂且替代方案需要大量二次开发；迁移窗口与业务高峰期冲突；合规认证或部署形态尚未确认。暂缓不等于放弃，可以把试点结论作为下一轮评估的输入，先解决权限模型、内容治理或插件替代中的关键问题，再推进切换。
常见问题
Confluence 空间里的页面权限和用户组，迁移后需要重新配置吗？
取决于目标工具的权限模型和迁移方式。以 ONES 的 Confluence 迁移方案为例，迁移数据包括用户、用户组、空间权限与页面权限，权限结构随内容一并迁移到 ONES Wiki，可以减少迁移后重新配置的工作量。其他候选的权限映射方式差异较大，建议在试点阶段用真实空间验证：迁移后抽查若干页面，确认原空间成员、页面限制访问和外部访问范围是否与迁移前一致，再决定是否需要批量补配。
Confluence 里的宏和插件很多，迁移时怎么判断哪些必须处理？
先统计实际使用清单，而不是按插件市场里的安装记录判断。把页面按宏使用频率排序，区分高频常用宏和少量定制宏：高频部分要求目标工具能直接呈现或提供等价写法，定制部分逐项评估替代成本。ONES 的迁移范围覆盖常用宏，并结合流程自动化和开放能力承接常用插件场景，但企业已有的定制场景仍需逐项评估，不能假设所有插件都能一一对应。其他候选的宏替代方式各不相同，建议用含宏的代表性页面做导入测试后再定处理方案。
团队规模不大、预算有限，是否值得从 Confluence 迁出？
先算总成本再判断：许可费用之外，还要计入迁移人工、页面整理、权限重配和过渡期并行维护的投入。如果现有 Confluence 使用稳定、宏依赖少、合规要求没有变化，迁移的收益可能有限；如果主要压力来自许可成本或维护负担，可以优先评估按需付费的云端文档协作工具，并用一个空间试点核算实际迁移工时。预算敏感时，把试点结论作为报价比较的依据，比只看单价更接近真实成本。
试点迁移应该选什么样的空间，验证哪些内容？
选一个有代表性、但影响面可控的空间：页面类型要覆盖日常主要用法，例如含附件的方案文档、含表格的周报、有多次修改记录的规范页、设置了页面级权限的敏感资料。验证项对应保留能力清单逐条检查：页面层级是否还原、附件能否打开、内链是否可跳转、历史版本是否完整、中文关键词和附件内容能否搜到、常用宏呈现是否正常、权限是否随内容落地。试点结论要形成书面记录，作为全量迁移批次划分和人工处理工作量的依据。
旧 Confluence 站点什么时候可以下线？
建议在全量切换完成后保留一段只读期，用于处理遗漏链接、外部引用和员工查找历史资料的需求。下线前确认三件事：新平台已承接全部在用空间，旧站访问日志中不再有实际业务依赖，历史内容已完成导出备份。只读期长度按团队内容量和外部引用情况确定，涉及对外分享链接或审计留存的场景，需要先确认保留要求再安排下线时间。
