jira迁移去繁就简：删了80%旧项目

一、先给你一个真实结论：Jira 迁移中最值钱的动作，不是“搬”，而是“扔”

2018 年我第一次操盘 Jira 迁移时，犯过一个至今想起来仍然肉疼的错误，我把 1200 多个项目近乎原封不动地搬到了新环境。迁移脚本跑了整整 11 个小时，数据校验又花了两天，最后交付给业务方的时候，对方看了一眼项目列表，问了一句让我当场噎住的话：“为什么这些三年前就没人用的项目还在？”

后来我给团队复盘这次迁移，算了一笔账：那 1200 多个项目中，过去 18 个月有过任何活动记录的项目不到 200 个，换句话说，接近 85% 的项目是“僵尸”。为了这 85% 的垃圾数据，我们多花了至少 40 个小时的迁移时间、多占用了 60% 的存储空间、多付了一整年的额外许可证费用，因为旧环境的用户账号也必须一并迁移以保持数据关联。

从那时起我就确立了一条铁律：Jira 迁移的第一步，永远应该是大规模清理，而不是大规模搬运。

去年我在 PingCode 团队参与了一次针对某 400 人研发组织的 Jira 迁移项目，验证了一套“先瘦身后搬家”的方法论。最终结果：将源环境的 800+ 项目压缩到 140 个，迁移耗时从预估的 8 小时缩短到 2.5 小时，数据校验错误率降低了 70% 以上，更关键的是，迁移完成后 3 个月内，没有一个业务方来投诉“找不到项目”或“数据丢了”。

这篇文章就是这套方法的完整拆解。如果你正在进行或计划 Jira 迁移，建议在动手搬任何东西之前，先读完它。

二、为什么你的 Jira 里 80% 的项目都是垃圾，这不是你的错，但这是你必须解决的问题

1. Jira 项目膨胀的三个根因

我见过几十个组织的 Jira 实例，大小从几百到几千项目不等。几乎每一个都存在严重的项目膨胀问题。这个问题的根源其实很清晰：

第一，Jira 的权限模型倒逼出大量“隔离型项目”。Jira 的权限方案绑定在项目级别，而很多组织有复杂的部门隔离需求，A 部门的人不能看 B 部门的缺陷，外包团队只能看到自己的任务。当一个项目里需要容纳多个隔离群体时，Jira 的权限颗粒度根本不够用。于是管理员的“解决方案”简单粗暴：拆项目。一个产品线拆出七八个项目，每个项目对应一个隔离群体。

第二，Jira 的项目创建成本极低，删除成本极高。创建一个新项目只需要 30 秒，配几个字段和权限就能用。但删除一个项目呢？你得先确认没有人在用它、没有自动化规则依赖它、没有 Confluence 页面链接到它、没有外部系统通过 API 调用它的数据，这种信息不对称让“删除”变成一场心理博弈。大多数管理员的选择是：放着吧，不碍事。

第三，组织架构变动是项目膨胀的加速器。一个部门拆成两个，项目跟着拆；一个产品线合并到另一个，项目留着“以防万一”；一个项目经理离职了，他当年创建的七八个测试项目就成了无人认领的遗产。每次组织变动都在 Jira 里留下一层沉积岩，经年累月就形成了你看到的那座“项目坟场”。

2. 真正让你肉疼的不是存储成本，是这些隐性代价

很多人以为“项目多就多呗，硬盘又没多少钱”。说这种话的人通常不是 Jira 管理员。我来告诉你真正的代价是什么：

第一，全实例级别的操作会被拖垮。Jira 的索引重建、版本升级、备份恢复、全局权限重算，这些操作的耗时和整个实例的数据量呈超线性关系。我有一次在某个 600 项目的实例上做版本升级，光是预检查就跑了一个半小时，而同一个版本在 100 项目的测试实例上只用了 12 分钟。

第二，搜索和过滤体验烂到用户想砸键盘。Jira 的搜索默认范围是“所有项目”。当你的实例里有几百个项目时，用户每次搜索 Issue 都会触发跨项目的大范围索引扫描。我见过最夸张的情况是，一个研发主管在 Jira 里搜一个关键词，结果返回了 4000 多条结果，来自 80 多个项目，其中一大半是他根本没权限访问的，根本没法用。

第三，管理员维护的认知负荷是指数增长的。每个项目都有自己的工作流、自定义字段、权限方案、通知方案、自动化规则。当项目数量超过 200 个时，管理员的脑子就变成了一个“配置碎片垃圾桶”，你根本记不住哪个项目用了哪个字段、哪个工作流被哪些项目引用了。改一个全局字段？提心吊胆，因为你不确定改完后会不会炸掉 50 个项目。

