Confluence 空间迁移前核对清单：空间、页面树、附件与权限

Confluence 空间迁移前，不能只确认“空间已导出”或“页面数量对得上”。真正决定迁移后能否继续工作的，是空间范围有没有业务负责人确认、页面父子关系是否仍可用、附件是否仍归属正确页面，以及原有访问规则能否在目标环境中复现。建议把迁移准备做成逐空间的放行流程：每项检查都指定负责人、留存证据，并明确未通过时是修复、排除还是暂停迁移。

这份清单适用于空间迁移、空间拆分或合并，以及从 Confluence 迁往其他知识库的准备阶段。具体界面、导出能力和权限映射方式会因部署形态、版本、迁移工具和目标平台而异；本文提供的是迁移前的管理核对与验收方法，不替代针对实际环境的技术验证。

一、先定义迁移边界：把“要迁什么”落实到空间

1. 空间清单必须有业务确认人

空间名称和标识只能说明空间在哪里，不能说明内容是否仍有价值。一个空间可能同时包含仍在使用的操作手册、已结束项目资料、历史政策和个人维护页面。如果只按空间整体决定“迁”或“不迁”，常见结果是把过期内容一起搬走，或者把仍被引用的关键页面留在源端。

空间负责人应由实际使用该空间、能够判断内容去留的业务人员担任；系统管理员负责提供数据和配置盘点，不应代替业务负责人判断内容价值。每个空间都应明确选择：整体迁移、部分迁移、归档后排除，或暂缓决定。

2. 建立空间级台账

项目负责人建立一张共享台账，至少记录空间名称与标识、业务用途、负责人、目标位置、迁移范围、特殊依赖、风险等级、确认状态和计划处理方式。不要只记“完成/未完成”：未完成的原因可能是负责人未确认，也可能是目标端能力未知，两者需要不同的后续动作。

空间数量不是工作量的充分指标。两个空间即使页面数相近，如果一个页面层级简单、权限统一，另一个包含大量附件、跨空间链接和页面级限制，后者通常需要更多人工核验。盘点时应把“关系复杂度”与数量分开记录，不要用页面数单独推算验收工作。

3. 把范围决策与内容治理分开

迁移前清理内容有价值，但“清理”不应变成无限期的重写项目。负责人应先决定哪些内容必须在迁移窗口内保留，哪些可以归档或排除；标题规范、内容改写等治理工作可另行排期。若关键页面归属不清，应先确定业务责任人，再决定去留，而不是因为迁移临近就把它默认删除。

建议把无法及时决策的内容标为“待确认”，记录责任人和决策期限。期限到期仍无人确认时，由项目治理机制决定是保留在源端、进入隔离归档区，还是随空间整体迁移。具体选择取决于保留政策和源端下线安排，不能把“没人反对”当成业务批准。

二、核对页面树：检查内容关系，而不只是页面总数

1. 找出层级异常和归属不明页面

页面树承担导航和语义归属两种作用。页面迁移后即使正文完整，如果父页面丢失、页面被放到错误分支，用户也可能无法从熟悉的入口找到它。因此，内容负责人需要检查关键页面的父子关系、异常深层分支、孤立页面，以及名称相同但用途不同的页面。

抽查对象应优先覆盖业务关键页面、层级较复杂的分支和近期仍被使用的内容，而不是只随机挑选首页附近的页面。对发现的孤立页面，先判断它是有意独立、历史遗留还是父页面已删除，再决定归属。页面数量相符不能证明页面树正确。

2. 建立可复核的页面树抽查记录

内容负责人从空间中选取关键分支，记录抽查页面、预期父页面、迁移后实际父页面、页面是否可访问、发现的问题和处理结果。抽样比例不宜脱离风险一刀切：复杂分支和敏感内容应扩大人工核查；结构简单、业务影响低的页面可以采用较少抽样，但仍需验证代表性分支。

抽样不是对全量正确性的证明，而是一种在时间有限时发现系统性问题的办法。若试迁移中同一分支连续出现层级错位，或问题集中在某类页面，就不应继续扩大批次；应先查清是导出规则、目标端结构限制还是人工映射导致，再增加该类内容的检查范围。

3. 单独登记内部链接和跨空间引用

内部链接的风险常被页面树检查掩盖：页面自身和父子关系都存在，链接仍可能指向旧地址、已排除页面或另一个尚未迁移的空间。系统管理员应盘点关键导航入口、跨空间引用和业务流程中使用的链接；业务负责人确认哪些是必须保留的入口。

验收时不必要求所有历史链接都保持原样，但必须对关键链接定义处理结果：目标地址更新、设置可接受的跳转、在页面中改为说明性文字，或确认已废弃。具体能否自动重写，取决于迁移路径和工具能力，须在试迁移中验证，不能仅凭“支持导入页面”推定链接关系会完整保留。

三、核对附件：从文件存在转向“文件，页面，访问”关系

