Jira + Confluence怎么迁移？从数据盘点、试点到切换的完整流程

Jira 和 Confluence 运行几年后，系统里通常已经积累了大量项目、工作流、自定义字段、权限、插件和历史文档。迁移时如果只关注“数据能不能导进去”，很容易遗漏原有的业务关系和协作方式。

一套更稳妥的 Jira + Confluence 迁移流程，通常需要经历数据盘点、清理与映射、测试迁移、业务验收、正式切换和旧系统归档几个阶段，并在整个过程中保证数据完整和业务连续。

要点速览：Jira + Confluence迁移应该怎么做？

完整流程可以概括为：确定迁移范围 → 盘点数据与流程 → 清理历史数据 → 设计对象映射 → 准备迁移环境 → 测试迁移 → 数据校验与 UAT → 制定切换计划 → 数据冻结或增量迁移 → 正式切换 → 旧系统归档

其中最需要提前验证的是三件事：数据有没有迁完整、原来的关系有没有保留、用户能不能在新系统继续完成日常工作。

例如，一篇 Confluence PRD 原来关联 Jira Epic 和多个 Story，Story 又对应研发任务、缺陷和版本。迁移后即使页面和工作项数量完全一致，如果这些上下文关系断开，产品、研发和测试仍然需要重新寻找信息。

如果企业计划同时替换 Jira 和 Confluence，也可以用 ONES Project + ONES Wiki 分别承接研发项目管理和知识库，并通过迁移工具或专业迁移服务完成历史数据迁移。ONES 官方方案支持 Jira 的项目、工作项、状态、字段、流程、附件和历史记录迁移，以及 Confluence 的空间、页面、附件和权限结构迁移。

Atlassian 官方也建议在正式迁移之前先做测试迁移，用于估算迁移时间和停机窗口、验证数据、进行用户验收测试，并提前发现潜在问题。

一、先盘点 Jira 和 Confluence 里到底有什么

迁移项目启动后，第一项工作应该是建立现状清单。

Jira 侧通常要盘点项目、Issue Type、自定义字段、状态、工作流、权限、用户组、评论、附件、自动化规则以及插件；Confluence 则需要关注 Space、页面树、页面权限、附件、宏、模板和历史内容。

可以先做一张迁移资产表：

盘点的目的还包括决定：哪些内容值得进入新系统？

运行多年的 Jira 中经常存在关闭多年的项目、已经废弃的字段和重复工作流；Confluence 中也可能有无人维护的页面、临时会议记录和已经失效的资料。全部迁移虽然看起来最省事，却会把历史负担一起带进新平台。

比较实用的做法，是把存量数据分为：继续使用 / 整理后迁移 / 历史归档 / 不再迁移

例如，当前项目和仍有追溯价值的核心历史项目可以完整迁移；多年未使用的 Jira 项目可以进入历史归档；高频技术规范和产品文档继续进入知识库；明显失效的临时内容则可以在迁移前清理。这样做还有一个好处是正式迁移的数据量更可控，后续校验也更容易。

二、盘点以后，先设计新旧系统的数据和流程映射

不同研发管理平台的数据模型并不会和 Jira、Confluence 完全一致。正式导入之前，需要先确认旧系统里的对象在新系统中由什么承接。

以 Jira 为例，可以先梳理 Issue Type：

Epic → 大型需求 / 史诗
Story → 需求
Task → 任务
Bug → 缺陷

具体叫什么并不重要，关键是保证迁移前后团队对业务对象的理解一致。

字段和工作流也需要重新检查。假设原来的 Jira 流程是：待处理 → 分析中 → 开发中 → Code Review → 待测试 → 测试中 → 待发布 → 已完成。迁移时要判断这些状态是否仍然有管理价值，哪些是业务真正需要的，哪些只是过去几年不断追加出来的。

这里比较容易踩的坑是：为了降低迁移风险，把原 Jira 的所有配置 1:1 复制过去。技术上能复制，不代表管理上应该复制。很多 Jira 实例运行多年以后，同一类工作可能存在多个类似 Issue Type，几十个低频自定义字段，不同团队还维护着几套相似但不统一的工作流。

因此可以把原有配置分成三类：业务必须保留的、仍然具有管理价值的、仅因历史工具和插件形成的。前两类重点承接，第三类则可以结合新平台能力重新设计。

Confluence 也是如此。除了确认页面正文是否能迁，还应提前规划新的 Space、目录、权限和内容责任体系。如果旧环境里同时存在“产品中心”“产品知识库”“产品文档”“产品项目资料”等多个内容高度重叠的 Space，可以借迁移重新整理为：企业公共知识 → 产品知识 → 研发规范 → 项目知识 → 历史归档。

迁移就不仅是数据搬家，也成为一次知识结构治理。

三、正式迁移之前，用真实项目做一次测试迁移

