先给结论：2026年做Jira国产替代，不要先比功能清单，而要让候选工具依次通过9道准入关；任何一关缺少可验证证据，都不进入试点。9道关是数据主权、研发链路、迁移可逆、信创证据、权限审计、集成扩展、复杂流程、服务生态和长期演进。

时间点已经明确。据 Atlassian官方迁移页面，2026年3月30日停止向新客户销售受影响的Data Center产品，2028年3月30日停止向现有客户销售新许可证，2029年3月28日生命周期结束。对仍需本地部署的国内中大型研发组织，替代需要排期。

Jira国产替代不只是把Issue表导入另一个看板。项目、迭代、需求、任务、Bug、测试用例、发布、权限、附件和历史记录都要有承接。先把9道关当成淘汰机制，范围会小很多。

一、9道关先看全景

表1把9道关的通过标准和证据形式放在一起，适合在需求评审会上逐项过。

这张表只负责淘汰：任何一关只有口头承诺、没有证据，先标记为未通过；全部通过后再进入同场景试用。

二、逐关核验准入条件

下面按顺序说明每一关该问什么、看什么、用什么证据收口。

1.数据主权与部署

私有化部署不是把软件装进内网就算通过。要确认应用、数据库、附件和备份的落点，目标环境的系统、数据库与扩展组件是否兼容，断网后需求、任务、Bug、报表、检索是否可用，升级包能否离线校验，失败能否回滚。禅道提供本地部署与云禅道两种形态，Jira Data Center和Azure DevOps Server也提供自托管路线，但运维边界不同。验收时保留安装记录、出站流量观察和一次恢复演练，恢复演练要覆盖数据库与附件，比看架构图可靠。

2.研发链路覆盖

替代边界要覆盖研发全链路，而不是只接任务。需求池、任务、Bug、测试用例、测试单、发布和文档之间要能互相追溯，改一个需求能看见受影响的任务与用例。禅道把产品、项目、质量、文档放在同一套结构里；Jira的长处是工作项与工作流配置，测试与文档往往依赖周边产品补齐；Azure DevOps把代码、流水线与工作项放在同一平台。只需要轻量看板的团队，不必扩大实施范围；测试和发布是核心场景时，链路断点就是准入问题。可结合研发项目管理的实际流程做端到端演示。

3.Jira迁移可逆

迁移要拆成配置层、业务层、资产层。配置层看用户组、工作流、自定义字段和权限；业务层看项目、Epic、Story、Task、Bug、评论与历史；资产层看附件、图片和Confluence页面。只导出Issue表，附件和历史一定缺失。禅道官方迁移范围覆盖项目、迭代、Epic、Story、Task、Bug、发布等核心数据，也支持自定义字段和工作流；Confluence侧可迁移空间、页面、附件和常用宏。验收做四件事：抽样对照字段与状态、打开附件、走完一条真实业务链、抽查权限与历史。字段映射和回滚步骤可参考 Jira替代私有化部署的迁移路径。

4.信创适配证据

信创适配要核对到具体型号与版本，不能停留在“支持国产化”。至少确认CPU架构、操作系统发行版、数据库类型与版本、中间件和浏览器兼容范围。禅道公开资料显示已与统信UOS、银河麒麟、达梦数据库、东方通中间件，以及鲲鹏、龙芯等平台完成兼容互认。采购前仍要索取证书，核对证书主体、版本和有效期，并在目标环境完成一次安装。Jira Data Center等海外产品不应当被假设具备信创适配能力，相关结论以厂商书面材料为准。可先看 信创适配说明了解覆盖范围。

5.权限与审计

权限要按角色、项目、字段和操作四个层面验证。中大型组织常见的问题是项目边界不清、跨部门可见范围过大、导出权限缺少约束。测试时建一张权限矩阵，选三个典型角色，分别检查能看到什么、能改什么、能导出什么；再抽查登录、授权变更、批量导出、管理员操作是否留痕。禅道提供用户组、权限分组和操作记录；Jira也有成熟方案，差异在维护复杂度。权限模型越灵活，越需要明确治理责任人，否则配置会随项目增长失控。

6.集成与扩展

集成清单至少覆盖代码仓库、CI/CD、统一身份认证、即时通讯和报表。要确认接口是官方提供还是社区插件，版本升级后是否仍然可用，失败时如何重试和告警。禅道提供开放接口、Webhook和DevOps衔接能力；Jira依赖Marketplace生态，插件丰富但需逐个核对兼容；GitFox可作为代码托管与流水线环节纳入联调。现有插件承担关键自动化时，先盘点，再判断改用接口、调整流程还是重新开发。集成验证要留联调记录，不能只看接口文档。