第四，也是最容易被忽视的，用户信任崩塌。当团队在 Jira 里经常搜到过期信息、找不到正确项目、被分配到已废弃的 Issue 时，他们不会反思“是不是我搜索方式不对”，而是直接得出一个结论：“这个系统烂透了，没法用”。项目膨胀最终杀死的是用户对整个系统的信任，而这种信任一旦崩了，你推什么新流程都没人配合。

三、大迁移前的“资产审计”，80% 的数据到底能不能删？

1. 我设计了四分类法来给项目“贴标签”

在 PingCode 协助的多个迁移项目中，我落地了一套项目分类标准，把所有项目分成四类：

这套分类法在 400 人组织的实际项目中跑出来的结果非常震撼：活跃项目占 18%，休眠项目占 22%，存档项目占 35%，废弃项目占 25%。也就是说，真正需要完整迁移的项目不到五分之一，超过一半的项目可以采用“导出归档”或“直接删除”的策略。

2. 审计不能只靠管理员拍脑袋，必须把业务方拉上船

我自己踩过的最大的坑就是“管理员自查”。我曾经花了整整三天，凭自己的记忆给 300 多个项目标记状态，然后群发邮件通知各业务方“以下项目将被删除”。结果可想而知，三天内收到 47 封“等等别删！！！”的邮件，其中有十几个项目我已经标记为“废弃”但实际上业务方还在用（只是用的频率很低）。

后来我改进了流程，核心原则就一条：管理员只提供数据，业务方来做决策。具体操作步骤：

1. 由管理员导出全量项目清单，包含项目名称、创建时间、最后活动时间、Issue 数量、创建者、项目负责人等字段。
2. 由管理员基于数据做初步标记建议，按照上文四分类法打上“疑似休眠”“疑似废弃”等标签，但绝不替业务方做最终决定。
3. 将清单分发给各业务方负责人，要求他们在指定期限内逐条确认：“保留/归档/可删除”。必须明确写出，逾期不回复视为“可删除”，这一条是推进效率的关键。
4. 业务方确认完毕后，由管理员汇总最终清单，并对“保留但有争议”的项目组织线上对齐会。
5. 最终清单需各方签字确认（或至少邮件确认），形成正式的迁移范围文档。

这个流程多花了大约一周时间，但它的价值在于：把“删项目”这个敏感动作从管理员个人的风险变成了组织共识。万一将来有人问“为什么那个项目没了”，你有完整的确认记录可以追溯。

四、技术层实操：如何安全地“删掉 80%”而不炸掉生产环境

1. 废弃项目的删除，不是点个“Delete”那么简单

很多 Jira 新手以为删除项目就是进管理后台、找到项目、点删除按钮。我只能说，如果你直接这么干，大概率会在 24 小时内被业务方追着骂。

一个“安全删除”的完整前置检查清单：

• 权限依赖检查：有没有外部系统（如 CI/CD 工具、监控平台）通过 API 调用这个项目里的 Issue？可以先在 Jira 的审计日志里查该项目最近 30 天的 API 访问记录。
• 自动化规则依赖检查：全局自动化规则中是否引用了该项目作为触发范围或操作目标？这个在 Jira 的 Automation 管理页面里可以看到。
• Confluence 关联检查：Confluence 中有没有页面嵌入了该项目的 Issue 清单、Jira 图表或筛选器？断开后这些嵌入会变成错误提示，非常影响体验。
• 外部链接检查：有没有人在邮件、文档、IM 群里发过该项目的 Issue 链接？迁移后这些链接会全部失效。
• 子任务/关联关系检查：该项目的 Issue 有没有被其他项目的 Issue 关联、引用、跨项目链接？如果有，直接删除会导致关联方出现“幽灵引用”。

我的推荐操作顺序：先标记为“不可访问”（修改权限方案把所有用户踢掉）→ 观察 1-2 周 → 确认无人反馈 → 执行备份导出 → 正式删除。这个“软删除-观察-硬删除”的三段式流程虽然慢一点，但能极大降低翻车概率。

2. 那些“好像还有用”的休眠项目怎么处理，归档策略与分级迁移

休眠项目是决策最困难的一类。删了吧，怕哪天要用；留着吧，又明确知道最近一年没人碰过。

在 PingCode 辅助的迁移项目中，我设计了一套“分级迁移”策略来处理这类项目：

• 休眠但包含合规审计数据的项目（如已结项的政府项目、已交付的甲方案例）：导出为 PDF 或 JSON 静态备份，存储在内部文档库中。不迁移到新环境，仅在备份记录中留下检索索引。
• 休眠但未来可能重启的项目（如暂停的产品线、季节性活动项目）：迁移到新环境，但标记为“归档”状态，权限设为全员只读。项目名称加 [已归档] 前缀，并在描述中注明归档日期和责任人。
• 休眠且业务方明确表示“不再需要”的项目：参照废弃项目流程处理。