对于 Jira + Confluence 这种核心研发系统，不建议第一次迁移就直接覆盖全部用户和数据。更稳妥的方法，是选择一个有代表性的 Jira 项目，再搭配一个相关的 Confluence Space 做测试迁移。试点项目最好主动覆盖一些真实的复杂情况，例如：

• 多种 Issue Type；

• 自定义字段；

• 父子工作项和关联关系；

• 评论与大量附件；

• 多种用户权限；

• 自定义工作流；

• Confluence 多层页面；

• 图片、附件和宏；

• Jira 与 Confluence 之间的引用关系。

如果正式环境有几十万条工作项，可以先抽取 100～500 条典型 Jira 工作项 + 20～50 篇不同结构的 Confluence 页面跑一次完整流程。测试结束以后，不建议只核对“迁移成功多少条”，还应建立迁移前后的对比清单：

Atlassian 官方也明确建议进行测试迁移，因为测试可以帮助团队确定正式迁移时间、评估停机窗口、验证数据并执行 UAT。

数据验证之后，还应该让产品、研发、测试、项目经理和知识管理员分别进入环境完成真实操作：创建需求、修改任务状态、查看历史评论、打开附件、编辑技术文档、检查页面权限、从文档找到对应研发事项。只有这些操作都能正常完成，才能说明新环境真正具备上线条件。

四、试迁通过后，再安排正式切换窗口

测试迁移验证通过以后，再进入正式切换准备。

这一阶段要把“什么时候停止旧系统写入、什么时候同步最终数据、什么时候开放新系统”写成具体计划。

一个常见节奏可以是：

T-7 天：确认最终迁移范围。锁定需要迁移的项目、Space、成员和特殊配置，确认各业务负责人。

T-3 天：完成环境与账号检查。确认新平台容量、账号目录、用户组、权限、SSO 和必要的第三方集成已经配置完成。

T-1 天：通知用户并减少旧系统变更。停止新增字段、修改工作流等高风险配置，准备进入最终数据同步窗口。

T 日：执行正式迁移。完成全量迁移或者最终增量同步，并立即检查核心项目、页面和账号数据。

T+1 天：业务验收。产品、研发、测试和项目负责人进入新环境执行真实业务操作。

T+3～7 天：稳定观察。集中处理权限遗漏、数据异常、链接失效和用户反馈。

对于业务连续性要求较高的企业，也可以采用历史数据提前迁移 + 正式切换前增量同步的方式来缩短数据冻结时间。

正式迁移方案里还应该提前定义异常处理条件。例如关键项目数据缺失、大量用户权限异常、代码或流水线集成无法运行时，是延迟正式开放，还是恢复旧系统写入，都应该提前确定。

五、新系统上线以后，还要把旧系统真正退下来

正式迁移完成，并不意味着迁移项目已经结束。很多迁移最后形成“双系统长期并行”，原因通常是新平台已经上线，但团队仍然习惯回旧 Jira 查项目、到旧 Confluence 找资料，甚至继续在那里更新数据。

因此需要提前设计旧系统退出路径：

正常使用 → 停止新增 → 冻结写入 → 只读归档 → 最终下线

对于需要审计和历史追溯的企业，旧系统可以保留一段时间只读访问。关键在于明确哪一个平台已经成为新的唯一事实来源，避免相同任务和文档长期在两边更新。

迁移后也要重新确认日常管理规则，例如：

• PRD 应该关联哪个需求？

• 技术方案怎样对应开发任务？

• 测试报告应该沉淀在哪里？

• 项目结束后哪些资料必须归档？

• 文档过期后由谁负责更新？

• 新项目怎样复用旧项目经验？

这些规则决定了半年以后，新平台会不会再次出现信息分散。

因此，迁移真正完成的标志并不是“旧数据已经导入”，而是团队已经形成稳定的新工作方式。

六、用 ONES 承接 Jira + Confluence 迁移流程怎么落地？

ONES 可以通过 ONES Project + ONES Wiki 承接 Jira + Confluence 的核心场景：ONES Project 负责项目、需求、任务、缺陷和研发流程，ONES Wiki 承接 Space、页面、附件和研发知识，同时提供 Jira 与 Confluence 的历史数据迁移能力。

如果已经完成前面的数据盘点、映射设计和迁移范围确认，接下来可以把原系统内容映射到 ONES 的具体能力：

ONES 官方 Jira & Confluence 替换方案明确以 ONES Project、ONES Wiki、ONES TestCase、ONES Account、API / Webhook 和迁移服务组成一体化承接架构。其中 Jira 侧覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 侧则支持将空间、页面、附件和权限结构迁移到 ONES Wiki。

在迁移方式上，不同数据规模也可以采用不同路径。ONES 的迁移资料提供自助迁移和专业迁移服务两类方式：

• 配置相对标准、规模较小的团队可以先评估自助迁移；

• 对于数据量大、工作流复杂，或涉及插件、二次开发、私有化部署的企业，则更适合先进行迁移评估和测试，再安排正式迁移。