1. 建立附件基线和高风险清单

附件检查至少要覆盖数量或清单、总体体量（若可获取）、文件类型、关键附件及其所属页面。附件很多时，可按业务重要性和风险分层：合同、操作规程、关键设计资料等先列入重点核验；大文件、特殊格式文件和被多个页面引用的文件也应单独标注。

系统管理员负责生成可用的附件盘点信息，技术负责人判断文件格式、大小或迁移机制是否存在特殊限制，内容负责人确认关键附件与页面的业务关系。若源端或迁移工具无法提供可靠的全量附件清单，应在台账中写明数据缺口，并扩大关键页面的人工抽查，不能把“没有报错”当作附件完整性证据。

2. 抽查三个关系：是否存在、归属是否正确、能否使用

每个被抽查的关键附件至少验证三件事：目标页面中是否仍能找到文件；文件是否关联到正确页面；以预期用户身份打开时是否可访问、内容是否可读。只检查文件数量，可能漏掉附件挂错页面；只检查文件存在，也可能漏掉权限不足或文件无法正常打开。

建议从关键页面选取附件，再从附件清单反向抽查其归属页面。前一种方法能发现页面缺少重要文件，后一种方法能发现附件被迁入错误位置或页面不存在。两种抽查方向互补，尤其适用于空间拆分或页面重新归类的场景。

3. 明确版本、重复文件与失效引用的处理规则

迁移前应由业务负责人确认附件保留要求：只需当前版本，还是需要历史版本；重复文件是保留原样、统一归档，还是经核实后去重；已失效的附件引用是修复还是删除。历史版本能否保留并非所有迁移路径都相同，须结合源端、目标端和工具能力核实。

不要在没有负责人确认时批量删除“看起来重复”的文件。文件名相同不代表内容相同，文件名不同也不代表内容不同。对于重复项，可先记录位置、版本和引用页面，由内容负责人决定是否合并；若迁移窗口无法完成判断，保留比不可逆删除更稳妥，但需评估目标端容量与管理成本。

四、核对权限：把规则、身份和实际访问分开验证

1. 先区分空间级权限与页面级限制

权限盘点的核心不是保存一份用户列表，而是弄清楚谁因什么规则获得访问权。管理员应分别记录空间级权限、页面级限制、用户组、外部用户或匿名访问设置，并标记包含敏感内容的页面。只检查空间权限，可能遗漏页面额外限制；只测试管理员账户，则无法证明普通用户的访问边界正确。

权限清单应关注“允许谁查看、谁编辑、哪些人被排除”，而不只是某个权限项是否存在。源端和目标端的权限模型可能不同，用户组名称相同也不一定成员相同，因此迁移前要确认映射规则，并在目标环境用代表性账户进行验证。

2. 建立身份映射表，处理失效与歧义账号

系统管理员负责列出源端用户组和账号，身份管理或技术负责人确认目标端对应关系，业务负责人确认外部协作者和特殊访问需求。离职账号、重名账户、外部用户、目标端不存在的群组都应有明确处理结论：映射到新身份、改由新的业务组管理、取消访问，或暂缓迁移。

如果目标端的用户身份尚未准备好，不能把权限迁移状态标成“已完成”。应把身份映射作为前置依赖，记录待创建账户、群组负责人和完成时间。否则，数据虽然迁入，访问验证却无法代表正式使用状态。

3. 用正向和反向测试验收访问边界

权限验收既要验证“应当能访问的人确实能访问”，也要验证“本不应访问的人确实被阻止”。前者是正向测试，后者是反向测试。只测业务负责人能打开页面，不足以证明敏感页面没有对更广泛群体开放。

为每个高风险空间指定业务验收人，至少选择具有不同权限的代表性账户，测试查看、编辑及受限页面访问。记录测试账户、页面、预期结果、实际结果和截图或其他可追溯证据。若权限模型无法在目标端一一对应，应由业务负责人接受新的规则设计，并记录差异，而不是将“工具不支持”视作默认豁免。

五、把依赖与迁移保障纳入同一张检查表

1. 盘点宏、插件和自定义内容

页面内容可能依赖宏、插件、自定义模板、嵌入内容或外部系统。即使页面正文成功迁移，依赖缺失也可能导致关键信息不显示或操作入口失效。系统管理员负责列出依赖，技术负责人确认目标端是否支持或需要替代方案，业务负责人判断该功能是否影响日常工作。

处理结论可以是原样保留、转换为静态内容、改用目标端能力、人工重建或确认不再需要。对无法确认的依赖，应进入试迁移验证清单，并明确由谁判定“可接受”。不要在正式迁移后才让业务团队发现某个页面关键区域变成空白。

2. 备份、试迁移与回滚要各自验收

