从jira云到自建：迁移实战复盘

一、核心结论：迁移不是技术问题，是一场组织手术

如果你正在寻找一篇“从Jira云备份出来、装一台服务器、恢复数据就完事”的教程，现在可以关掉了。这篇文章不适合你。

真正做过Jira云到自建迁移的人都知道：数据搬运只占整个项目工作量的30%。剩下70%是在解决三个致命问题：插件生态的断崖式兼容灾难、用户权限体系的隐性腐化、以及迁移过程中你必须同时应付的“业务不能停”悖论。

2024年Q4，我所在的团队完成了一次从Jira Cloud（企业版）到私有化部署的完整迁移。项目从立项到切换完成，按日历时间走了四个月。但按实际执行工期算，纯技术操作只有两周。另外三个半月，全部花在决策论证、权限体系重构、插件替代测试以及组织内部的扯皮上。

这篇文章不会教某一条命令该怎么敲，我想谈的是这些藏在命令背后的真实决策逻辑。因为在你把数据库dump出来之前，有十几个前置问题没想清楚，后面几步踩坑的概率几乎是100%。

二、背景：我们为什么非走不可

1. 表面理由和真实理由

对外我们说的是安全合规。这不是假话。我们服务的一家金融租赁客户明确提出：所有项目级数据必须存储在中国大陆境内服务器，且需支持监管审计的“猝死式抽查”，提前两小时通知，要求导出指定项目从创建至今的全部操作日志。

Jira Cloud的审计日志API在理论上能查，实际上有两点让人很难受：一是请求频率限制严格，大量数据导出时经常触发429；二是日志返回的字段解释权在Atlassian，审厂的时候厂商解释比我们自己解释还被动。

但真正按下按钮的原因不止合规。

2023年底，Atlassian宣布Server版停售之后，云版价格连续两次上调。我们按当时300人的授权规模做了一次三年总成本测算，Cloud企业版三年TCO比买断Data Center版本的三年总成本高出将近40%。而Data Center版本的三年后还在那儿跑着，Cloud是每年都得付。

另一个很少人公开讲但都私下抱怨的原因：Jira Cloud在国内的访问体验不稳定。不是完全不可用，而是“时好时坏”。周一早上9点半的站会，你永远不知道今天会不会卡在加载旋转画面。这种不确定性带来的团队焦虑，远比偶尔多等两秒更消耗人。

2. 为什么没选其他SaaS，而选了自建

当时在桌上讨论的方案有三个：

• 方案A：继续用Jira Cloud并购买更高版本。 核心问题是成本可预见的持续攀升，且网络体验无法从根本上解决。
• 方案B：切到某国产SaaS研发管理平台。 优势是快、便宜、有中文支持。但劣势是高定制化的Jira工作流很难完全平移，部分插件在国内平台上没有等价功能。
• 方案C：自建Jira Data Center。 数据自主，功能兼容性最高，但需要自己承担运维和灾备。

最终选C，核心判断只有一个：我们希望保留Jira那套已经跑了五年的自定义工作流和自动化规则，而不是再花半年重新适配一套新工具。 这个决策的前提是我们团队有成熟的运维能力。如果你没有专职运维，选C是灾难。

三、拆解最常见的三个误区

1. “把云实例导出再导入就行”，你低估了插件这个最大变量

我见过一个兄弟团队，花了三周把Jira Cloud全量XML备份导出，在新服务器上恢复成功，打开一看傻眼了：70%的自动化规则全部报错，15个插件中有9个无法正常工作。

原因在于，Cloud和Data Center的插件体系本质上是两套生态。Cloud的很多插件是Atlassian Connect框架下的Forge应用，它们根本没有Data Center版本。而部分同时支持Cloud和DC的插件，在两个版本间的配置格式并不完全一致。尤其是ScriptRunner这类深度绑定Jira API的插件，各种Groovy脚本里的类引用、自定义端点地址、Token绑定的密钥路径全都得改。

