Atlassian Data Center 今日起停新客，退出周期正式开始。

一、3 月 30 日：退出周期正式落地的起点

根据 Atlassian 官方路径，2026 年 3 月 30 日，Atlassian Data Center 面向新增客户的入口正式关闭，退出周期由此进入实质落地阶段。从今天起，新客户已无法购买新的 Data Center 订阅及新的 Marketplace Data Center 应用。

Atlassian 给出的退出路径其实很清楚：

2026 年 3 月 30 日停新客，关闭新增客户入口；

2028 年 3 月 30 日停现有客户的新增、停扩容，收紧现有客户的主动空间；部分特殊场景可以申请例外性的延长维护，但不改变整体终点；

2029 年 3 月 28 日，数据中心服务终止。所有数据中心许可证及相关的应用市场许可证将到期并转为只读模式。

来源：Atlassian 官网

企业真正需要看懂的，不只是这几个时间点本身，更是它们背后的含义。

2026 年关掉的是入口，意味着 Data Center 已不再是新增客户的未来路线；

2028 年收紧的是扩展空间，意味着依赖新增许可、应用和扩容来承接增长的路径会被打断；

2029 年到来的则是终局，意味着问题不再只是“还有没有支持”，而是这条路线还能不能继续承担长期协作底座的角色。

对仍在使用 Jira/Confluence DC、仍在评估本地部署的企业来说，这已经足以构成一次需要重新判断的信号。

二、为什么真正的决策窗口不是 2028，而是现在

很多企业看到 Atlassian Data Center 的官方时间线，第一反应会是：真正的终点在 2029，现有客户新增许可、应用和扩容的截止时间在 2028，那是不是意味着至少还能再观察一两年？

问题恰恰在这里。

如果只看官方终点，而不看许可机制和企业内部决策周期，就很容易高估自己还拥有的准备时间。

也正因为如此，2028 并不是很多企业真正的起点，现在才是。

如果企业到 2028 年才开始正式讨论方案，看起来似乎还没到终点，但实际上，留给调研、预算、立项、试点、内部共识和迁移实施的空间已经非常有限。对中大型组织来说，系统路线的调整从来不是一个“最后几个月集中完成”的动作。

2026—2027 的意义，不在于它是官方写出来的某个硬节点，而在于它很可能是企业最后一个还能相对从容启动正式项目的时间窗口。

对仍在增长、流程较复杂、集成较深的组织来说，真正需要改变的，不是对终点的认知，而是启动判断的时间。

三、3 大结构性风险：真正需要重估的，不只是续费问题

对很多仍在使用 Jira/Confluence DC 的企业来说，现在真正需要重估的，已经不是一个简单的“续不续费”问题，而是至少三类更深层的结构性风险。

第一，是扩容风险

很多团队最容易陷入的一种误判是：只要系统今天还能用，问题就还不紧迫。

但对仍在扩团队、扩项目、扩协作边界的组织来说，真正的关键不是“今天能不能用”，而是未来两三年还能不能继续按原来的节奏承载增长。Atlassian 官方已经明确，现有客户新增许可、应用和扩容的窗口只到 2028 年 3 月 30 日，这意味着过去依赖扩容承接增长的路径不会无限期延续。

很多企业买到的，并不是一条“无限弹性、随时可扩”的容量路线，而是一个按用户规模划分的许可区间。Atlassian 官方采购与许可规则已经明确，Data Center 支持按用户档位升级。也就是说，当组织规模、使用人数和协作范围持续扩大时，企业往往需要通过档位升级来承接，而不是无限制地平滑扩展。

换个更直观的说法，这其实就是一个“容量桶模型”：企业当前处在某个容量区间内，团队增长、项目增加和协作范围扩大，都会不断逼近边界；而一旦现有客户新增许可、应用和扩容窗口关闭，过去依赖继续升级来承接增长的路径就会被打断。对仍在增长的组织来说，这不是一个采购细节，而是系统承载问题。

第二，是成本风险

很多企业第一反应是续费价格，但真正需要重估的，从来不是某一年的采购金额，而是未来几年的 TCO，也就是总拥有成本。

对 DC 用户来说，后面真正要算的账，至少包括六部分：主产品许可、插件成本、基础设施投入、运维与维护人力、迁移或替代的一次性项目成本，以及流程重建、权限调整、集成改造、培训适配等组织切换带来的隐性成本。

尤其值得注意的是，Atlassian 官方已明确，Data Center EOL 不只影响主产品，也影响 associated Marketplace apps；同时，Atlassian 也已停止接受新的 Data Center 应用提交，并按时间表逐步收缩相关生态。

这意味着很多企业后续面对的，不会只是主系统价格变化，而是主产品与插件生态同步变化后的整体成本重估。

