从 Jira 迁移到 ONES 之前，先做一道算术题：附件总数 × 3.2%_服务软件

如果你们团队还在用 Jira 跑研发流程，今年大概率被"换工具"这件事折腾过。这一波不是因为国产工具突然变香了，而是 Jira 自己的窗口在关闭，而不少公司的候选名单里，都出现了 ONES 这个名字。

选型不是今天的主题。这篇只聊一件更容易翻车的事：迁移。先看一组最近复盘里的数据：有人统计了 17 起迁移事故，只有 2 起是工具本身的 bug，剩下 15 起全指向导出策略盲区和验收定义的低估。知乎也就是说，大多数团队迁移翻车，不是翻在"工具不行"，而是翻在"数据没搬对"。

时间线已定，账单不便宜

先把 Atlassian 的生命周期公告摆上桌：2024 年 2 月 Server 官方支持终止，从那天起没有安全补丁；2026 年 3 月 Data Center 停止接受新客户购买；2029 年 3 月 Data Center 结束生命周期，实例转为只读。知乎自 2026 年 3 月 30 日起，新客户已经无法购买受影响的 Jira Data Center 和 Confluence Data Center 产品。知乎

再算一笔留存账。2026 年的一份成本测算里，100 人规模上 Data Center 年费约 20 到 33 万人民币，2025 年起还涨了约 23%。知乎对稍有规模的团队来说，这是一笔逐年往上走的开销。换到国产平台，多数团队能把订阅成本明显压下来，还多出私有化部署和信创适配的选项，但前提是：搬得干净。

先看 ONES 官方的迁移方案

ONES 是把"Jira & Confluence 替换"做成官方解决方案的，值得先看看它承诺了什么。官网的说法是：围绕 Jira 中的项目、工作项、状态、字段、流程、附件和历史记录进行迁移，最大程度保持研发过程连续，让团队在切换工具后快速恢复协作。ONES官网配套服务分四类：Jira 迁移、Confluence 迁移（迁入 ONES Wiki）、插件替代、信创合规。

官方把迁移服务流程拆成五个阶段：需求收集、蓝图方案、迁移演练、正式迁移、系统验收，每个阶段都有对应交付物，比如迁移方案、性能测试报告和验收报告。

但要提醒一句：以上是厂商侧口径。"无损"和"平滑"是签合同前的承诺，而那些迁移事故里，没有一家厂商在迁移前说自己搬不动。承诺可以听，验证必须自己做。

迁移真正翻车的地方

看两个真实案例。一家金融企业的 150GB 实例，走"一键迁移"，结果附件丢了 3.2%（约 4800 个文件），验收阶段没有一个人发现。知乎

另一家金融科技公司更瘆人：迁完第三天，业务团队发现少了 200 多条改动历史，包含需求变更记录、代码评审意见、测试讨论。全程没有报错、没有异常日志，直到有人去翻三个月前一次关键决策的评论链，才发现。知乎注意，这家并不草台：有专职 DevOps，做过完整导出测试，也在 staging 环境跑过验证。

为什么"验收通过"还是会丢数据

因为大部分人验收时的动作是对条数。Issue 数量对得上、项目数量对得上，就算过关。可静默丢掉的，恰恰是 Issue 里面的东西：附件字节、评论链、变更历史、字段间的上下游关联。最容易漏的检查动作就在这儿：验收时大部分人查的是"条数对不对"，不是"内容对不对"。知乎条数验证的是外壳在，内容验证的是证据链在，而研发管理里值钱的往往是后者。

最容易丢的变更历史、评论链、需求关联，恰恰是丢了最难补的。在 ONES 里，这类信息是这样被承载的：每个基线版本留快照，需求变更给出差异高亮，影响分析直接列出受影响的下游对象，设计、任务、测试、发布串成一条链。

这张图不是功能宣传，是给你一个验收参照：迁移完成后，别只看需求"条目"在不在，还要看这种"关系和历史"的链条还连不连得上。

签合同前要做的四件事

第一，盘点现状。迁移前要统计项目数量、用户数量、工作项类型、自定义字段、工作流、权限方案、自动化规则、插件、附件规模和历史数据范围。知乎这份清单就是你验收的基线，不盘点，后面无从核对。

第二，用一个真实项目试迁移。选活跃度适中、带自定义字段、评论、附件和关联关系的项目完整迁一遍，逐项核对工作项数量和关键字段，别拿销售演示当依据。

第三，在试用环境跑一次真实迭代。用 WBS 拆需求、挂依赖关系、标里程碑，看甘特图和关键路径能不能扛住真实的排期变动，再把需求评审、开发、测试、缺陷修复完整走一遍。

第四，问清免费人数之后的报价。ONES 团队版面向 50 人及以下免费使用，包含 ONES Project、ONES Wiki、ONES TestCase，适合先用较低门槛把试点跑起来。知乎但超过免费人数后企业版怎么报价、私有化部署怎么收费，要在签合同前落到纸面上，这是最容易被含糊过去的一环。

验收标准与执行节奏

验收动作上，有一套现成做法值得直接写进合同：导出完整 XML 备份加附件 MD5 清单；迁移后随机抽检 10% 的 Issue，逐个看附件、评论、时间轴；旧系统保留只读 30 天当后悔药；别信"100% 迁移"，把数据完整性条款和赔付方案写进合同。知乎

执行节奏上，建议按四步走：数据试迁移、流程重建、系统集成、并行运行。最关键的是最后一步：新旧系统同时运行一个或两个完整迭代，确认权限、报表和实际操作没有明显问题后，再冻结旧系统写入。知乎

对需要长期审计的企业，还可以保留 Jira 只读环境或导出关键历史数据，新平台上线后立即删除全部旧系统数据并不合适。知乎

另外，流程重建不是机械复制：把 Jira 里的状态和流转规则映射到新平台时，顺手删掉早已失效的流程。把历史包袱原封不动搬进新系统，是仅次于丢数据的第二大浪费。

哪些团队先别急着换

说句实在话：不是所有团队都该现在换。国产工具与 Jira 的差距是客观存在的：自动化规则大多只支持 3 到 5 个步骤，复杂嵌套做不了；插件生态最直白，Jira Marketplace 几千个，国产应用市场不到 100 个。知乎如果你们深度依赖某个特定 Jira 插件，或者有极复杂的嵌套自动化链路，别硬换，观望也是一种策略。

反过来，如果你们的使用以需求、任务、缺陷、迭代这些核心场景为主，能接受"主流程覆盖＋部分自行折腾"，私有化、信创、中文服务又是硬要求，那这一轮替代值得认真评估。