所以我们后来的做法是：先不管数据，先列一个“插件死亡清单”。把Cloud上正在使用的每一个插件逐一核查，看它在Data Center上有没有等价替代品，或者官方是否提供迁移路径。没有的路，就从源头上放弃对应的自动化流程，重新设计。

这是一个硬仗，没有捷径。

2. “权限和用户映射能自动搞定”

Cloud版的用户管理如果是用Atlassian Access配合Google Workspace或Azure AD做的SSO，迁移到自建后如果不接LDAP/AD，就只能退化成本地用户管理。很多团队在Cloud时期为了方便，直接把外部合作伙伴和客户加进来当“客户角色”，这些账号的权限在Data Center里会变得非常奇怪，它们被当成普通用户，从而能看到不该看到的东西。

另外，Cloud的项目权限默认有一个很“贴心的”特性：项目负责人可以看到所有。而在Data Center里，项目权限的粒度和Cloud不完全一致。一个很常见的翻车场景是：迁移完成后，原来不应该看到财务系统集成项目的同事突然能访问了。

所以我们的做法是：从零开始重新设计一套权限方案，不继承任何Cloud权限。迁移时把全部项目设为私有，然后分批开放。这才是安全的上线方式。

3. “先在测试环境跑通就行”

这句话本身没错，但很多团队所谓的“测试环境”跟生产环境的配置差了十万八千里。内存、CPU核数、数据库连接池大小、反向代理的超时设置，这些看似基础设施的问题，在大量用户并发访问时会暴露得彻彻底底。

我们第一轮迁移演练在4核16G的测试机上跑，一切顺利。切到生产配置8核32G的时候反而出现了诡异的死锁，原因是我们拷贝过来的JVM参数是按小机器优化的，垃圾回收策略在更多内存下反而会引发长时间停顿。这类问题只有在全量数据和并发仿真下才会冒出来。

四、专业判断逻辑：决定先做什么、后做什么

1. 迁移前的“三问法则”

我提炼了一套很朴素但好用的决策模型，用于在启动迁移前快速判断团队是否准备好了。问三个问题：

第一问：我们到底在“复制”还是在“进化”？

如果答案是复制，我们只要原封不动地把云上的东西搬到自建，那么技术风险中等，但业务价值极低。你花几个月搬了个一模一样的东西，老板问你带来什么变化，你答不上来。

如果答案是进化，我们借这个机会清理掉五年来没人用的自定义字段、废弃的工作流、失效的自动化规则，那么工作量会增加30%到50%，但长期收益显著。

我们选的是进化路线。结果发现，在我们Cloud实例的360个自定义字段中，有137个字段已经超过18个月没有任何项目引用。它们活着，只是因为没人为删除负责。

第二问：我们的“停机窗口”能接受多久？

如果答案是“可以接受一个周末”，那么迁移方案相对从容。如果答案是“两小时内”，那你需要一个双写同步方案，复杂度会翻至少三倍。

我们最终争取了48小时窗口。周五晚上8点开始，周日晚8点前必须恢复。这个窗口决定了我们不敢做实时增量同步，只能提前三天做全量快照，然后做差异数据追赶。

第三问：谁为插件兼容性问题兜底？

必须有一个人，且最好是技术负责人，明确承担这个责任。否则插件问题就会变成一个无底洞，每个团队都会说“我那个自动化规则是核心流程不能动”，然后项目永远没法结束。

2. 数据迁移的优先级排序

不是所有数据都应该第一批迁移。我们按业务紧急度和依赖关系排了四个优先级：

1. 项目元数据和活跃工作项（正在进行的Sprint、未完成的Issue）。这是必须最先恢复的，团队要接着干活。
2. 用户账号和项目级权限。没有这一步，第1步恢复之后谁也进不去。
3. 历史Issue和评论。存量数据做完整迁移，但可以放在第1、2步完成后再逐步导入，不影响生产恢复。
4. 附件和仪表板配置。这是最容易出问题也最耗时的部分。我们放在最后，因为在48小时内没它不影响团队恢复工作。