公开的 ONES 方案材料也将 Jira 和 Confluence 迁移划分为需求分析与迁移评估、环境检查与迁移准备、测试迁移与正式迁移三个主要阶段。

真实迁移场景：复杂企业不仅要迁数据，还要重建研发体系

在 ONES 公开的某头部国有券商案例中，企业将原有 Jira 与 Confluence 统一迁移至 ONES，涉及 298 个 Jira 项目、30.7 万条任务、8.9 万附件、3300 位用户，以及 105 个 Confluence 空间和 200G 附件。迁移之外，项目还重新梳理了项目分类、Epic / Story / Task / Bug 等工作项体系、流程权限，并继续集成私有 GitLab、测试和 DevOps 平台。

这个案例说明，大规模 Jira + Confluence 替换通常不是把两个数据库换个地方保存，而是同时处理历史数据迁移 + 工作流治理 + 权限重构 + 知识迁移 + 工具链集成。这些工作如果在试迁阶段没有提前验证，很容易在正式切换以后集中暴露。迁移完成后，比较理想的研发链路应该继续保持需求文档 → 需求 / 任务 → 开发 → 测试与缺陷 → 发布 → 项目知识。

也就是说，ONES Project 和 ONES Wiki 承接的不只是 Jira 数据和 Confluence 页面，还要让研发管理与知识沉淀之间继续保持上下文。

七、Jira + Confluence迁移检查清单

进入正式迁移之前，可以快速检查下面这些问题：

• 已确认需要迁移的 Jira 项目和 Confluence Space；

• 已区分继续迁移、整理后迁移和历史归档数据；

• 已盘点 Issue Type、自定义字段和工作流；

• 已完成用户、用户组和权限映射；

• 已梳理插件、API 和第三方系统依赖；

• 已设计旧系统和新系统之间的数据模型映射；

• 已重新确认 Confluence 知识结构；

• 已完成代表性项目和 Space 的测试迁移；

• 已完成数据数量与内容抽样检查；

• 已完成产品、研发、测试等关键用户 UAT；

• 已评估正式迁移时长和冻结窗口；

• 已准备增量迁移或最终同步方案；

• 已明确迁移异常时的处理和回退策略；

• 已制定旧系统只读、归档和下线计划。

如果其中还有多项没有明确答案，通常还不适合直接进入正式迁移。

总结

Jira + Confluence 迁移可以归纳成一条清晰路径：

盘点数据与流程 → 清理历史配置 → 设计新旧系统映射 → 用真实项目测试迁移 → 完成数据校验和 UAT → 制定正式切换窗口 → 执行最终迁移 → 归档旧系统。

迁移过程中真正需要持续关注的是数据完整、业务连续和关系保留。项目、需求、任务和页面都能迁过去只是基础，迁移后团队还能顺利找到上下文、继续研发协作，整个替换项目才算真正完成。

如果企业希望把 Jira 与 Confluence 一起迁移到统一研发平台，ONES 提供了以 ONES Project + ONES Wiki 为核心的 Jira & Confluence 替换和迁移方案，并可结合测试管理、企业账号体系、开放平台及迁移服务继续承接原有研发工作方式。

FAQ

1. Jira 和 Confluence需要一起迁移吗？

不一定必须同一天完成，但建议统一规划。如果 Jira 工作项与 Confluence 页面存在大量关联，分别迁移时需要提前设计链接和关系如何恢复。

2. Jira迁移之前需要清理历史数据吗？

建议清理。已经废弃的项目、字段、工作流和账号可以根据业务价值决定继续迁移、历史归档或不再导入，减少新平台中的历史负担。

3. 为什么正式迁移前要先做测试迁移？

测试迁移可以提前验证数据完整性、权限、页面结构、工作流和第三方集成，同时估算正式迁移时长和停机窗口，并让真实用户完成 UAT。Atlassian 官方也明确建议在正式迁移前进行测试。

4. Confluence迁移最容易遗漏哪些内容？

除了页面正文，还应重点检查附件、图片、页面层级、用户和用户组、Space 权限、页面权限、宏以及与 Jira 工作项之间的链接关系。

5. ONES可以迁移Jira和Confluence吗？

可以。ONES 官方提供 Jira & Confluence 替换和迁移方案，Jira 数据可以迁移至 ONES Project，包括项目配置、问题类型、工作流、字段、权限，以及工作项属性、附件和评论等；Confluence 数据可以迁移至 ONES Wiki，包括用户、用户组、空间和页面权限、页面正文、附件、图片及常用宏等。对于不同数据规模，还可以选择自助迁移或专业迁移服务。

6. Jira + Confluence迁移完成后还要保留旧系统吗？

通常可以保留一段时间的只读环境，用于历史查询和数据校验。完成业务验收后，再根据审计、合规和归档要求逐步下线旧系统。