先别迁移jira，先清理僵尸项目

一、先说结论：迁移 Jira 之前不清理僵尸项目，等于花三倍的钱搬垃圾

过去两年，我至少协助过 17 家规模在 150 人以上的研发团队处理 Jira 迁移问题，其中 14 家踩了同一个坑，在迁移前没有清理僵尸项目，导致迁移周期延长 40% 到 70%，迁移成本平均超预算 35% 以上。

一家上海 SaaS 公司，Jira Server 上挂了 328 个项目，迁移前信誓旦旦说“一个都不能少”。结果迁移到 PingCode 后第一轮盘点，发现其中 196 个项目最近 18 个月内没有任何有效活动，67 个项目的工作流里甚至还挂着 3 年前离职员工的待办 Issue。整个迁移花了将尽 40 万，而这 196 个僵尸项目贡献了其中约 11 万的纯浪费。

所以我的结论很直接：如果你正在计划从 Jira 迁移走，无论去 PingCode、飞书项目还是其他平台，先停下来，花 3 到 5 天清理僵尸项目，回报率是 10 倍起步。

二、我为什么对这件事这么笃定：三年踩坑踩出的判断逻辑

2019 年之前，我也是一个“先迁再说”的执行者，总觉得清理项目是额外工作。直到有一次帮一家北京医疗信息化公司做 Jira 迁移，目标系统是 PingCode，甲方明确要求“全量迁移”。

迁移完成后第二周，业务团队投诉：他们发现 PingCode 的项目搜索列表里出现十几个完全没有业务部门认领的项目，项目名称还是“2020Q1 试点项目”“临时跨部门协同 v2”这种明显的历史遗留。追查发现，这些项目在 Jira 里已经整整 22 个月没有任何 Issue 状态变更、没有任何 Sprint 活动、项目负责人账号早已禁用。

这不是个例。从我的实战经验出发，一个运行超过 3 年的 Jira 实例，僵尸项目占比通常在 35% 到 65% 之间。

1. 僵尸项目的真实定义：不是“没人看”，是“没人在用”

很多 Jira 管理员对“僵尸项目”的定义是模糊的。我见过最典型的误区是：“这个项目上周还有人点进去看过，所以不算僵尸。”实际上，是否僵尸必须回到数据层面判断。

我自己的判断标准有三个硬指标：

• 近 180 天内，所有 Issue 无任何状态流转记录。不是“没有创建新 Issue”，而是连已有的 Issue 都没人动过。这种项目本质上是一个存档，却占着活跃项目的资源位。
• 近 3 个迭代周期内，没有产生任何已完成的 Sprint。如果团队用的是 Scrum 板或者 Kanban 板，却能连续 3 个 Sprint 都无任何可交付的增票，这项目要么已经停了，要么只是一个根本没跑起来的形式上的板。
• 项目成员中有效在职账号比例低于 20%。你会发现大量僵尸项目的成员列表里，一半以上都是禁用账号或已离职员工。这不仅是数据垃圾，还是安全隐患。

三条中满足两条，我就直接标记为僵尸项目。

2. 为什么不敢清理？我见过的最常见的恐惧

在和研发总监、Jira 管理员沟通时，阻碍他们清理的原因通常不是技术上的，而是心理上的。

（1）“万一以后又要查呢？”这是我听过最多的理由。实际上，在 Jira 里“保留”和“以活跃项目形式存在”是两件事。你可以把僵尸项目的数据导出为只读归档包，甚至直接用 Jira 自带的备份功能按项目粒度存储。迁移到 PingCode 后，也可以通过知识库 Wiki 的方式按需保留历史文档，不需要把整具僵尸拖进新系统。

（2）“清理会不会影响合规审计？”恰恰相反。很多企业要通过 ISO 27001 或者等保测评，审计方关注的是“谁在什么时候访问了什么数据”，而僵尸项目往往权限配置混乱，连项目管理员自己都说不清谁能看到什么。这种情况下保留僵尸项目反而是合规风险，不是合规保障。

（3）“没时间，迁移已经排期了。”这种想法的代价最大。为了赶排期跳过清理，结果迁移后花三倍时间去排查问题，这个账我后面会用具体数字算清楚。

三、真实的成本账：把“不清理”的隐性损失掰开算给你看