五、具体案例：一次真实的迁移执行过程

1. 数据摸底发现的问题

我们在正式迁移前做了一个“影子审计”，就是把Cloud实例的所有配置和数据量统计一遍。结果吓一跳：

• 附件总大小：1.2TB。其中超过一半是Jira自动生成的截图和日志文件，这部分完全可以清理。
• 工作流数量：74个。但其中40个是过去三年里创建的“一次性实验型工作流”，创建之后从未被任何项目正式启用。
• 自动化规则：126条。其中约30条互相冲突，比如有一条规则把Bug自动分配给张三，另一条规则在五分钟后因为另一个条件又改派给李四。系统不报错，就这么默默执行了好几年。
• 用户账号：有123个账号在6个月内没有任何登录记录，包括4个早已离职的前员工账号。

这些数字摆到桌面之后，原来反对“进化式迁移”的声音安静了。谁都不好意思再说“全部原封不动搬过去”。

2. 迁移执行中的三个关键决策

决策一：放弃实时增量同步，改为两次全量加一次增量。

我们考虑过用Atlassian官方推荐的Project Configurator做项目级迁移，但在实际测试中发现，对于包含大量自定义字段和复杂工作流的项目，PC工具经常把字段映射搞乱。最终我们采用了一个更保守但更可靠的做法：

• 迁移前三天，做一次完整的全量XML备份导出并恢复到目标服务器。
• 迁移前一天，再做一次全量备份，替换掉前一次的恢复数据。
• 正式停机窗口内，用Jira的REST API把最近24小时新增和变更的Issue逐个抓过来。

这个方法笨重，但可控。每一步都可以回滚，每一步的出问题范围都限定在单次操作里。

决策二：附件不跟着数据库一起走。

Cloud附件的存储路径和Data Center的文件系统路径完全不同，而且直接搬文件会遇到权限映射、文件名转义、以及中文文件名在两种环境下的编码差异。我们选择用脚本通过Cloud API逐个下载附件，然后通过Data Center接口重新上传。这看起来效率低，但避免了文件系统级别的各种隐坑。

2TB的附件用了将近20小时下载，期间有3个文件因为Cloud端的临时故障导致SHA校验失败，手动重试后通过。这件事提醒我们：附件下载脚本必须带校验和重试机制，否则你永远不会发现哪个文件悄悄损坏了。

决策三：在自建环境先跑一周“影子期”。

所有数据迁移完成、通知团队可以登录之后，我们并没有立即停掉Cloud的访问。而是用了一周时间，让两个系统并行运行。团队优先在新系统操作，但如果在某个环节新系统不行，仍可切回Cloud。

这一周暴露了三个在测试阶段完全没发现的问题：一个与SSO集成相关的超时配置、一个Nginx反向代理的WebSocket连接断开、以及一个特定浏览器版本下编辑器组件的兼容bug。如果没有这个缓冲期，这三个问题会直接炸在正式切换日。

3. 国产替代的一次并行评估

在迁移计划执行的同时，我们抽了一支两人小分队，独立评估了如果不用自建Jira DC、而是直接用国产平台替代的可行性。评估对象之一是PingCode。

我们关心的问题非常具体：

• 我们的Scrum和Kanban混合管理模式能否原样落地？
• 现有的JQL查询条件能不能迁移？
• 那些集成Jenkins和GitLab的自动化触发器怎么办？

测试下来有几个观察：

在标准化敏捷管理方面，PingCode的产品设计比Jira更贴近国内团队的日常习惯。比如需求管理和测试用例的直接关联、工时填报与研发效能度量的内置闭环，这些在Jira里需要靠多个插件拼凑的功能，在PingCode里是开箱即用的。我们的测试经理在试用两天后说了一句原话：“终于不用再装Zephyr了”。

