Confluence 的替代要先分清哪些能力必须原样保留、哪些用法可以换一种实现。页面与空间结构、权限、历史版本、搜索、附件、模板与宏、外部协作和集成方式，需要逐项确认。候选方案可按知识库型、文档协作型、研发一体化平台三类评估，切换前用一个有代表性的空间做试迁移，验证结构还原、权限继承和链接可用性，再安排全量切换节奏。
要点总览（TL;DR）
- 替换 Confluence 前先列能力保留清单：空间与页面层级、权限模型、版本历史、全文搜索、附件、高频宏列为必须保留项，编辑器习惯、插件生态、外部协作入口可调整。
- 候选按三类评估：研发流程割裂优先看研发一体化平台（如 ONES），协作范围扩展到业务部门优先看文档协作型（飞书文档、钉钉文档、SharePoint），轻量知识沉淀优先看知识库型（语雀、Notion）。
- ONES 的 Confluence 迁移方案可将空间、页面、附件和权限结构迁入 ONES Wiki，迁移范围含用户、用户组、空间权限与页面权限、页面正文、图片、常用宏及批注；特殊宏、历史版本和链接重写需在试迁移中逐项确认。
- 试迁移选一个结构完整、权限有代表性的空间，验收页面层级还原、权限继承、历史版本可查、内链与附件可用、搜索命中；通过后再按空间分批全量切换，并行期保留旧系统只读访问并写明回退预案。
Confluence 替代要先确认哪些能力必须保留
替换 Confluence 的动因通常集中在许可与成本、部署位置与数据归属、知识库与研发流程脱节、协作范围从研发扩展到业务部门这几类。动因决定评估重点：如果主要动因是数据位置和合规，部署方式与权限模型的权重会上升；如果主要动因是研发协作割裂，文档与需求、测试、发布流程的衔接方式就成为核心标准。把动因写清楚，后续比较才不会变成单纯的功能数量对照。
能力清单建议分成“必须保留”和“可调整”两组。必须保留项指迁移后如果缺失会直接影响业务连续性的能力，例如空间与页面层级、权限模型、版本历史、全文搜索、附件、模板与高频宏。可调整项指团队可以接受换一种实现方式的能力，例如页面编辑器的操作习惯、插件生态、外部访客协作的具体入口、与代码和需求系统的联动深度。分组时以实际使用频率和影响范围为判断依据，避免把个人编辑偏好列为硬性要求。
把清单落成字段表，后续候选比较和试迁移验收都使用同一张表：
| 能力项 | 现状用法 | 判定 | 验证方式 |
|---|---|---|---|
| 空间与页面层级 | 按部门、项目划分空间，页面树三到四层 | 必须保留 | 试迁移后核对目录层级与页面归属 |
| 权限模型 | 空间权限为主，敏感页面单独限制 | 必须保留 | 抽样账号登录验证可见范围 |
| 版本历史 | 用于追溯文档修改与评审记录 | 必须保留 | 迁移后查看历史版本是否可查、可恢复 |
| 全文搜索 | 按标题、正文、附件查找资料 | 必须保留 | 用已知关键词检索，核对命中结果 |
| 附件 | 设计稿、表格、文档随页面存放 | 必须保留 | 检查附件数量、格式与预览效果 |
| 模板与宏 | 目录、状态标签、信息面板、任务列表 | 高频项保留，低频项可调整 | 统计宏使用分布，逐类确认对应写法 |
| 页面编辑器习惯 | 团队已熟悉现有编辑操作 | 可调整 | 培训与试用反馈 |
| 插件生态 | 部分页面依赖第三方插件生成内容 | 可调整 | 列出插件清单，逐项确认替代实现 |
| 外部访客协作 | 客户、供应商查看或评论部分页面 | 可调整 | 验证分享范围与访问控制 |
| 研发系统联动 | 页面引用需求单、缺陷单 | 视流程依赖程度判定 | 验证链接、状态同步与通知路径 |
清单完成后，先做一次内部确认：每项“必须保留”的能力都要有明确的使用场景和负责人，避免迁移后才发现某项能力实际无人使用却占用了评估资源。对“可调整”项，也要写清可接受的替代方式，例如宏改为静态内容或结构化表格，插件生成的内容改为手工维护页面。
候选方案与 Confluence 基准差异对照
下表把 Confluence 作为基准行单列，标明其为被替代对象，不计入候选。候选按知识库型、文档协作型、研发一体化平台分组，对照维度沿用能力清单中的关键项。表中只写可确认的差异，未确认项标注待验证，具体以试迁移结果为准。
| 方案 | 类型 | 页面与空间结构 | 权限与历史版本 | 搜索与附件 | 模板与宏 | 外部协作 | 部署方式 | 与研发流程衔接 |
|---|---|---|---|---|---|---|---|---|
| Confluence（基准，被替代对象） | 知识库型 | 空间加页面树，层级较深 | 空间与页面级权限，版本历史完整 | 全文搜索覆盖页面与附件 | 宏生态丰富，插件扩展多 | 支持访客与外部协作配置 | 云版与数据中心版 | 与 Jira 等研发工具联动成熟 |
| ONES | 研发一体化平台 | ONES Wiki 承载空间与页面，支持从 Confluence 迁移空间、页面、附件与权限结构 | 支持迁移用户、用户组、空间权限与页面权限；历史版本迁移情况待验证 | 附件、图片在迁移范围内；迁移后搜索表现待验证 | 支持常用宏迁移，特殊宏需逐项评估 | 待验证 | 支持国产化、私有化，具体选项待确认 | 与项目管理、测试管理在同一平台衔接 |
| 飞书文档 | 文档协作型 | 知识库加文档层级，适合按团队或主题组织 | 文档级与知识库级权限，历史版本可查看恢复 | 搜索覆盖标题、正文与附件内容 | 内置模板与文档组件，复杂宏需替代 | 支持链接分享与外部联系人协作 | 云端 SaaS | 与飞书内任务、日历、消息联动，外部研发系统需评估 |
| 钉钉文档 | 文档协作型 | 知识库加页面树，适合按部门或项目划分 | 知识库与页面权限，保留编辑历史 | 搜索覆盖组织内可访问文档，附件随页面存放 | 文档、表格、多维表模板，宏需逐类确认 | 支持分享链接与外部联系人 | 以云端服务为主，私有化选项待核实 | 依托钉钉内项目与任务协同，与原研发系统需保留链接对应 |
| 语雀 | 知识库型 | 知识库加目录树，结构清晰 | 知识库成员权限，文档保留历史版本 | 站内搜索，附件可上传预览 | 内置常用模板，宏需改写或简化 | 支持分享链接与邀请成员 | 以 SaaS 为主，部署形态待确认 | 可通过链接与开放接口配合，自动联动需评估 |
| Notion | 知识库型 | 工作区、团队空间与页面嵌套，页面可兼作数据库视图 | 页面级共享与团队空间权限，版本记录可用 | 搜索覆盖页面内容，附件挂在页面中 | 模板与数据库视图可替代部分宏，动态报表需重建 | 支持访客权限与链接分享 | 以 SaaS 为主 | 适合承载需求与产品文档，任务跟踪交给专业工具 |
| Microsoft SharePoint | 文档协作型 | 站点、文档库与页面组织，适合部门或项目门户 | 沿用 Microsoft 365 账号体系，站点、库、文件级权限，版本历史默认保留 | 搜索覆盖站点内容与文档，依赖元数据规范 | 页面模板与文档模板，流程化提醒可用列表与自动化实现 | 支持外部共享，受租户策略约束 | 以 Microsoft 365 云服务为主，也有本地部署版本 | 可与 Teams、Planner、Azure DevOps 等配合，深度取决于配置 |
从对照表可以看出初步筛选方向：如果替换动因以研发流程割裂为主，研发一体化平台和具备开放接口的知识库型方案更值得优先评估；如果动因是协作范围扩展到业务部门，文档协作型方案在编辑体验和消息联动上更直接；如果组织已经以微软生态为办公底座，SharePoint 在账号、权限和 Office 文件协同上衔接成本较低。表中“待验证”项应在试迁移中逐项落实，不能仅凭对照表做最终决定。
候选方案逐一评估
ONES
ONES 面向以 Confluence 替换与迁移为目标的团队，提供将 Confluence 空间、页面、附件和权限结构迁移到 ONES Wiki 的方案，并把知识库与项目管理放在同一平台中衔接。对于正在做研发工具国产化替换、希望迁移后保持知识组织方式并减少系统割裂的中大型企业，这一方案与迁移任务直接相关。
迁移覆盖范围与知识组织延续。ONES 的迁移方案支持将 Confluence 的空间、页面、附件和权限结构迁入 ONES Wiki，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注也在迁移范围内。迁移方式提供批量迁移与数据包导入，团队可按数据规模和网络条件选择。这样处理的价值在于，原有空间划分和页面层级能够继续作为知识查找入口，权限关系随数据一并落地，减少迁移后重新整理目录和逐页授权的工作量。
与研发流程的衔接。ONES 用一体化平台连接项目管理和知识库管理，针对 Jira 与 Confluence 数据分散、系统割裂的情况，把需求、任务、测试与文档放在同一工作环境中。对于常用插件场景，方案通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，降低迁移后的二次适配成本。适配建议是：迁移前先梳理团队实际使用的插件和宏，把常用项列入功能匹配清单；企业已有的定制插件和深度集成需要逐项评估，按实际使用频率决定保留、替代或调整流程。
使用条件与核验点。方案中的宏迁移限定为“常用宏”，特殊宏需要逐项确认迁移效果；空间与页面层级还原的完整度、迁移后的全文搜索表现，建议在正式迁移前用代表性空间做试迁移验证。历史版本是否随迁移保留，资料未作说明，应列入迁移前确认清单。部署方面，ONES 支持国产化、私有化和安全合规要求，具体适配的软硬件清单、部署选项与合规资质需向厂商确认。迁移节奏上，ONES 建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。
适配建议。适合以 Confluence 替换为明确目标、同时使用 Jira 并希望统一研发与知识管理的团队。实施时可按空间分批切换：先选一个结构完整、权限关系有代表性的空间试迁移，核对页面层级、权限继承、附件和常用宏的呈现，再逐步扩大范围。对依赖特殊宏或定制插件的页面，提前列出清单并安排替代方案，能减少切换期间的业务中断。
飞书文档
飞书文档适合已经或计划使用飞书作为日常协作平台、希望把知识库与即时沟通、会议、任务放在同一工作空间内的团队。在 Confluence 替代与迁移的语境下，它的价值集中在文档协作体验和团队日常信息流转的连贯性：页面以文档形式承载，空间对应团队或项目，评论、提及、任务分配与消息通知在同一产品内完成。对于内容以中文为主、协作频繁、需要业务与研发共同阅读和维护知识库的组织，这种一体化路径能减少在多个工具之间切换的成本。
页面与空间结构方面，飞书文档支持用文件夹和知识库组织页面层级，知识库可设置成员与访问范围，适合按团队、项目或主题划分内容边界。迁移 Confluence 时，需要先梳理原有空间与页面的对应关系：哪些空间整体平移到独立知识库，哪些页面按主题合并或拆分。飞书文档的页面结构偏向文档式阅读与协作，层级较深的传统 wiki 目录需要重新设计导航，建议在迁移前确定两到三层的目录规范，避免把旧结构原样搬运后难以维护。
权限与历史版本是迁移中需要重点核验的环节。飞书文档提供文档级和知识库级的权限设置，支持按成员、部门或群组授权，历史版本可查看和恢复。Confluence 中常见的按页面树继承权限、匿名访问、外部协作者访问等配置，迁移后需要逐项对照确认。涉及敏感内容的页面，建议在迁移前整理权限清单，迁移后抽样验证实际访问效果。版本历史方面，迁移工具通常保留页面内容与部分版本记录，具体保留范围和格式需要在正式迁移前用小批量页面试跑确认。
搜索与附件、模板与宏直接影响迁移后的使用体验。飞书文档的搜索覆盖文档标题、正文和附件内容，附件可直接上传并预览常见格式，适合把 Confluence 中的图片、表格和办公文件随页面一并迁移。模板方面，飞书提供文档模板和知识库模板，团队可沉淀常用页面结构；Confluence 中依赖宏实现的内容，如目录、状态标签、信息面板、任务列表等，部分可由飞书文档的内置块和组件对应实现，复杂宏或第三方插件生成的内容则需要评估替代方案，必要时改为静态内容或简化呈现。迁移前建议统计宏的使用分布，优先处理高频宏。
外部协作与部署方式需要结合组织边界判断。飞书文档支持通过链接分享、邀请外部联系人协作，适合与客户、供应商共同编辑或评审文档；具体的外部访问范围和审批要求以组织配置为准。部署上，飞书文档为云端 SaaS 服务，由平台统一维护升级，组织需要确认数据存放、合规要求和网络访问条件是否满足自身要求。与研发流程衔接方面，飞书文档可与飞书内的任务、日历、会议和机器人消息联动，页面中的待办可直接指派给成员；如果研发团队使用其他代码托管或项目管理工具，需要评估文档与这些系统之间的链接、通知和自动化衔接方式，避免知识库成为信息孤岛。
适配建议：迁移可分三步推进。先选取一个结构清晰、使用活跃的空间做试点，验证页面导入、权限映射、附件和宏的处理效果；再根据试点结果确定目录规范、模板和权限策略，批量迁移其余空间；最后保留一段并行期，让团队在新旧入口之间过渡，收集搜索和导航方面的反馈后再下线旧系统。对于页面数量多、宏依赖重的组织，建议把迁移拆成内容迁移和结构优化两个阶段，先保证内容完整，再逐步调整页面组织。飞书文档的协作体验和平台一体化是其主要优势，迁移成效则取决于前期对权限、宏和目录结构的梳理是否充分。
钉钉文档
钉钉文档面向已经在使用钉钉组织通讯录和日常协作的企业团队，适合把知识库、项目文档和会议纪要集中到同一套账号体系下管理。在 Confluence 替代与迁移的场景中，它的价值主要在于文档与组织架构、群聊、日程、审批等协同入口天然连通，迁移后的内容可以直接被现有成员按部门、角色找到并使用，减少另建一套账号和权限体系的成本。
页面与空间结构方面，钉钉文档以知识库承载成组的页面，知识库内可建立页面树，适合把 Confluence 中的空间按业务线、项目或部门对应过来。迁移时建议先梳理原空间的层级深度，把过深的页面树压缩到两到三层，再按“知识库—页面—子页面”的对应关系落位，避免把历史层级原样搬运造成导航冗长。权限与历史版本上，钉钉文档支持按知识库、页面设置协作者和访问范围，并保留页面编辑历史，可查看和恢复较早版本，这对迁移后核对内容完整性、纠正导入错位比较实用。需要核验的是原 Confluence 页面级限制在目标端能否一一对应，尤其是仅对少数人开放的敏感页面，迁移前应单独列出并逐页确认可见范围。
搜索与附件是迁移后使用频率最高的环节。钉钉文档的搜索覆盖组织内可访问的文档内容，附件随页面存放，便于在页面上下文里直接查阅。迁移大批量附件时，建议先统计原空间的附件体积和类型，确认单页附件数量与大小在目标端的使用体验，再决定哪些大文件改为链接引用。模板与宏方面，钉钉文档提供文档、表格、多维表等模板，可覆盖会议纪要、项目计划、需求记录等常见场景；Confluence 中依赖宏实现的目录、状态标记、信息面板等，需要在迁移时逐类确认目标端是否有对应写法，复杂宏建议改为静态内容或结构化表格，避免迁移后出现空白占位。
外部协作上，钉钉文档可通过分享链接、邀请外部联系人参与的方式支持与客户、供应商的共同编辑，适合需要把部分文档开放给组织外部的场景。使用前应确认外部访问的开关策略和水印、下载限制等管控项是否符合企业要求，涉及合同、报价等敏感内容时优先采用限定范围的分享方式。部署方式以钉钉云端服务为主，企业无需自建服务器，迁移工作量集中在内容梳理和权限重建上；对数据驻留或私有化有明确要求的企业，需要在选型阶段向服务方核实可用的部署选项。
与研发流程衔接是钉钉文档在替代 Confluence 时差异较明显的一环。Confluence 常与 Jira 的需求、缺陷条目互相引用，钉钉文档则更多依托钉钉内的项目、任务和群聊协同。若研发团队的需求管理仍在原有系统，建议保留文档中的需求编号和链接字段，用统一命名规则维持文档与工单的对应关系；若研发协作也迁入钉钉生态，则可以把需求说明、评审记录、发布说明放在同一知识库下，按迭代建立子页面。适配建议是：先选一个中等规模的空间做试点迁移，验证页面层级、权限映射、附件和宏的处理方式，形成可复用的迁移清单后再批量推进；对历史归档类内容，可按只读方式集中存放，减少迁移后的维护负担。
语雀
语雀是蚂蚁集团旗下的云端知识库与文档协作产品，以“知识库—文档—团队”的结构组织内容，适合把分散在个人电脑、聊天记录和邮件里的项目资料、产品文档、团队规范集中到可检索、可协作的空间中。对于正在评估 Confluence 替代方案、希望把知识沉淀从本地部署的重型平台转向云端轻量协作的团队，语雀的吸引力主要在于上手门槛低、编辑体验接近日常文档工具，成员无需专门培训就能开始写页面和整理目录。
页面与空间结构方面，语雀用知识库承载一组相关文档，知识库内通过目录树组织页面层级，团队可以按项目、部门或主题建立多个知识库，并用成员角色区分可阅读、可编辑和可管理的范围。迁移 Confluence 时，常见的做法是先梳理原空间与页面的对应关系，把每个 Confluence 空间映射为一个语雀知识库，再按原页面树重建目录。语雀提供文档导入能力，可处理 Word、Markdown 等常见格式，但 Confluence 原生导出格式的还原程度、页面内宏和附件的迁移效果，需要在正式迁移前用一批代表性页面做小范围试导，确认标题层级、表格和图片是否完整。
权限与历史版本是迁移评估中需要重点核验的部分。语雀支持知识库级别的成员权限设置，文档编辑过程会保留历史版本，便于回溯修改。对于 Confluence 中依赖细粒度页面权限、按用户组授权或页面级限制访问的场景，团队应提前确认语雀的权限粒度能否覆盖原有管理要求，尤其是涉及敏感项目资料、跨部门可见性的知识库。历史版本方面，可核对版本保留范围与恢复操作是否符合团队的审计和追责习惯。
搜索与附件、模板与宏直接影响迁移后的日常使用。语雀提供站内搜索，能够按标题和正文查找文档，附件可作为文档内容上传和预览；模板方面，语雀内置了会议记录、项目计划、周报等常用模板，团队也可以把自有的文档格式保存为模板复用。Confluence 中大量使用的宏（如状态标签、任务列表、目录宏、信息面板）在迁移后可能需要改用语雀的对应写法或简化处理，建议在试导阶段统计高频宏的使用情况，评估哪些可以替换、哪些需要调整页面写法。
外部协作与部署方式需要结合团队边界判断。语雀以 SaaS 云端服务为主，外部协作者可通过分享链接或邀请成员的方式参与，适合与客户、供应商共享部分文档的场景；如果组织对数据存放位置、网络隔离或私有化部署有硬性要求，应提前确认语雀的部署形态与合规条件是否匹配，这类信息以官方最新说明为准。与研发流程衔接方面，语雀可与代码托管、持续集成等工具通过链接和开放接口配合，把需求文档、接口说明、发布记录放在知识库中供研发查阅；如果团队希望文档状态与需求单、缺陷单自动联动，需要评估接口能力和实际配置工作量。
适配建议：把语雀作为 Confluence 替代方案时，适合优先迁移结构清晰、以文档阅读和协作编辑为主的知识库，例如产品文档、技术方案、团队规范和会议纪要；对权限颗粒度要求高、宏依赖重或必须私有化部署的空间，先做试点迁移并逐项核验，再决定迁移批次和页面改写范围。迁移前建立页面清单与负责人，迁移后安排一轮链接检查和搜索测试，能减少切换期找不到资料的情况。
Notion
Notion在 Confluence 替代与迁移的讨论中，通常被放在“文档、知识库与项目协作一体化”的位置上。它适合那些希望把团队 wiki、项目说明、会议记录和轻量任务放进同一工作空间的团队，尤其是内容型团队、产品与运营团队，以及规模不大但文档更新频繁的组织。与以页面树和空间为核心的传统 wiki 相比，Notion 的组织方式更接近“页面即数据库、页面即工作台”，迁移时需要先接受这套信息组织逻辑。
从页面与空间结构看，Notion 用工作区、团队空间和页面层级来承载内容，页面可以无限嵌套，也可以通过链接和数据库视图形成交叉引用。迁移 Confluence 时，空间可以对应到 Notion 的团队空间或顶层页面，页面树大体能保留层级关系，但宏、复杂表格和部分富文本格式往往需要人工整理。权限与历史版本方面，Notion 支持页面级共享、团队空间权限和版本记录，适合按项目或部门划分可见范围；迁移前建议先梳理 Confluence 中依赖空间权限和页面限制的内容，确认哪些页面需要重新设置访问范围。搜索与附件能力可以覆盖日常查找，附件直接挂在页面中，迁移大量附件时需要预留整理和校验时间。
模板与宏是迁移中最需要提前评估的部分。Notion 的模板和数据库视图可以替代一部分 Confluence 宏的用途，例如状态看板、任务清单、会议记录模板和内容索引，但 Confluence 中依赖特定宏实现的动态内容、报表和页面嵌入，通常需要改成 Notion 的数据库、嵌入或手动维护的页面。外部协作方面，Notion 可以通过分享链接、访客权限和评论协作让外部伙伴参与页面，适合与客户或供应商共享项目资料；涉及敏感内容时，需要逐页确认分享范围和链接权限。部署方式上，Notion 以 SaaS 为主，迁移前要确认数据存放、账号体系和访问策略是否符合组织要求。
与研发流程衔接时，Notion 更适合承载需求说明、产品文档、迭代记录和知识沉淀，任务跟踪和代码关联通常交给专业研发工具，再通过链接或嵌入与文档互相引用。迁移实施可以分三步：先选一个空间做试点，验证页面层级、权限和附件的还原效果；再批量迁移正文内容，集中处理宏和复杂格式；最后建立模板和命名规范，让团队在新结构中持续维护。适配建议是，把 Notion 定位为团队知识库和协作工作台，迁移前明确哪些内容留在原系统、哪些进入 Notion，并为宏替换和权限重建安排专门时间。
Microsoft SharePoint
Microsoft SharePoint是微软面向企业内容管理与协作的平台，通常随 Microsoft 365 提供，适合已经使用 Teams、Outlook、Office 套件并希望把知识库、文档库和部门门户放在同一套账号与权限体系下的组织。在 Confluence 替代与迁移的语境中，它承接的核心对象是空间与页面、附件与文档、权限与版本，以及围绕研发流程产生的项目资料和会议记录。
页面与空间结构方面，SharePoint 用站点、文档库和页面组织内容，站点可对应部门、项目或产品线，页面承载说明性内容，文档库承载文件及其元数据。迁移 Confluence 时，可以把空间映射为站点或站点内的文档库，把页面树映射为页面层级或配合导航链接组织。需要提前确认的是，Confluence 页面中的富文本、表格和嵌入内容在转换后可能出现样式差异，页面评论和部分宏也需要逐项核对，迁移前宜先做一批代表性页面的试转换。
权限与历史版本是 SharePoint 的常见使用重点。它沿用 Microsoft 365 的账号体系，可按站点、库、文件夹和单个文件设置访问权限，文档库默认保留版本历史，便于查看修改记录和恢复旧版本。对研发团队而言，这意味着需求文档、设计说明和发布记录的访问范围可以与项目成员身份对应起来。实际配置时需要控制权限继承的层级，避免站点内子库权限过散导致维护成本上升；版本保留策略和保留期限也应按企业合规要求确认。
搜索与附件方面，SharePoint 的搜索覆盖站点内容、文档和部分元数据，附件的检索效果依赖文件名、标题和列字段的规范填写。迁移后如果希望搜索体验接近原有知识库，需要为常用文档补齐标题、所属项目、文档类型等元数据，并规划好站点命名。模板与宏方面，SharePoint 提供页面模板和文档模板，可通过列表、Power Automate 等方式实现流程化提醒和审批；Confluence 中依赖宏实现的目录、状态标记、信息面板等效果，需要在迁移时评估用页面组件、列表视图或自定义方式替代，复杂宏建议列入人工核对清单。
外部协作与部署方式需要结合组织边界判断。SharePoint 支持与外部用户共享站点或文件，具体可用范围受租户设置和管理员策略约束；部署以 Microsoft 365 云服务为主，也存在本地部署版本，选型时应确认当前订阅包含的服务范围和租户配置。与研发流程衔接方面，SharePoint 可与 Teams 频道、Planner、Azure DevOps 等通过链接、嵌入或集成方式配合，把项目文档和任务信息放在相近入口；集成深度取决于组织已有的工具组合和配置，宜在试点中验证实际使用路径。
适配建议上，SharePoint 更适合已经把微软协作生态作为办公底座的团队，尤其是文档密集型、权限分层明确、需要与 Office 文件协同编辑的场景。迁移时建议按“站点规划—权限模型—页面与文档试迁移—搜索与元数据补齐—用户培训”的顺序推进，先选一个空间做完整演练，再分批迁移其余内容。对于高度依赖 Confluence 特有宏和页面评论连续性的空间，应预留人工整理和内容重构的时间。
切换条件与选择建议
进入试迁移前，需要同时满足几个条件：能力保留清单已经确认，必须保留项有明确的验证方式；候选方案在关键维度上没有未解释的硬性缺口，待验证项已列入试迁移任务；迁移范围、页面负责人和时间窗口已经确定；旧系统的访问在并行期内保持可用。以下情况建议暂缓：高频宏或定制插件尚未找到替代实现；权限模型差异较大且涉及敏感内容；历史版本保留是审计硬性要求但目标方案尚未确认；团队尚未就目录规范达成一致。暂缓不等于放弃，可以先做内容梳理和结构设计，再进入试迁移。
试迁移范围建议选择一个结构完整、权限有代表性的空间，覆盖多级页面、至少两类权限设置、常见附件类型和高频宏。范围过小无法暴露结构还原问题，过大则增加整理成本。试迁移时按以下要点验收：
- 页面层级还原：核对空间、页面、子页面的对应关系，检查目录导航是否可用。
- 权限继承：用不同角色的账号登录，验证空间权限与页面级限制的实际效果。
- 历史版本：抽查若干页面的版本记录是否可查、可恢复，确认保留范围。
- 内链与附件：检查页面之间的链接、跨空间链接、附件下载与预览是否正常，断链逐条记录。
- 搜索效果：用已知关键词检索标题、正文和附件内容，核对命中结果与排序。
- 宏与模板：按使用频率逐类确认呈现效果，记录需要改写或简化的页面清单。
试迁移通过后，再安排全量切换。建议按空间分批推进，每批完成后做一轮链接检查和权限抽查；并行期保留旧系统只读访问，方便团队对照查找资料，并行期长度根据内容量和团队适应情况确定。回退预案应提前写明：哪些数据在切换后仍可从旧系统导出、回退的时间窗口、回退时的通知路径和负责人。对依赖特殊宏或定制插件的页面，提前安排替代方案和人工整理时间，能减少切换期间的业务中断。
选择建议可以按以下顺序推进：先按替换动因确定权重，研发流程割裂优先看研发一体化平台，协作范围扩展优先看文档协作型方案，办公生态统一优先看与现有账号体系衔接紧密的方案；再用能力保留清单逐项打分，把“必须保留”项的缺口作为一票否决条件；最后用试迁移结果修正判断。最终决定依据试迁移中可观察的结构还原、权限继承、链接与附件可用性，以及团队实际使用反馈，而不是对照表上的功能数量。
常见问题
Confluence 迁移到 ONES Wiki 时，历史版本和页面内链会自动保留吗？
现有官方资料列出的迁移范围包括空间、页面、附件、图片、常用宏、批注，以及用户、用户组、空间权限与页面权限，未说明历史版本是否随迁移保留，也未说明页面内链和跨空间链接是否自动重写。这两项建议列入迁移前确认清单，并在试迁移阶段用代表性空间实际验证：抽查若干页面的版本记录是否可查、可恢复，逐条检查页面间链接和跨空间链接是否指向正确目标，断链记录后统一处理。
团队大量使用 Confluence 宏和第三方插件，迁移时怎么处理？
ONES 的迁移方案支持迁移常用宏，并通过 ONES Project、Wiki、TestCase、流程自动化和开放能力承接常用插件场景；特殊宏和定制插件需要逐项评估，不能假设全部可以一一对应。执行上建议先统计宏和插件的使用分布，按使用频率分为高频、低频两类：高频项列入功能匹配清单，在试迁移中逐类确认呈现效果；低频项和定制插件评估改为静态内容、结构化表格或调整流程。对无法直接对应的页面，提前安排人工整理时间，避免切换期间出现空白占位。
试迁移应该选多大的空间，验收哪些项目才算通过？
试迁移范围建议选择一个结构完整、权限有代表性的空间，覆盖多级页面、至少两类权限设置、常见附件类型和高频宏。范围过小无法暴露结构还原问题，过大则增加整理成本。验收要点包括：页面层级还原，核对空间、页面、子页面的对应关系；权限继承，用不同角色账号验证空间权限与页面级限制；历史版本可查可恢复；内链与附件下载预览正常；用已知关键词检索标题、正文和附件，核对命中结果；宏与模板按使用频率逐类确认呈现效果。全部通过后再安排全量切换。
什么情况下应该暂缓从 Confluence 切换？
出现以下情况建议暂缓进入试迁移：高频宏或定制插件尚未找到替代实现；权限模型差异较大且涉及敏感内容；历史版本保留是审计硬性要求但目标方案尚未确认；团队尚未就目录规范达成一致。暂缓不等于放弃，可以先做内容梳理和结构设计，把能力保留清单中的必须保留项逐条落实到验证方式，再进入试迁移。对依赖特殊宏或定制插件的页面，提前安排替代方案和人工整理时间，能减少切换期间的业务中断。
全量切换后旧 Confluence 要保留多久，回退预案怎么写？
建议按空间分批推进全量切换，每批完成后做一轮链接检查和权限抽查；并行期保留旧系统只读访问，方便团队对照查找资料，并行期长度根据内容量和团队适应情况确定。回退预案应提前写明：哪些数据在切换后仍可从旧系统导出、回退的时间窗口、回退时的通知路径和负责人。对依赖特殊宏或定制插件的页面，提前安排替代方案和人工整理时间，能减少切换期间的业务中断。
