企业知识库迁移对照清单：权限、附件、宏与历史版本如何验收
企业知识库迁移对照清单，是在页面数量对上之后，再分别验收权限、附件、宏、历史版本、链接与审核工作流是否仍然可用的一组核对项。它要回答的不是「导入向导有没有显示成功」，而是新系统里，该能打开的人能否打开、该能点开的附件是否还在、宏和权限会不会在迁完后失效。本文以 Atlassian 对 Confluence Data Center 生命周期与 Confluence Cloud Migration Assistant 的官方说明为主，并对照 Notion 工作区导出范围，给出一份可写进迁出立项书的验收清单。
浏览 6
巴克励步
导语：先问导入完成之后还能不能用
企业知识库迁移对照清单，是在页面数量对上之后，再分别验收权限、附件、宏、历史版本、链接与审核工作流是否仍然可用的一组核对项。它用来判断：该看见的人在新系统里是否仍能打开对应页面，不该看见的人是否仍然打不开；图片和附件是否还能下载；宏、嵌入和跨页链接是否还在工作；以及日常编辑和审核是不是已经切到新库，而不是还停在「导入向导显示成功」。
这和替代 Confluence / 语雀 / 飞书知识库的选型对照不是同一篇文章。那一篇解决的是协作 Wiki 与可发布 Wiki 的产品分界，以及该不该离开原系统；本文假定方向已经大致选定，要回答的是：搬迁这件事本身怎样才算完成。它也和内容治理、权限模型不同：治理回答这一页还值不值得当现行版本，权限回答目标系统里空间、页级和外部共享该怎么设计；本文回答的是，旧库里已经生效的限制、附件和历史，迁过去之后有没有丢、有没有放宽、有没有失效。产品定位见支柱文 Baklib Wiki 是什么。
立项里最常见的误会有三个：一是把「页数对得上」当成验收通过；二是以为官方迁移助手能自动带走权限模型、应用数据和审计轨迹；三是把 Confluence 迁到 Confluence Cloud 的工具，直接当成迁到任意企业 Wiki 的方案。2026 年，Atlassian 已经把 Data Center 的停售与停服时间表写成正式页面，这些误会也更容易在迁出窗口里被翻出来。
为什么现在要谈：官方时间表已经开始收口
第一，Confluence Data Center 的生命周期不再只是「以后会有变化」，而是已经进入按日期收口的阶段。Atlassian 写明：受影响的 Data Center 产品将在 2029 年 3 月 28 日 23:59 PST 结束生命周期，届时订阅和相关 Marketplace 应用到期，产品将变为只读。现有客户可以继续续订到这一天，但续订不能延伸到该日期之后。从 2026 年 3 月 30 日 23:59 PST 起，新客户已不能再购买新的 Data Center 订阅或新的 Marketplace Data Center 应用；现有客户购买新的 Data Center 订阅、Marketplace 应用和扩容的截止日期是 2028 年 3 月 30 日 23:59 PST。到期后数据仍可只读访问，但不再提供产品更新和安全修复，官方明确不建议把只读实例继续暴露在互联网上，并建议提前备份，以保证长期仍能拿到历史数据。见 Data Center End of Life、Atlassian Ascend。
第二，即便目的地仍是 Atlassian Cloud，官方也没有把「迁移助手跑完」写成「全部数据与规则都到了」。Confluence Cloud Migration Assistant 会迁移什么把页面限制、页面历史、标签、评论、共享草稿、任务和附件列进可迁移范围，同时也写明：全局设置与权限须在 Cloud 手动配置；个人草稿不迁，共享草稿会迁；源实例审计日志不迁；以链接地址插入的附件不迁；邮件归档插件中的附件须手工再上传；用户自建宏、部分仅旧编辑器可用的宏，以及已从 Cloud 移除的宏，都不能按原样继续用。空间 XML 导入还不会带走用户、用户组或组成员关系，限制页可能要等账号和组在目标站点重建后才能看见。见 Confluence 迁移前检查清单。
第三，即使团队不在 Data Center 上，离开 Confluence Cloud、Notion 或其他协作 Wiki 时，也会碰到同一类验收问题。Notion 官方说明：可以把页面或数据库导出为 PDF、HTML，或 Markdown 与 CSV；也可以导出整个工作区，并附上已上传的文件，下载链接会发到邮箱且 7 天后失效，大型工作区最长可能需要 30 小时。导出范围不包括当前导出者没有权限的内容，例如其他用户的私人页面；企业版还可以关闭成员导出。官方还写明：不能靠把导出包再上传回去，立刻重建一个工作区。见 Export your content。这些事实要说明的不是「某家工具不能用」，而是：官方导出或官方迁移助手，都会留下必须手工验收的缺口；跨产品搬迁时，缺口只会更多，不会更少。
把这三条放在一起，迁出立项的问题就从「能不能导入」变成：你是否先分拣了该迁、该归档和该退役的内容，是否按权限、附件、宏、历史和链接分层验收，并且是否能在旧库按计划只读或下线之前，证明日常工作已经可以信任新库。
四个容易混在一起的词
在短名单上把下面四个词拆开写。混用它们，最后往往得到「导入报告是绿色的」，却在第一周就发现限制页被放开、图片 404、宏裂开，或者关键制度仍只能回到旧库才能改。
| 概念 | 它真正回答的问题 | 典型落地方式 |
|---|---|---|
| 导入成功 | 选定对象有没有被写入目标系统 | 对照源库与目标库的空间/页面清单，核对导入日志里的失败项 |
| 内容保真 | 正文、表格、图片、宏和嵌入迁完后是否仍可读、可用 | 用最复杂的样例页做试点：宽表、多附件、宏、绘图和嵌套标题 |
| 权限保真 | 该看见的人是否仍能看见，不该看见的人是否仍打不开 | 用高权限、低权限、外部访客和匿名身份各走一遍关键路径 |
| 迁移完成 | 日常工作是否已切到新库，旧库能否按计划只读或下线 | 编辑、审核、搜索和发布都在新库完成，并有回切条件与冻结窗口 |
一个可操作的判断句是：先画清「导入成功 / 内容保真 / 权限保真 / 迁移完成」四行，再看迁移工具的成功提示有多漂亮。 页数对得上，只覆盖了第一行。
还要把「页面历史」和「审计日志」分开。前者记录这一页改过什么；后者记录谁在何时访问、导出或改过权限。Confluence Cloud Migration Assistant 可以带走页面历史，但不会带走源实例的审计日志。若合规要的是操作轨迹，迁出前应单独归档，不要默认它会随正文到达新系统。这与权限模型里讨论的可追溯访问是同一条线，只是验收发生在搬迁窗口。
先分拣，再搬：迁、归档、退役
把已经过期、重复或只为已下线系统编写的页面原样搬进新库，等于把旧库的治理缺口一起搬走。Atlassian 的清理指南建议：先用分析数据找出低访问空间，再和空间管理员、活跃贡献者确认，是归档、备份后删除，还是继续作为现行空间使用；归档空间默认不出现在搜索结果里，但内容仍可按需打开，这往往比「先全部导入再清理」更利于迁入后的检索质量。若确定不再需要在线访问，应先导出 XML，在测试实例里验证备份可导入，再删除原空间；需要给业务人员留一份可读副本时，可以额外导出 PDF。见 Clean up your Confluence instance。
迁移前检查清单还把公开访问设置列为必查项：迁之前要找出已对互联网公开的空间，并去掉匿名访问，除非这些内容本来就应该公开。见 Confluence pre-migration checklist。这一步与数据驻留和权限模型直接相关：匿名可见一旦被原样带进新环境，或在权限重映射时被放宽，损失的不是格式，而是边界。
把分拣结果写成三类，而不是「全部导入后再说」：
- 迁：当前仍被日常工作使用的现行知识，进入新库的活跃目录。
- 归档：暂时不用，但有留存或合规要求的内容，单独存放，不和现行知识混在默认搜索里。
- 退役：草稿、重复页、已废止制度，以及只为已下线系统编写的说明。不要把它们迁成「看起来还在用」的正式页面。
目录深度也要一并处理。源系统如果允许很深的嵌套，忠实导出可能得到一套读者进不去、对外站点也不适合发布的层级。知识库信息架构讨论的是日常如何组织；迁移窗口则是一次把过深的树压平、把重复入口合并的机会。不要把「层级完全一致」当成保真的唯一标准。
官方已经写明：哪些会迁，哪些不会
下面这张表不是全市场通用的功能对比，而是把官方已经公布的范围写成验收预期。目的地如果不是 Confluence Cloud，缺口不会自动变小，只是换了一种表现方式。
| 对象 | Confluence Cloud Migration Assistant 的官方范围 | 迁到其他企业 Wiki 时还要额外核对 |
|---|---|---|
| 页面正文与页面限制 | 页面、页面限制、标签、评论、共享草稿、任务可迁；个人草稿不迁 | 限制模型能否映射到目标系统的空间/页级权限；共享草稿会不会变成正式页 |
| 附件与图片 | 附件通常可迁；以链接地址插入的附件不迁；邮件归档插件中的附件须手工再上传 | 图片是否仍指向源站图床；离线包里的相对路径在导入后是否失效 |
| 宏与应用数据 | 部分内置宏可迁但行为可能变化；Marketplace 宏取决于厂商是否提供迁移路径；用户自建宏、部分旧编辑器宏和已移除宏不能按原样迁移 | 目标系统有没有对应能力；做不到的宏要在迁前改写成普通正文、表格或嵌入 |
| 用户、组与全局权限 | 可迁移用户和组；全局设置与权限须在目标 Cloud 手动配置；未配置 SSO 时用户须重设密码 | 先建组再导入内容；同名组是否真的对应同一批人；外部访客和匿名访问是否被意外打开 |
| 历史、分析和审计 | 页面历史可迁；分析数据不迁；源实例审计日志不迁 | 合规所需的操作日志要单独导出；不要用页面历史代替审计轨迹 |
| 空间导出 / 站点导入 | 空间 XML 不导入用户、组或组成员关系；Cloud 空间导入在目标站点没有同名组时会丢掉基于组的权限；非站点管理员导出时，通常只包含自己可见的内容 | 用管理员身份做整库导出；先迁身份与组，再迁内容；抽查限制页，而不是只抽查公开页 |
Atlassian 还建议：先迁用户、组和附件，再迁其余内容，以缩短停机窗口；正式迁移前应做一次测试迁移，并在目标站点已有数据时先备份。见 What migrates with the Confluence Cloud Migration Assistant、Confluence pre-migration checklist、Import a Confluence Cloud space。
Notion 的官方导出则从另一侧说明「能导出」和「能原样重建」不是一回事：Markdown 与 CSV 适合带走正文和数据库行，但 Callout 会以 HTML 导出，因为没有对应的 Markdown 写法；HTML 导出可以包含评论；整个工作区的导出包不能用来一键重建工作区，私人页面还可能根本不在包里。见 Export your content。离开语雀、飞书等协作知识库时，也应先核对这些产品当前官方支持的整库导出格式、权限是否随包迁移、图片是内嵌还是仍指向原图床，不要把单篇导出或第三方脚本的结果，直接当成企业级迁出方案。
验收要分六层，不要只对页数
不要把一次迁移的成败收成「成功 / 失败」。按层诊断，才能决定下一步是补附件、重做权限、改写宏，还是推迟切流。
| 层次 | 主要核对什么 | 通过时说明什么 | 未通过时优先查什么 |
|---|---|---|---|
| 身份与权限 | 空间权限、页面限制、组映射、外部共享、匿名访问、访客账号 | 高权限用户能打开应看的页；低权限、访客和匿名看不到不该看的内容 | 是否先迁了用户和组；同名组是否空心；公开访问是否被原样带入 |
| 附件与媒体 | 页内图片、附件下载、以链接插入的文件、大文件和回收站中的附件 | 样例页上的图片能显示，附件能下载且版本可对上 | 是否只迁了页面没迁附件；图床外链是否会在切断源站后失效 |
| 宏、嵌入与应用 | 内置宏、Marketplace 宏、Jira / 项目宏、自建宏、绘图和嵌入 | 关键页的宏仍能渲染，或已改写成目标系统可维护的等价内容 | 厂商是否提供迁移路径；旧编辑器宏在新编辑器中是否只显示为损坏块 |
| 历史、评论与审核 | 页面历史、评论、共享草稿、审核步骤和待办 | 需要回溯的制度页能看到必要版本；进行中的审核能在新库继续，而不是只留在旧库 | 个人草稿是否被误当成正式内容；审核流是否只迁了正文、没迁步骤 |
| 链接与信息架构 | 页内链接、跨空间快捷方式、锚点、过深的目录树 | 读者能从新的导航走到正确的页；对外将发布的路径深度可维护 | 跨空间快捷方式是否丢失；忠实导出是否保留了过深、不可用的层级 |
| 搜索、发布与问答 | 默认搜索是否混进归档和退役内容；对外站点是否只发布已审定版本 | 员工搜到的是现行知识；对客手册和内部讨论不共用同一份未过滤索引 | 是否把草稿、评论和已归档页一并送进了对外站点或 AI 语料 |
权限层必须用真实账号走关键路径，而不是只看权限配置界面。Cloud 空间导入的官方说明已经给出一个典型陷阱：基于组的权限，只有在目标站点已经存在同名组时才会保留；先导入内容、后补组，可能让限制页暂时甚至长期变成「导入进去了，但谁都打不开」，或反过来在重映射时被放宽。见 Import a Confluence Cloud space。
附件层要专门抽查「看起来像附件、其实只是一串源站 URL」的插入方式。Atlassian 写明：从源实例复制附件地址再贴进页面时，这类附件不会被迁移助手带走。跨产品搬迁时还有第二类问题：导出的 Markdown 仍指向源站图床，源站权限一收或链接一过期，新库里的「正文还在、图全没了」就会集中出现。
宏这一层往往决定试点能不能通过。官方建议在清理阶段查看宏使用情况，识别很少用到或难以迁到 Cloud 的宏；Plan 宏迁到 Cloud 后会表现为损坏，需要用 Jira Macro Repair 转换成 Smart Links，而且操作者要同时具备 Confluence 与 Jira Plans 的管理权限。见 Clean up your Confluence instance、What migrates…。迁到非 Confluence 的目的地时，更应在迁出前把无法对应的宏改写成普通表格、步骤或嵌入，而不是指望导入后再逐页抢救。
试点怎样才算过：先让人信任新库，再切断旧库
Atlassian 把测试迁移写成迁移前检查清单中的推荐项，并建议在目标站点已有数据时先做备份。见 Confluence pre-migration checklist。对企业知识库来说，试点不应只选「最好看的几篇介绍页」，而应包含：
- 最复杂的页：宽表、多附件、宏、绘图、跨页引用和多层标题同时出现的样例。
- 最常被打开的页：分析数据里的高访问内容，用来验证搜索、导航和日常编辑。
- 限制最严的页：制度、薪酬、客户合同、未发布路线图，用来验证权限保真。
- 即将对外发布的页：帮助中心或产品手册，用来验证发布面不会带上内部评论和草稿。
试点通过的标准，不是「测试空间里能看见页面」，而是：页面所有者确认内容可维护；权限抽查通过；附件和宏的失败项已有补救办法；编辑和审核能在新库完成一轮真实任务。然后再设冻结窗口，处理冻结之后仍发生的变更，并写明回切条件。迁移完成的标志，是日常工作不再依赖旧库，而不是旧库已经只读。
如果新库还要承担对外手册或帮助中心，试点里就应包含一次真正的发布，而不是只在编辑器里预览。协作 Wiki 里「写完即可见」和可发布文档站「审核后才形成对外 URL」不是同一件事；迁入后再靠手工复制出一份对外文稿，很快会回到两份逐渐分叉的正文。Docs AI 可见性清单讨论的是发布后的抓取与
llms.txt；本文只要求：对外路径在切流前就已经用已发布、已授权的版本跑通。迁完之后：同一份已发布资产，按站点交付
对同时维护内部制度与对外手册的团队，更稳妥的做法是：只有已经发布、按站点权限交付的知识，才进入对应阅读面的检索和问答；草稿、评论和已归档版本留在协作面，不和正式答案混用同一套索引。Baklib 把这类能力写成知识库绑定应用站点之后，才形成对外 URL，并在站点上交付权限；一篇知识库还可以绑定多个 Wiki 应用，例如中文站、英文站或内网预览，变更需按应用同步，未同步时会提示数据已过期。整库或子树也可导出为 Markdown、JSON / CSV、Word 或 PDF，用于备份和下游对接。见 知识库发布、知识库分发与导出、Baklib Wiki。
一源多站的意义，是同一份已发布的知识可以出现在内部门户和对外手册上，却使用不同的访问规则和不同的问答范围，而不是维护两份互不引用的文稿。这与可发布企业 Wiki 的选型对照讨论的是同一条产品分界，本文只把它用在迁入后的验收上：如果迁完之后仍要靠复制粘贴维持对外站点，迁移就还停在「内容进了编辑器」，而没有进到可交付的知识资产。
可执行核对清单：把迁移验收写进立项书
下面十问可以直接贴进迁出立项或概念验证脚本。对每一问，要求看到试点记录或导出对照表，而不是只看一次导入成功的截图。
- 有没有先做「迁 / 归档 / 退役」分拣，而不是整库原样搬迁？ 低访问、重复和已废止内容应排除在活跃目录之外；公开或匿名访问要在迁前单独确认。
- 验收是不是分成权限、附件、宏、历史、链接和发布面，而不是只对页数？ 要求能指出一次失败属于哪一层。
- 用户和组是否先于内容到达目标系统？ 同名组是否对应同一批人；未配置 SSO 时，账号激活和密码重置有没有方案。
- 是否用高权限、低权限、外部访客和匿名身份抽查过限制页？ 既要避免越权可见，也要避免「迁进去了但谁都打不开」。
- 最复杂样例页上的图片和附件能否显示、下载，且版本可对上？ 专门检查以链接地址插入的文件，以及仍指向源站图床的图片。
- 关键宏和 Marketplace 应用是迁得动、改得成，还是会在新编辑器里损坏？ 迁前应有宏使用清单和改写计划，而不是迁后再逐页发现。
- 页面历史、评论、共享草稿和审计日志是分别处理的吗？ 需要回溯的制度页要能看到必要版本；审计日志若是合规项，须单独归档。
- 内部链接、跨空间入口和目录深度在新库里是否仍可走通？ 过深的树应在迁入时压平，不要把无法导航的层级当作保真成功。
- 是否先做了测试迁移，并写明冻结窗口与回切条件？ 冻结之后的变更要有对账办法；日常编辑、审核和搜索都在新库跑通之前，不要切断旧库。
- 内部知识与对外手册是否共用同一份已发布资产、分别进入不同站点的阅读范围？ 若做不到，迁得再完整也会在复制粘贴中重新分叉：一边已经更正，另一边的手册或助手还在引用旧段落。Baklib 将知识资产发布、权限交付与一源多站写成同一条产品逻辑：一份内容可以输出到不同应用站点，并分别设置公开、登录可见或指定权限可见。见 知识库发布、Baklib Wiki。
怎么选：先写验收标准，再挑导入工具
先不要从「哪家声称支持一键迁出 Confluence」开始。先写出你必须保住的对象：限制页、附件、宏、历史、审核中的文档，以及迁入后要不要同时支撑内部门户和对外手册。再用这张清单去看迁移工具和目标产品：官方助手覆盖哪些层，哪些层必须改写或手工补齐，哪些层在目标系统里根本没有对应能力。
如果目的地仍是 Confluence Cloud，应直接使用 Atlassian 的检查清单和 CCMA 范围说明，不要另造一套与官方冲突的预期。如果目的地是可发布的企业 Wiki，还要同时验收发布、站点权限和检索范围；选型对照决定产品形态，本文决定搬迁是否过关。数据必须留在特定区域或专有环境时，应把驻留承诺写进迁入条件，而不是迁完再补问，细节见数据驻留对照清单。
对既要内部协作、又要对客交付的团队，目标不应停在「新编辑器里能看到旧文章」。更完整的结果是：现行知识成为一份已发布的知识资产，按站点交付权限，并作为对应站点的检索与问答上下文。Baklib Wiki 适合在这一步介入：它不是把 Confluence 的宏生态原样搬过来，而是把已经分拣、已经审定的内容，变成可发布、可设权、可按站点同步的知识。见 Baklib Wiki、知识库发布。
参考来源
想要了解更多?
数字内容新基建白皮书
常见问题
导入显示成功，是不是就等于迁移完成？
不是。导入成功只说明工具把选定对象写进了目标系统。Atlassian 自己也把全局设置与权限、个人草稿、审计日志，以及部分附件和宏，写进了「不会随 Confluence Cloud Migration Assistant 迁移」的清单。Cloud 空间导入还会在目标站点没有同名组时丢掉基于组的权限。验收应以真实账号能否打开、附件能否下载、宏是否仍能渲染、限制页是否仍被限制为准，而不是以导入向导的成功提示为准。
Confluence Cloud Migration Assistant 能不能用来迁到任意企业 Wiki？
不能。它解决的是 Confluence Data Center / Server 到 Confluence Cloud，或向已有 Cloud 站点追加数据，并明确不会覆盖目标站点已有内容。把它当成「迁到任何 Wiki」的通用工具，会漏掉格式转换、权限模型重映射和发布面重建。若目的地是可发布的企业 Wiki 或文档站，仍要按本文的六层清单做试点和终验，这与可发布企业 Wiki 的选型对照是前后两步。
历史版本迁过去了，审计日志是不是也在？
不一定。Confluence Cloud Migration Assistant 可以迁移页面历史，但官方写明：源实例上的审计日志不会迁到 Cloud。历史版本回答的是「这一页曾经怎么改过」；审计日志回答的是「谁在何时访问、导出或改过权限」。若合规要求保留操作轨迹，应在迁出前单独导出并归档审计日志，不要默认它们会随页面一起到达新系统。
为什么迁之前还要先做内容分拣？
因为把已经无人使用、重复或只为已下线系统编写的页面原样搬过去，会把旧库的治理缺口一起搬走。Atlassian 的清理指南建议先用分析数据找出低访问空间，再决定归档、备份后删除还是继续使用；迁移前检查清单还要求核对匿名公开访问。分拣的结果应写成「迁 / 归档 / 退役」三类，而不是「全部导入后再说」。
迁到新系统后，内部 Wiki 和对外手册要不要再复制一份？
最好不要把同一份现行知识长期维持成互不相关的两份文稿。更稳妥的做法是：协作面完成审核后，把已发布版本按站点权限分别交付到内部门户、帮助中心或产品文档站，并让对应站点的检索和问答只使用该发布面的内容。Baklib 把这一步写成知识库绑定应用站点之后的发布与同步，而不是在编辑器里再复制一遍。见 知识库发布。