但高度定制的部分迁移难度很大。我们有一套基于ScriptRunner写的工单自动分发系统，逻辑覆盖了12个自定义字段和3层if-else嵌套。这种深度定制在工作流引擎不同的平台上几乎无法平移，只能重新实现。

所以最终结论是：如果我们愿意接受“放弃部分高定制化流程、拥抱标准化最佳实践”的前提，PingCode是一个完全可以落地的选项，迁移总工作量甚至可能比自建Jira DC更小，因为自建要处理数据库调优、运维监控、灾备建设这些操作，而用SaaS平台这些全由厂商承担。

但我们当时的场景是要保留历史逻辑，所以自建DC成了主路线。如果是一个新团队从零开始，或者一个愿意借机革新的组织，国产平台这条路其实值得认真考虑。

六、行动建议：不同情况下的路径选择

1. 如果你的团队少于50人

坦白说，我不建议自建Jira Data Center。理由很简单：DC版本的授权起步价对中小团队毫无性价比，而且运维成本摊到人头上会显得很贵。这个规模更适合评估国产SaaS平台，比如PingCode或者Worktile这类已经把研发管理流程内建好的工具。它们的定价模型更适合中小团队，而且不需要专人维护。

如果你对Jira有很深的情感依赖，也可以考虑Jira Cloud的Standard版本降级使用，把插件砍掉一半，把自动化规则精简到20条以内，有时候好用和复杂之间只隔了一个清理。先清理再迁移，这条适用于所有规模。

2. 如果你的团队在100-500人之间

这是最容易纠结的区间。建议拿以下筛选条件快速判断：

• 有专职运维人员吗？ 没有的话自建DC的风险急剧上升，建议优先看国产SaaS平台。
• Jira工作流里有没有深度定制的ScriptRunner脚本？ 有的话，迁移到任何非Jira平台的成本会翻倍，自建DC反而是最省事的选择。
• 管理层对数据主权的态度是否坚定？ 如果要求私有化部署，选项基本就自建DC和PingCode私有化版本这两条路。

100人以上的组织在选型时还需要额外关注一个维度：跨项目资源视图和效能度量。很多工具在单项目管理上都做得不错，但一到要看清“20个项目里哪些人在被过度分配”就力不从心。在做PingCode评估时，我们发现它的资源规划和效能度量模块正是为这个规模设计的，同比Jira需要靠Tempo和Structure这类插件才能实现类似效果。

3. 如果迁移是为了满足合规审计

这种情况下的最优解可能既不是自建DC，也不是继续Cloud，而是选择一个支持本地化部署且有完整审计日志的国产平台。PingCode支持私有化部署，支持从账号安全、安全审计、IP限制、访问控制等多维度配置，且适配信创操作系统。对于金融、军工、政务类客户，这些是硬门槛。

我们在迁移中接触过一个真实的审厂场景：检查人员要求在一小时内提供某个项目过去半年的所有操作记录，包括谁在什么时间点修改了Issue的哪个字段、旧值是什么、新值是什么。Jira Cloud能做到，但要调API、要拼数据、要应对限流。国产平台如果内置了结构化的审计报表，这个体验会好很多。

七、取舍：哪些东西必须放弃，哪些必须坚持

1. 必须放弃的东西

（1）对“无缝迁移”的一厢情愿。 不管选哪条路，总会有些功能在迁移后不一样。有些是变好了，有些是暂时找不到替代品。接受这一点，项目才能推进下去。

（2）历史遗留的“无人认领配置”。 那些没人知道为什么存在的自定义字段、再也没有团队用的工作流、失效了三年没人管的仪表板，请借这次迁移机会清理掉。带过去只会让新系统从一开始就背负历史包袱。

（3）Cloud特有的便利性功能。 比如Atlassian Intelligence的AI摘要、部分Forge生态插件、Cloud独有的沙盒环境，这些东西在自建环境里没有等价物。如果你的团队高度依赖这些功能，迁移前要做好功能盘点，在内部正式公示哪些功能将不再可用。