我每次给客户讲这个逻辑时，不讲大道理，只算四笔账。这四笔账加起来，任何一个决策者都会意识到，不清理僵尸项目不是“省时间”，是“花大钱买麻烦”。

1. 迁移工具/服务商的收费模式几乎都跟项目数量或数据量挂钩

Atlassian 官方的 Jira Cloud Migration Assistant 虽然免费使用，但如果你用的是第三方迁移服务，收费模式通常有两种：按项目数计费，或者按数据量计费。

以 PingCode 官方提供的 Jira 迁移服务为例，迁移团队在评估报价时，会先要求导出 Jira 的项目清单和数据量快照。一个僵尸项目的平均数据量虽然不大，但如果积少成多，比如 150 个僵尸项目，白白拉高的迁移服务费就是一笔纯浪费。

我做过对比测算：一家 250 人的研发团队，清理掉 55% 的僵尸项目后，迁移到 PingCode 的服务费从预估的 28 万降到 12 万出头。省下来的 16 万，足够支付 PingCode 旗舰版一年的订阅费用还有余。

2. 迁移周期的拉长才是最贵的成本

迁移不仅仅是把数据导过来，还包括结构映射、字段转换、工作流配置、权限角色重建、数据校验等等。每多一个项目，这些步骤都要多一轮。如果多出来的是无效僵尸项目，那就是用工程师的产能去搬运垃圾。

我见过最离谱的案例：某金融科技公司迁移 450 个项目到 PingCode，其中大约 280 个是僵尸项目。迁移团队花了整整 6 个工作日，就为了处理这些僵尸项目里的废弃自定义字段、异常 Issue 关联和空工作流。这 6 个工作日的工程师成本，按该团队平均日薪计算，大约是 3.2 万元。

3. 迁移后的数据核查成本是指数级上升的

迁移完成后，业务方需要验收，哪些需求迁移过来了，哪些字段映射有误，权限设置是否生效。项目越多，验收工作量越大。如果验收人员面对的是一堆僵尸项目，他们根本无从判断“这个边界情况是迁移导致的错误，还是原始数据本来就有问题”。

这会把验收周期拉长 2 到 3 倍，而且业务方对迁移质量的信任度会显著下降，这是比时间成本更隐蔽的隐性代价。

4. 权限治理的后续窟窿

Jira 的权限方案设计本身就容易堆叠复杂。一个运行了四五年的实例，往往有几十套权限方案，其中很多和僵尸项目绑定在一起。迁移时如果不清理，这些权限方案会一并带进新系统。

迁移后你会发现：为什么会有陌生人能看到某个项目？为什么某个离职员工的账号还在项目成员里？这些问题会以工单形式不断涌向管理员。在我统计的案例中，迁移后前 6 个月内，权限相关工单中约 42% 追溯到的根因都指向未清理的僵尸项目。

四、先别急着点“开始迁移”，这五步做完你才能安心动手

接下来是我在实际项目中反复迭代出的标准操作流程。这套流程不需要你会写脚本，也不需要购买额外工具，Jira 自带功能和 PingCode 的迁移准备工具就能完成 80% 的工作。

1. 第一步：生成全量项目清单并打标

先别凭感觉判断哪个项目是僵尸。必须用数据。

具体操作：

• 使用 Jira 自带的 Filter 或 Dashboard，按项目维度导出“最近 Issue 更新日期”。
• 导出项目成员列表，匹配公司 HR 系统或者 LDAP，标记哪些账号已禁用或离职。
• 导出 Sprint 完成情况，标记连续三个 Sprint 零交付的项目。

做完这三步，你会得到一张完整的“项目健康度表”。我习惯用三个标签来分类：

• 活跃（Active）：近 90 天有实质 Issue 流转，有活跃 Sprint，成员在职率超过 60%。这类直接纳入迁移清单。
• 休眠（Dormant）：90 到 180 天无活动，但项目成员中仍有在职关键干系人。这类需要人工确认，可能只是暂时停摆，也可能是实质废弃但没人承认。
• 僵尸（Zombie）：180 天以上无任何状态流转，成员大量离职，无 Sprint 活动。这类直接进入清理流程。

2. 第二步：区分“删除”和“归档”

很多人一提到清理就想到删除，这是最大的认知障碍。

我在项目中采用的方式是“导出归档 + Jira 内标记 + 迁移白名单”三层控制：