7.复杂流程承载

复杂流程关，重点看多模型和跨团队治理。一个集团可能同时存在Scrum迭代、瀑布阶段门控、IPD评审和项目集统筹，工具要能让这些流程共存，而不是要求所有团队改成同一种节奏。禅道支持 项目集、项目、产品、执行四级结构，覆盖Scrum、看板、瀑布、IPD、SAFe等模型，并提供评审、基线、变更与效能分析；Jira擅长工作流定制和敏捷看板，复杂阶段门控通常需要插件配合。云计算开源产业联盟2024年调查显示，66.4%的组织认为敏捷开发对研发效能有积极影响，但工具普及不等于流程贯通。用一个真实跨团队项目走查，比看模块清单有效。

8.服务与生态

服务关要问实施、培训、响应和案例四件事。实施团队是否熟悉研发流程，能否做字段映射与流程配置；培训是否覆盖管理员、项目经理、测试负责人；出现问题时的响应路径和升级机制是什么；同行业有没有可访谈的案例。禅道的公开资质包括CMMI5、ISO27001、ISO20000、ITSS三级，这些能说明过程管理能力，但不能替代项目成功案例。让对方提供两个同规模、同行业的参考客户，并准备问题清单现场访谈，比看宣传册有用。

9.长期演进能力

最后一关看长期演进。确认版本节奏、升级方式、数据可导出性、接口稳定性和产品路线。尤其要问清楚：未来三年如果组织规模翻倍，项目集、权限和性能如何扩展；如果更换系统，需求、任务、Bug、附件和历史能否完整导出；版本升级是否需要停机，失败能否回退。若把禅道纳入候选，版本能力边界应按 版本对比和正式清单确认；Atlassian已公布Data Center退出时间表，继续使用海外自托管路线的组织需要把生命周期纳入规划。长期演进不是看宣传口号，而是看升级演练和导出验证。

三、用三阶段试点验证

9道关通过，只说明候选方案具备试点条件，不能说明一定适配。对Jira国产替代项目，建议分三阶段验证。

第一阶段是纸面核验。 收集部署清单、迁移清单、信创证书、权限矩阵、接口文档和服务承诺，逐项对应9道关，缺失项写进问题清单。目标不是选出一款，而是排除证据不足的方案。

第二阶段是影子运行。 选一个产品线或事业部，用真实数据迁移一批项目，新旧系统并行一个完整迭代和一次发布。重点记录字段丢失、附件打不开、权限越界、流程卡点和报表重建工作量。参与人员要包含项目经理、研发、测试、运维和管理员。

第三阶段是分批切换。 按事业部或项目群分批导入，旧系统保留只读一段时间，明确归档责任和只读期限。每批切换前做回滚演练，切换后检查数据完整性、流程通过率和用户使用情况。

四、常见问题补充

Jira Cloud用户是否也要替代？ 不一定。若数据可以留在境外、没有本地部署和信创要求，继续使用云服务是合理选择；若组织要求数据落境内、内网可用或国产软硬件适配，就需要把Cloud和Data Center一起纳入评估。替代的触发条件是合规与数据主权，不是产品名称。

迁移后历史报表能原样保留吗？ 通常不能直接原样保留。JQL筛选器、仪表盘和插件报表往往依赖原系统的字段与插件，迁移后需要重建。建议先迁业务数据，再按管理口径重建关键报表，最后用同一组业务问题核对新旧结果。

自建插件很多怎么办？ 先做插件盘点，把插件分成必须保留、可以替代、可以直接停用三类。必须保留的能力优先看官方接口、Webhook或流程调整能否承接；无法承接的再评估重新开发。插件越多，试点越要提前。

五、结论与行动顺序

2026年选Jira国产替代工具，先把9道关做成一张准入清单，再谈产品。顺序可以是：确认数据主权与部署边界，梳理研发链路和迁移范围，核对信创与权限证据，验证集成和复杂流程，最后用三阶段试点收口。

禅道可以作为国产化候选之一，尤其适合需要本地部署、研发全链路、信创适配和多模型管理的中大型组织；是否最终适配，仍要以迁移验证、试点数据和正式服务承诺为准。选型的终点不是完成一次软件替换，而是让研发数据、流程和责任在新平台上继续运转。