备份、试迁移和回滚解决的是不同问题：备份提供恢复材料，试迁移暴露兼容与映射问题，回滚方案说明出现不可接受问题时如何停止或恢复。仅有备份文件不等于备份可恢复；试迁移成功也不意味着正式批次有回退路径。

项目负责人应确认备份位置、保管权限、恢复责任人和恢复验证方式；技术负责人执行试迁移并记录问题；业务负责人验收内容和权限；项目负责人依据结果决定是否放行。若源端无法在迁移后继续提供访问，应把目标端验证和备份恢复能力作为更严格的放行条件。

3. 为每个检查项定义交付物和验收口径

管理清单只有在能够被复核时才有执行价值。建议把每一项写成“对象，负责人，证据，验收结果，未通过动作”，避免只有一个勾选框。证据可以是台账、导出清单、抽查记录、权限测试记录或试迁移问题单，不应要求所有项目都用同一种形式。

六、用风险分层决定抽查深度和迁移顺序

1. 不要让所有空间使用同一套抽样强度

统一流程有利于管理，但统一抽样强度会造成两种浪费：简单空间被过度检查，复杂或敏感空间检查不足。可以用四个维度做定性分层：业务关键性、页面树复杂度、附件依赖程度、权限敏感度。每项按低、中、高评估，分值不是统计事实，而是团队内部安排资源的工具。

高风险空间优先进入试迁移，增加页面树、附件和权限的人工核验；低风险空间可用较轻的抽样方式，但仍需完成范围确认和基本访问测试。若某空间虽然结构简单，却承载敏感资料，应按权限风险提升检查级别，不能用“页面少”抵消高后果风险。

2. 试点空间要覆盖风险，不只是容易成功

试点若只选结构最简单的空间，容易证明迁移工具能够处理简单内容，却不能验证项目最担心的附件、权限和依赖问题。更有效的做法是选择能够覆盖主要风险类型的代表性空间；若一个空间无法覆盖全部情况，可以拆成多个试点，分别验证复杂页面树、附件处理和权限映射。

试点验收的目标不是追求“没有问题”，而是确认问题能否被发现、定位和处理。问题应记录类别、影响范围、根因、责任人、解决方式和是否需要扩大检查。若问题只靠逐页人工修复且无法在计划周期内完成，项目应调整批次规模或迁移策略，而不是把未解决问题留给正式切换。

七、正式迁移前的放行与调整规则

1. 设置明确的暂停条件

迁移项目应在开始前定义不可接受的问题，例如关键页面缺失、敏感页面越权、重要附件无法打开、目标端依赖导致核心内容不可用，或备份恢复方式未经验证。暂停条件的作用是让团队在压力下仍按同一标准决策，避免因为排期临近而把风险口头接受。

并非所有差异都必须暂停。标题样式、非关键历史链接等问题，若业务负责人确认影响可接受，且有后续修复责任人和期限，可以记录为遗留项。但涉及内容完整性、敏感权限或不可逆数据损失的缺陷，不应仅凭“后续再看”放行。

2. 使用“通过、附条件通过、不通过”三种结论

通过表示范围、内容、附件、权限和依赖均满足约定验收标准，责任人和证据齐全。附条件通过适用于已知差异不影响关键业务，且有明确的修复负责人、期限和风险接受人。不通过表示存在关键缺失、越权或无法恢复等问题，必须修复后重新验证。

附条件通过不能成为无限期问题池。每个遗留项都要有影响说明、临时控制措施、负责人和截止日期；到期未完成时，应重新评估是否扩大迁移或下线源端。项目负责人负责汇总放行结论，业务负责人接受业务风险，技术负责人确认技术问题已解决或边界已说明。

3. 迁移前执行清单

• 空间范围已由业务负责人确认，迁移、排除和归档决定均可追溯。
• 页面树中的关键分支、孤立页面和重要跨空间链接已有检查记录。
• 附件基线已留存，关键文件经过存在性、归属和可访问性抽查。
• 空间权限、页面限制、用户组和身份映射已核对，并完成代表性账户测试。
• 宏、插件、自定义内容及其他关键依赖已评估，未知项已安排试迁移验证。
• 备份位置、恢复责任人、试迁移结果和暂停条件均已确认。
• 每项未通过或附条件通过的问题均有负责人、期限和复验方式。

八、最终判断：以关系正确和风险可控决定是否放行

Confluence 空间迁移前最值得关注的，不是单一的页面数或导出状态，而是四类关系能否在目标环境中成立：空间与业务范围、页面与父级、附件与所属页面、用户与访问规则。只要其中任何一类关系无法验证，迁移完成就不能等同于业务可用。

下一步可先选一个空间建立台账，邀请空间负责人确认边界，再由系统管理员补齐页面、附件、权限和依赖信息。完成一次代表性试迁移后，根据问题类型调整抽查范围和批次顺序。只有关键内容可定位、重要附件可使用、权限边界符合预期，并且备份与回退责任明确，项目才具备进入正式迁移的条件。