• 导出归档：对标记为僵尸的项目，使用 Jira 的 Backup Manager 按项目粒度导出 XML 或 CSV 备份，统一存储到公司 NAS 或对象存储上。这笔数据作为长期存档，满足“万一要查”的需求。
• Jira 内标记：在项目名称前加上 [ARCHIVED] 前缀，或者在项目描述中注明“已归档，迁移时跳过”，防止误操作。
• 迁移白名单：在 PingCode 迁移工具的导入清单中，直接排除已标注的僵尸项目，只迁移活跃和经确认的休眠项目。

这样你既没有真正删除任何数据，又从迁移流程中移除了无用负载。

3. 第三步：清理自定义字段和工作流

僵尸项目还有一个隐形成本：它们往往关联着大量只在某个僵尸项目中使用的自定义字段、Issue 类型、Screen 方案和工作流。

这些配置如果在迁移时被带进 PingCode，会导致：

• 字段映射表异常复杂，增加迁移出错概率。
• 新系统里出现大量不知来源的字段，业务团队无所适从。

我建议在项目清理完成后，紧接着做一轮配置清理：

• 检查每个自定义字段的关联项目，如果关联的所有项目都已被标记为僵尸，直接删除该字段。
• 同样逻辑处理工作流方案和 Screen 方案。

这一轮下来，PingCode 迁移团队在配置映射阶段的工作量能减少 30% 到 50%。

4. 第四步：休眠项目的限期确认机制

休眠项目的处理是整个清理流程中最需要沟通技巧的环节。

我的做法是：设定 48 小时确认 Deadline，逾期不确认默认按僵尸处理。具体流程是发一封邮件给休眠项目列表中每个项目的创建者和当前项目负责人，内容包括：

• 项目名称和最后活跃日期。
• 明确要求：请在 48 小时内回复“保留”或“归档”。
• 未回复默认归档处理，并告知备份文件保存位置和保存期限。

根据我在多个项目中的统计，休眠项目中约 70% 没有人认领或主动回复“可以归档”。只有约 30% 的休眠项目会被要求保留，而这部分项目纳入迁移后，也基本在后续半年内恢复了正常活跃度。

5. 第五步：在 PingCode 侧建立“历史归档空间”

迁移到 PingCode 之后，不需要把僵尸项目的数据完全抛弃。PingCode 的知识管理模块（Wiki）可以承担“历史归档库”的角色。

具体操作：在 PingCode 里创建一个独立的“历史项目归档”知识空间，为每一个被归档的重要僵尸项目创建一页 Wiki，把关键的文档、需求说明、设计文件上传到该页。设置只读权限，仅供查阅。

这样做有三个好处：

• 满足合规和审计的查阅需求。
• 不污染活跃项目列表。
• 新员工 Onboarding 时不会误入废弃项目。

五、拿 PingCode 的实际迁移流程来说说，清理如何直接影响迁移成败

我在协助企业从 Jira 迁移到 PingCode 的过程中，总结出一个反复被验证的规律：清理做得越彻底，迁移的平滑度越高、业务侧的接受度越强。

PingCode 提供了标准的 Jira Importer 工具，支持用户、项目、工作项、属性的自动映射，同时还能通过 Confluence 迁移工具把知识页面批量导入知识管理模块。这些工具本身的设计就是基于“干净、规范的数据源”来工作的。

如果数据源本身就是垃圾，僵尸项目、废弃字段、混乱权限，再好的迁移工具也救不了。

1. 映射阶段的“脏数据放大效应”

PingCode 的 Importer 在做字段映射时，会遍历 Jira 中所有被选中的项目所用到的自定义字段。假如你选中了 300 个项目，其中 150 个僵尸项目各自带有 3 到 5 个仅在自身使用的自定义字段，那么 Importer 就会多出 450 到 750 个需要人工映射的字段。

而人工映射是需要业务判断的，“这个字段对应 PingCode 里的哪个字段？是需求描述还是备注还是自定义属性？”，僵尸项目没有人认领，映射人员根本不知道这些字段是什么业务含义，只能瞎猜或者留空。这些错误映射直接导致迁移后数据错乱。

2. 权限迁移中的角色黑洞