这里有一个非常实用的经验：迁移后的“归档项目”不要和活跃项目混在同一个项目列表里。Jira 原生不支持项目分组，但大部分替代工具（包括 PingCode）支持将归档项目归入独立的“归档空间”或通过标签过滤。如果继续用 Jira，可以通过项目分类（Project Category）做分组，至少能让用户一眼区分。

3. 迁移工具不是万能的，导入前必须做的“配置瘦身”

即使你使用的是专业的 Jira Importer 工具（无论是 Jira 官方的还是第三方的），迁移工具的本质是“忠实搬运工”，不是“整理收纳师”。源环境有多少个项目、多少套工作流、多少个自定义字段，它就会原样搬到目标环境。

所以，在数据导出之前，你还需要做一轮“配置瘦身”：

• 工作流去重合并：我见过最夸张的情况是，一个 300 项目的实例里有 160 多套工作流，但仔细一看，核心流程其实只有七八种变体，其余的都是“改了名字但流程一模一样”或者“多了一个不用的状态”。合并后可以缩减到 15 套以内。
• 自定义字段清理：用 Jira 的“自定义字段分析”功能，找出“关联到 0 个屏幕”或“在所有项目中均未被使用”的字段。这类字段通常占比 30%-50%，直接删除对业务零影响。
• 权限方案标准化：把几百套权限方案收敛为几套标准模板（如“内部公开”“部门可见”“仅项目成员”），迁移后统一应用。

配置瘦身的好处是双重的：一是减少了迁移过程中的字段映射复杂度，二是新环境的维护负担大幅降低。一个干净的新环境，本身就是迁移项目的核心交付价值之一。

五、实战复盘：PingCode 辅助下的一次 400 人组织 Jira 迁移

1. 项目背景与初始状态

这是一家做企业 SaaS 的研发组织，总人数约 400 人，10 个产品线，使用 Jira Software（Data Center）已超过 6 年。迁移的触发原因是 Jira Server 版本停止销售后，企业决定趁此机会完成从 Atlassian 体系到国产工具链的整体切换。

摸底阶段的几个关键数据：

• Jira 项目总数：823 个
• 活跃用户：380 人
• 总 Issue 量：超过 120 万条
• 自定义字段：340+ 个
• 工作流方案：180+ 套
• Confluence 空间：45 个，页面总数超过 6000

初步评估，如果直接全量迁移，预估耗时在 8-12 小时（纯数据导入），且迁移后的环境会直接继承所有技术债。

2. 我们如何在一周内从 823 个项目砍到 140 个

整个清理过程分为四个阶段：

第一阶段：数据审计（2 天）

导出全量项目清单，按“最后活动时间”“Issue 创建趋势”“项目创建者是否在职”三个维度做初步分类。结果：823 个项目中，超过 365 天无活动的有 487 个，其中有 210 个项目的创建者已经离职且无明确负责人。这 210 个直接被标记为“建议删除”。

第二阶段：业务确认（3 天）

将分类清单发给 10 个产品线的负责人，按“确认保留 / 确认归档 / 确认可删除”三个选项逐条反馈。逾期未回复的项目一律视为“可删除”。最终回收确认结果后，形成了清晰的执行清单：

• 确认保留（活跃+休眠）：140 个项目
• 确认归档（仅导出备份）：280 个项目
• 确认可删除（无异议）：403 个项目

第三阶段：执行清理（1 天）

在源 Jira 环境中分批执行：先对 403 个可删除项目执行备份导出（保存至内部 NAS），然后逐一删除。再对 280 个归档项目导出为 JSON+附件压缩包，按产品线分目录存储。

第四阶段：正式迁移（1 天）

使用 PingCode 提供的 Jira Importer 工具，将保留的 140 个项目导入新环境。由于数据量已大幅缩减，整个导入过程耗时仅 2.5 小时，映射配置和校验又花了半天。隔天组织各产品线做 UAT 验收，最终发现的数据问题只有 7 处，均在小半天内修复完毕。

3. 迁移后三个月的跟踪数据

迁移完成后，我跟踪了这个组织三个月的使用数据，几个关键发现：

• 新环境日均活跃度：迁移后第一个月恢复到源环境的 85%，第三个月达到源环境的 110%，说明用户适应顺利且使用意愿在增强。
• “找不到项目”的求助量：三个月内仅收到 3 次相关工单，且都是个别用户不知道归档项目的查找方式，而非数据丢失问题。
• 管理员维护时间：从原来的每月约 15 小时下降到 3-4 小时，主要原因是工作流和字段大幅标准化后，日常配置变更的复杂度骤降。
• 搜索速度提升：全局搜索的响应时间从原来的平均 4-6 秒下降到 1 秒以内，用户体验显著改善。

这些数据充分验证了“瘦身优先”策略的有效性。