2. 必须坚持的东西

（1）上线前必须做并行验证。 没有并行跑过至少一周，我绝对不会正式切换。这件事说起来简单，但在实际项目里经常因为“赶进度”被砍掉。砍掉并行验证的后果，就是在上线第一天被大量用户报Bug，信心一夜崩塌。

（2）权限体系必须重新审核。 不要复用Cloud的权限导出。逐个项目过，逐个角色看，把该关的门关上。宁可上线时管控过严被人抱怨，也不要上线后发现数据泄露。

（3）必须有一个明确的回滚方案。 Cloud环境在迁移期间保持运行，且至少保活到新系统正式运行满一个月。永远不要过早关掉旧系统。

3. 可以妥协但要有底线的部分

附件迁移可以分批，但元数据迁移必须一次性完成。 Issue编号、项目Key、用户Key这些一旦在新系统开始产生新数据，就不能再改。

插件替代可以逐步进行，但核心自动化规则必须在切换前跑通。 我们允许一些“锦上添花”的插件在迁移后第二个月才补上，但任何涉及Issue流转、权限分配、通知触发的规则都必须在上线前验收。

性能可以调优后补，但可用性必须足够。 上线第一周的性能不完美是正常的，但不能经常性宕机或大面积超时。上线前至少做一次全链路压测，模拟足够比例的读写混合场景。我们在压测中发现了一个MySQL连接池配置过低的问题，在不压测的情况下根本暴露不出来。

八、三个月后的回顾：值不值得？

上线三个月后，我们做了一次内部回顾。结果是：

不满意的地方：

• 运维负担确实比预期重。DBA每个月至少要投入2个工作日做巡检和优化。
• 插件的维护成本也比Cloud高，Cloud版本更新是自动的，自建版本每次升级都要先在测试环境验证。
• 有3个Cloud插件至今没有在DC平台找到完美替代品，团队只能接受功能降级。

满意的超出预期的部分：

• 页面加载速度。国内机房部署后，从点击到完全加载的平均时间从Cloud时期的3-5秒降到了0.6-1.2秒。别看数字不大，这直接改变了团队对工具的耐心。以前打开一个Issue的间隙会走神看手机，现在几乎秒开。
• 数据自主带来的安全感是真的。有一次客户审厂，我们直接打开数据库执行一条SQL加上项目级过滤条件，十分钟出完报告。同样的需求在Cloud上至少要走API导出加Excel透视。
• 成本方面，按三年计算，这次迁移的总投入（含人力、授权、硬件）已经低于继续订阅Cloud的累计支出。从第四年开始，成本优势会更明显。

九、最后的话

这篇文章不会给你一个“标准答案”。迁移这件事，从来不存在一条所有人的最优路径。

我能给的是一套经实践验证的决策框架：

• 先搞清楚你的真实驱动力，是成本、合规、体验还是自主权？不同的驱动力会把决策引向完全不同的方案。
• 把数据摸底做在决策之前，你不知道自己的实例有多臃肿，就不知道迁移有多难。
• 接受“不完美迁移”的现实，有些东西会变好，有些会变差，有些会在这个过程中被清理掉。这是好事。
• 永远不要在没有并行验证的情况下切换，这是底线。

如果你正在考虑这条路，下一步建议是先做一次完整的“Jira健康检查”：导出全部配置清单，统计插件使用情况、自定义字段数量、自动化规则清单、附件总大小和用户活跃度。这些数字摆到桌面上之后，很多决策会变得清晰很多。

如果你不具备运维能力但又必须离开Jira Cloud，PingCode这类国产研发管理平台是值得认真评估的选项。它们在安全合规、本地化体验和开箱即用的研发管理能力上，已经在很多维度超越了自建方案的综合体验。

迁移不是目的，让团队更高效才是。 别为了迁移而迁移，也别害怕打破现有的东西。工具是为人服务的，不该反过来。