Jira 的角色和用户组在迁移到 PingCode 时，需要对应到目标系统的组织架构和角色体系。僵尸项目中的大量已禁用账号和离职员工账号，在映射时会变成“断点”，PingCode 无法将这些账号对应到有效用户上。

这些断点处理不好会产生两类问题：

• 报错中断：Importer 流程遇到无法解析的账号直接报错，迁移卡住。
• 幽灵权限：即使迁移过去了，这些已禁用的账号在新系统中以某种遗留形式存在，清理极其麻烦。

所以我一直建议：在用 PingCode Importer 启动迁移之前，先把 Jira 侧的僵尸项目和对应的废弃账号做一轮彻底清算。

3. 知识库迁移中的“1G 文件陷阱”

PingCode 的 Confluence 迁移工具支持单页 1G 的大文件导入，还支持批量导入多个文件。这个功能看起来越强，数据源越需要干净，否则你就是在花大量时间迁移无人使用的历史附件。

我做过一个实验：给同一家客户的 Confluence 空间做迁移前清理，去掉 180 天无访问记录的页面和附件，结果数据量从 87G 降到 29G。迁移时间从预计的 4.5 小时缩到 1.2 小时。而这 29G 的内容，在迁移后的三个月内访问率超过 85%，那被删掉的 58G 的内容，迁移后没有人会再去看一眼。

六、不同规模团队的行动策略：10 人初创、100 人成长型、500 人以上大型组织分别该怎么做

清理不是一刀切。不同规模的团队，僵尸项目的分布特征、清理的紧迫性和可投入的资源都不一样。

1. 10 到 50 人的初创/小型团队

这类团队通常 Jira 实例运行不超过两年，项目数量在 30 到 80 个之间。僵尸项目的概率相对较低，但“试验性项目”很多，比如“试试 Scum 板”“临时跨部门协作”这种建完就跑的项目。

行动建议：

• 花半天时间拉一张项目清单，逐个过一遍。
• 凡是半年内没有任何 Issue 活动的项目，直接归档。
• 迁移时只带活跃项目，不需要复杂的休眠确认流程。

取舍：小团队的核心约束是时间。所以不要追求完美清理，只要确保迁移清单里不包含明显的垃圾项目即可。

2. 100 到 300 人的成长型团队

这是僵尸项目的重灾区。这类团队通常经历过多次组织调整、业务方向变动和工具试用阶段，Jira 里的项目容易膨胀到 150 到 400 个。

行动建议：

• 必须严格按照我前面讲的五步流程来执行。
• 尤其注意休眠项目的确认机制，因为这个阶段“可能还要用”的错觉最强烈。
• 在 PingCode 侧提前建好归档空间，给业务方一个安全感，“不是删了，是换个地方存着”。

取舍：这类团队最难的是内部协调。建议由研发总监或技术 VP 出面拍板，否则业务线之间扯皮能拖一个月。技术上没有难度，难的是一把手的态度。

3. 500 人以上的大型组织

大型组织的 Jira 实例往往已经运行 5 年以上，项目数量可能在 500 到 2000 个之间。这类迁移通常伴随着 Jira Server 停售、合规审查、国产化替代等多重背景，迁移本身已经是一个复杂度极高的工程。

行动建议：

• 不要试图一次清理干净。分批次进行：先清理确信且无争议的僵尸项目（占总量 40% 左右），然后在迁移过程中逐步处理边界案例。
• 引入审计部门或合规部门背书，确保归档方案满足数据保留政策（比如至少保留 3 到 5 年）。
• 考虑使用 PingCode 的私有化部署方案，将归档数据放在本地存储，降低数据外迁的合规风险。

取舍：大型组织的核心约束是合规和流程。清理动作必须留痕、可追溯、有审批。不能只是 Jira 管理员一个人拍脑袋删项目，需要走正式的变更管理流程。但必须有人推动这件事启动，否则一年后还在原地讨论。

七、常见反对意见的逐一拆解：我在客户现场被怼过的那些话

这两年我在迁移项目现场被怼过无数次，以下是几个最高频的反对意见，以及我实际验证过的回应。

1. “我们 Jira 里每个项目都有用，没有僵尸。”

回应：一般说出这句话的人，已经有至少一年没有完整看过项目列表了。我的做法是不争辩，直接当面拉出 Jira 项目列表，按“最后更新日期”倒序排列，屏幕投到大屏上。通常拉到第三页，对方就不再说话了。