六、如果你正准备 Jira 迁移，这是我给你的行动路线图

1. 分场景决策：三种典型情况的不同策略

并非所有组织都需要“删 80%”。根据我的经验，迁移策略取决于你的组织规模和 Jira 实例的健康度：

场景一：小型团队（50 人以内，项目数 < 30）

项目数量本身不多，清理的收益有限。重点是配置整理：把工作流统一为 2-3 套标准流程，字段收敛到 30 个以内，权限方案标准化。迁移本身不复杂，但趁此机会把配置理顺，未来的扩展会顺畅很多。不建议花太多时间在删项目上，因为每个项目可能都还有价值。

场景二：中型组织（50-200 人，项目数 100-500）

这是“瘦身策略”收益最高的区间。项目数量已经开始产生管理负担，但尚未完全失控。建议目标定为删掉 40%-60% 的项目，主要清理对象是离职人员创建的测试项目、已完成的历史版本项目、以及因权限隔离而过度拆分的冗余项目。

场景三：大型组织（200 人以上，项目数 > 500）

到这个量级，“删 80%”不仅可行，而且几乎是必须的。持续膨胀的 Jira 实例会严重拖垮性能和维护效率。这个场景下，需要一个专项项目组来推动清理工作，建议由研发效能团队牵头，各业务线指定接口人，按照本文的四分类法和四阶段流程推进。

2. 如果业务方死活不同意删，如何推进艰难的共识

在实际工作中，你一定会遇到这种场景：某个项目已经三年没动过，但业务方说“这个是历史资料，不能删”。你不能靠权威压人，也不能直接放弃。

我的方法是一句灵魂拷问：“如果这个项目现在突然消失，你的日常工作会受什么具体影响？如果需要里面的数据，你现在的团队会怎么用？”

根据对方的回答分三种情况处理：

• 对方说不出具体场景（“嗯……反正就是觉得有用”）→ 大概率是心理依赖，不是真实需求。建议归档导出后删除，告诉对方备份文件的位置。
• 对方能说出具体场景但频率很低（“年底审计可能需要拉去年结项的三个项目数据”）→ 这是真实的合规需求。按“休眠项目”处理，归档只读。
• 对方能说出日常高频场景（“我们每周都要从那个项目拉数据做周报”）→ 那这个项目根本就不是休眠项目，是你审计的时候漏了。重新归类为“活跃项目”。

核心原则：让数据可用，但不一定要放在生产环境里。一份在 NAS 上存着的 JSON 备份也是一份有效的历史记录，它只是不需要占用你每天都要维护的 Jira 实例而已。

3. 迁移后的第一周，该做什么，防止新环境再次膨胀

我见过太多“千辛万苦搞完迁移，半年后又回到老样子”的案例。清理是一次性的，但治理必须是持续性的。

迁移上线后，建议立即落地三项治理机制：

1. 项目创建审批制：不再随意允许任何人创建项目。设置一个轻量级审批流程，申请者需要填写项目用途、预计存续周期、是否需要跨部门权限。审批人不一定是管理员，可以由研发效能团队或 PMO 统一把控。
2. 项目生命周期标签：每个项目在创建时就标注预计结束时间或复审周期。例如，活动类项目标注“活动结束后 1 个月自动归档”。系统不能自动执行也没关系，关键是有了记录，管理员可以定期拉清单做清理。
3. 季度项目健康度巡检：每季度由管理员跑一次“最后活动时间”报表，筛选出超过 6 个月无活动的项目，发邮件给对应负责人确认状态。这是一个每次只需半小时的低成本习惯，但能防止 80% 的未来膨胀。

七、最后的话：迁移本身不是目的，干净的环境才是

回到标题里的那个数字，删了 80% 旧项目。这个数字不是为了制造冲击感而编造的噱头，它是基于多个大中型组织迁移项目提炼出的一个合理目标。它不是要求你闭着眼睛删掉 80%，而是告诉你：如果你的 Jira 实例里大部分项目已经不再产生价值，那你有充分的理由和可行的方法，在迁移前把它们清理掉。

迁移的初衷通常是更换工具、降低成本或满足合规需求。但迁移过程的真正价值，往往不在于“搬到了一个新地方”，而在于你终于有机会把沉积多年的技术债一次性清算干净。一个只有 140 个项目的干净环境，比一个装了 800 个项目的臃肿环境，无论放在哪个工具平台上，都能让团队的工作效率提升一个台阶。

所以我的建议非常简单：

• 现在就打开你的 Jira 管理后台，导出一份全量项目清单。
• 按“最后活动时间”排个序，看看有多少项目超过一年没人碰过。
• 把这个数字发给你自己，这就是你迁移时可以削减的潜力空间。

不要等到迁移脚本跑到一半才后悔没早点清理。现在开始审计，还来得及。