企业真正需要比较的，不再是“今年续不续费”，而是三条路径未来 3 到 5 年的总成本到底谁更可控。如果不把这些成本放到同一张表里看，企业就很容易低估后续几年路径切换的真实投入。

第三，是生命周期风险

这次 Data Center 的终局，和过去 Server 停止支持并不相同。过去大家容易形成一种经验：厂商不支持了，系统未必不能继续跑；但这次 Atlassian 在官方 EOL 页面写得更明确，受影响的 Data Center 产品及其关联应用，在 2029 年 3 月 28 日到期后将变为只读。

这意味着企业要面对的，不再只是“厂商还支不支持”，而是“这套系统还能不能继续作为一套正常运行的生产协作底座”。

当一条路线的终局已经从“停止维护”被定义为“到期只读”，它带来的就不再只是技术层面的不确定性，而是组织级的生命周期治理问题。

只有把扩容、成本和生命周期这三类问题一起摆到桌面上，企业才会真正理解，为什么这次变化已经不适合再用“续不续费”这么简单的方式来讨论。

四、企业接下来无非三种选择

当时间线、许可机制和结构性风险都摆到桌面上之后，企业真正要面对的问题就变得很直接：接下来到底怎么选。

从现实看，大多数仍在使用 Jira DC 的企业，后面无非三种路径：继续维持、迁往 Cloud、主动替代。不同企业会有不同答案，但无论选择哪一条，前提都不是情绪判断，而是先把时间窗口、承载边界和总成本算清楚。

第一种，是留

继续维持现有环境，把最后的准备时间尽量用足。这条路径适合短期内变化不大、组织规模相对稳定、希望延后切换、先把内部盘点和预算准备做完整的团队。对这类企业来说，“留”并不等于长期不动，而更像是一种阶段性策略：先利用 2026 到 2028 之间仍然存在的缓冲空间，把现状盘清楚、把风险看清楚、把后续方案准备好。

但这条路径的前提也很明确：企业必须清楚自己是在“争取时间”，而不是“继续默认沿用”。

如果团队规模还在增长、插件依赖还在加深、跨系统集成还在变复杂，那么“留”就只能是一个过渡动作，很难再被当成长期答案。

第二种，是上 Cloud

这个方向是原厂主推路线，也是 Atlassian Ascend 持续推动的核心目标。整体信号已经很明确：Atlassian 未来的重心正在持续向 Cloud 收拢。

但对国内大部分企业而言，这条路径通常很难进入重点考虑范围。

一个必须正视的现实是，Atlassian Cloud 目前并不提供中国区本地数据驻留能力。这意味着，对于很多重视数据本地化、审计边界、部署位置和合规要求的中国企业来说，一旦涉及数据出境，这条路径往往会在评估阶段被优先排除。

对这类企业而言，这已经不是一个单纯的产品选择问题，而是数据安全与合规边界问题。

第三种，是主动替代

对于重视本地部署、自主可控和长期稳定的企业来说，主动评估替代方案会越来越现实。

对这类企业而言，真正要看的，并不是“有没有一个能立刻一比一复制 Jira/Confluence 的工具”，而是：有没有一条更适合未来几年发展的协作底座路线，既能承接研发、项目、测试、知识沉淀等核心场景，又能满足本地部署、权限控制、持续演进和本地化支持等实际需求。

这样一来，主动替代就不再只是为了应对一次政策变化，而是在窗口仍然存在时，重新把系统选择权握回自己手里。

在这一背景下，像 PingCode 这样的本土研发管理方案，会更自然地成为国内企业优先考虑的选择。因为真正有价值的替代路径，从来不只是“换一个工具”，而是能否提供更符合本地部署诉求、更稳定的产品演进节奏、更清晰的数据迁移方案，以及更贴近国内研发团队使用习惯的协作体系。

三种路径本身没有绝对的标准答案。

真正的区别在于：“留”是在争取时间；“上 Cloud”是在顺着原厂路线继续走；“主动替代”是在重新选择未来几年的协作底座。

五、现在更需要的，不是更多观点，而是决策工具

对仍在使用 Jira / Confluence DC、并正在评估后续路径的团队来说，现在真正需要的，已经不是更多观点，而是一份可以直接用于内部评估的决策材料。企业要面对的，也不只是一次公告变化，而是对时间线、许可边界、扩容风险和路径选择的重新判断。

我们整理了《Jira Data Center 生命周期终局白皮书》，围绕退出时间线、许可机制、扩容封顶模型、结构性风险和三种决策路径，把“要不要动、什么时候动、往哪条路走”这几个核心问题拆开说明，欢迎前往PingCode 公众号下载。白皮书目录如下：

对仍在使用 Jira / Confluence Data Center、未来 2 到 3 年仍会增长，并需要在“继续使用 / 上 Cloud / 主动替代”之间做判断的企业来说，越早把这些问题纳入正式评估，后续的选择空间通常也越大。