事实比辩论有用。统计数字不会骗人。

2. “万一删错了怎么办？你负责吗？”

回应：所以我没有说“删除”，我说的是“归档”。Jira Backup Manager 导出的文件在 NAS 上至少保留 12 个月，PingCode 侧的知识库归档页设置只读。你的数据从头到尾没有消失过。

而且退一步讲，如果一个项目归档了 12 个月都没有任何人来问过，你觉得它真的是“万一”会用到的吗？

3. “现在没时间，迁移完后我们再慢慢清理。”

回应：这是我听过最贵的借口。迁移完以后，业务团队第一时间要做的是上手新系统、跑通新流程、适应新的操作习惯。在这个节骨眼上，Jira 管理员会被大量的权限工单、配置调整请求、培训支持需求淹没，根本不可能抽出时间来做清理。

事实上，我跟踪过 8 家试图“迁移后再清理”的团队，其中 7 家在一周年时依然没有启动清理工作，僵尸项目原封不动地躺在新系统里。唯一的例外是一家被年度审计逼着清理的公司，但审计的压力不是常态。

4. “清理这么多项目，业务方会闹的。”

回应：以我的经验，真正会闹的业务方，通常是那些确实还在用这个项目的团队。而对于真正的僵尸项目，往往连闹的人都没有，因为根本没有人认领。

休眠项目确认机制要设 Deadline，就是为了让那些真正在意的人主动站出来。站出来的人，你认真对待；没有站出来的人，沉默就是答案。

八、如果你已经开始迁移了怎么办：三个场景下的补救方案

如果你已经按下了迁移按钮，或者已经完成了第一轮迁移，现在看到这篇文章才意识到问题，别慌，不是没有补救机会。

1. 场景一：迁移正在进行中，但尚未完成数据校验

行动：立即暂停校验流程，回到 Jira 侧做一轮快速清理。哪怕只清理掉最明显的那批僵尸项目（最后更新超过 365 天 + 负责人已禁用），也能显著缩小后续校验范围。

直接和 PingCode 的实施团队沟通：告知哪些项目属于清理范围，请他们在 Importer 的映射表中做相应剔除。通常这个调整不需要额外费用，但需要在数据校验开始之前做完。

2. 场景二：迁移已完成，新系统已上线

行动：在新系统中建立项目归档机制。PingCode 支持对已完结或废弃项目设置只读权限并移动到归档分组，同时可以在项目名称前加 [已归档] 标签。

这一步虽然不能挽回迁移成本，但可以防止僵尸项目在新系统中继续扩散混乱。权限治理要趁热打铁，上线后的头两周是黄金窗口，再过两个月，人们就习惯了混乱，再改就更难。

3. 场景三：迁移还没开始，正在选型

行动：你还有最佳的时间窗口。把本文给你的 Jira 管理员看，组建一个 2 到 3 人的清理小组，用一周时间完成项目健康度评估和归档执行，然后再启动正式的迁移选型 POC。

一个干净的 Jira 数据源，不仅让迁移更快更省钱，更重要的是让 POC 阶段的效果展示更加聚焦在真正活跃的业务场景上，这直接影响管理层对新工具的认可度和采购决策速度。

九、总结：迁移是一场搬家，不是一场考古

做了这么多年研发工具迁移，我越来越清晰地意识到一件事：迁移 Jira 是对研发资产的一次战略盘点，而不是一次盲目的数据搬运。

僵尸项目本质上是一种组织债务。它和代码里的技术债一样，平时你不觉得疼，但当你需要进行大规模系统变更的时候，比如迁移到 PingCode，这笔债会一次性找上来，要你用时间、预算和团队耐心来偿还。

如果你现在正在考虑从 Jira 迁移到 PingCode，我建议你下一个动作不是联系销售，也不是申请 POC，而是打开你的 Jira 项目列表，按“最后更新日期”排个序，拉到最下面，看看到底有多少项目沉睡在那里。

然后问自己三个问题：

• 这些项目，我真的打算把它们带进新系统吗？
• 带进去之后，谁负责维护它们？它们的目标是什么？
• 如果答案是不确定，为什么不在迁移之前处理掉？

如果这三个问题你都有了答案，那你已经知道自己该怎么做了。