Atlassian Connect 于 2027 年 1 月 31 日终止支持：把定制的 Jira 和 Confluence 应用迁移到 Forge

2027 年 1 月 31 日，Atlassian 将终止对 Connect 的支持，而大多数较老的 Jira 和 Confluence Cloud 应用都是基于这个框架构建的。从那天起，Atlassian 表示它“只会处理 Connect 中的严重安全漏洞”，而仍运行在 Connect 上的私有应用“将不再受支持，并可能无法正常工作”。

如果您站点上的每个应用都来自 Atlassian Marketplace，这就是厂商的事，而且大多数厂商已经做完了：Atlassian 在 2026 年 8 月报告说，“超过 95% 的付费应用席位已迁移到 Forge”。

本文写给另一种情况。贵公司有一个专门为您开发的 Jira 或 Confluence 应用：出自内部开发人员、外包人员或合作伙伴之手。它是通过链接安装的，不是买来的。公司以外没有人会去迁移它，而写它的人可能也已经不在了。

终止支持意味着什么，不意味着什么

没有公布任何关停日期。Atlassian 没有说 Connect 应用会在 2027 年 2 月 1 日停止运行，它最初的时间表公告还说，“已安装 Connect 应用的客户不会失去对应用的访问权限”。

不要把这理解为安全。变化在于，Atlassian 不会再有人照看 Connect：

• 只修复严重安全漏洞。非严重的缺陷会一直留着。
• “Connect 功能的弃用将在几乎没有预先通知的情况下发生。”
• Atlassian 支持团队“将无法修复由这项旧技术引起的问题”。
• 用 Atlassian 自己的话说：“Connect 在终止支持后不会保持稳定状态。故障会增加，兼容性缺口会扩大。”

所以风险是逐渐显现的，而不是一道悬崖。一种很可能出现的故障：Jira 改了某个页面，一个 Connect 面板不再渲染，而您找不到任何人提工单。如果那个应用嵌在财务审批流程或面向客户的服务台中，您会从依赖它的人那里听说这件事。

已经发生了什么

1 月这个日期，是始于 2025 年的一系列步骤中的最后一步。

• 2025 年 9 月：Marketplace 停止接受新的 Connect 应用。
• 2026 年 3 月 31 日：更新冻结。Atlassian 的定制应用指南说得很直白：在那个日期之后，“您将无法再向 Connect 应用推送更新”。您自己服务器上的代码仍然可以修改，但应用向 Jira 或 Confluence 声明的内容（其模块、作用域和 webhook）已经固定。
• 2026 年 3 月：时间表还说，“通过 Connected Apps 安装新的 Connect 私有应用的功能将不再可用”。把卸载当作单向操作：不要为了看看会坏什么而移除一个私有 Connect 应用。
• 2026 年 8 月：Atlassian 把终止支持的日期从 2026 年 12 月推迟到 2027 年 1 月 31 日。只多了一个月。不要指望还会再推迟。
• 现在：Atlassian 正在 Atlassian Administration 中逐步推出警告，仍在 Connect 上的私有应用会被“标记为 LEGACY 状态”。

找出您的私有应用

从 Atlassian Administration 的 Connected Apps 页面开始。任何标为 LEGACY 的应用都运行在 Connect 上。Atlassian 给出了识别私有应用的检查清单：如果以下大部分都成立，那就是您要迁移的应用：

• 通过直接链接或开发者模式安装，而不是从 Marketplace 安装；
• 在 Marketplace 搜索中看不到；
• 源代码由您的组织维护；
• 没有许可信息，并且安装列表中只有您的组织；
• 它的 Connected Apps 页面上没有相关链接侧栏（Marketplace 应用有）。

Atlassian 还补充了一条经验法则：五年多以前构建的定制云应用很可能是 Connect 应用，而 Connect 应用托管在 Atlassian 之外，“通常在 Heroku、AWS、Azure 或 Google Cloud Platform 之类的服务上”。应用的 View app details 链接会显示 Atlassian 所知的开发者是谁。

对每个应用，在任何人动代码之前，先写下五件事：

1. 它做什么、谁在用，用一句业务负责人能看懂的话写。
2. 源代码在哪里。 一个您控制的代码仓库、某个外包人员的笔记本电脑，或者哪里都没有。
3. 它运行在哪里，托管费用由谁的账户支付。 如果服务器挂在某个前外包人员的云账户上，那是今天的风险，而不是 1 月的。
4. 描述符。 每个 Connect 应用都在一个 URL 上提供一个 atlassian-connect.json 文件。它列出了应用使用的每一个模块、作用域和 webhook，这使它成为您能拿到的最可靠的清单。
5. 它保存了哪些数据，保存在哪里：在它自己的数据库中，还是在 Jira 事务和 Confluence 页面上存储的属性中。

先决定，再动手

不是每个私有应用都值得迁移。Atlassian 自己的建议是：先看看 Jira 或 Confluence 的原生功能现在是否已经能完成这项工作，只迁移组织仍然需要的东西。旧应用填补的空白，往往产品后来已经补上了。

每个应用会得到三种答案之一：迁移、用受支持的东西替代，或者停用。停用是一个合理的结果。Atlassian 建议，如果您要放弃一个应用，就通知其用户，并在 2027 年 1 月 31 日之前安排移除，而不是任由它自己出故障。

迁移到 Forge 涉及什么

Forge 不是换了名字的 Connect。托管模型、安全模型和界面模型都不同，这也是为什么 Atlassian 告诉即使是简单应用的所有者，也要尽早启动概念验证。

托管

Connect 应用是一个由您运行的 Web 服务。Forge 应用作为函数运行在 Atlassian 的基础设施上，并有硬性限制：用户触发的函数 25 秒，异步事件和定时触发器最长 900 秒。一个让用户等着跑十分钟同步的 Connect 应用，必须把这项工作移到异步事件中，而任何超过十五分钟的工作都必须拆分成多个步骤。出站调用也受到限制：任何未在应用清单中声明的域名都会被拒绝。

保留您现有的后端

Forge Remote 让 Forge 应用可以调用您托管在别处的服务，让您的服务器可以核实请求确实来自 Forge，并为您的后端提供调用 Atlassian API 的令牌。对于一个服务器上积累了多年业务逻辑的私有应用，这往往是更短的路线：界面和集成点迁到 Forge，逻辑留在原处。

代价是：Forge Remote 可能使应用失去 Atlassian 的 Runs on Atlassian 计划资格。对内部工具来说这没那么要紧，但您的安全团队应该在知情的情况下接受这一点。

身份验证和权限

Connect 应用使用以共享密钥签名的 JWT 进行身份验证。Forge 用清单中声明的 OAuth 2.0 作用域取而代之；对于远程后端，则由您的服务器验证一个 Forge Invocation Token，而不是 JWT。

之后，每一次对 Jira 或 Confluence API 的经过身份验证的调用，要么以 asUser 方式进行，使用当前使用应用的那个人的权限，要么以 asApp 方式进行，用 Atlassian 的话说，这种方式“无论谁在使用应用”都有效。逐个检查每一次调用并有意识地做出选择，是整个迁移中最重要的一次安全审查。

有一个差异常常让团队措手不及。Connect 模块默认会对无许可证用户和匿名用户渲染；Forge 模块则不会，除非清单通过 unlicensedAccess 明确选择开启。如果您的应用向服务台客户或 Confluence 的匿名读者展示任何内容，就单独测试这条路径。

用户界面

Connect 页面是 iframe，通过 Atlassian 的 JavaScript API 与 Jira 或 Confluence 通信。Forge 给了您两个选择：

• UI Kit：一个基于 React 的框架，渲染原生的 Atlassian 组件。快速且一致，但您只能用 Atlassian 的组件来构建：自定义 HTML 可能无法使用，它接受的静态资源只有图片。
• Custom UI：在 iframe 中运行您自己的 HTML、CSS 和 JavaScript，通过 @forge/bridge 与产品通信。

现有的 iframe 前端，迁到 Custom UI 通常改动最少。小面板和设置界面，用 UI Kit 重做往往更快。

数据

迁移就是在这里出问题的。Forge 有自己的托管存储：一个键值存储、一个自定义实体存储、Forge SQL，以及一个处于预览阶段的对象存储。数据按安装实例隔离，并与宿主 Jira 或 Confluence 站点存放在同一位置，所以无需额外配置就能满足数据驻留要求。

这对私有应用意味着：

• Connect 应用自己数据库中的数据，要么通过一次性的迁移任务移入 Forge 存储，要么留在原处，通过 Forge Remote 访问。
• Connect 应用以自己的应用密钥（app key）存储在 Atlassian 一侧的任何东西，都应该趁旧应用还在运行时导出。尽早测试新应用能否读取这些数据；不要想当然。
• Forge 在卸载后会保留托管数据 28 天，但重新安装不会自动恢复这些数据。

把迁移写成一个可重复执行、带有可核对计数的脚本，在测试站点上演练，并保留导出文件。

增量路径，以及为什么它大概不属于您

Atlassian 为 Connect 应用设计了一条更平缓的路线：增量采用 Forge，保留现有安装，把描述符转换为 Forge 清单，一次迁移一类模块，并为宏、自定义字段和工作流校验器等部分模块提供内置的数据迁移。

问题出在指南的第一段：“Forge 的增量采用仅适用于已在 Marketplace 上架的 Confluence 和 Jira Connect 应用。”

对于私有应用，请按新建一个 Forge 应用来规划。您把它部署到生产环境，通过开发者控制台的安装链接与您的站点共享，在迁移数据和用户测试期间让它与旧的 Connect 应用并行运行，然后移除 Connect 应用。

采用指南中的模块映射仍然有用，Forge 中不提供的 Connect 功能清单也一样：若干 Jira Service Management 模块和移动应用支持被标为不在计划内，jiraReports 仍在考虑中。在第一周就用这份清单核对您的描述符。那里有缺口，就会改变设计。

从 2027 年 1 月 31 日倒推的计划

从 2026 年 10 月初算起，大约还剩十七周，而 12 月对谁来说都很短。一个站得住的计划：

1. 本周：列出每一个 LEGACY 应用，附上上面那五项信息。确认谁控制着源代码和托管账户。
2. 10 月中旬之前：为每个应用决定迁移、替代还是停用。通知所有将被停用的应用的用户。
3. 10 月底之前：针对最难那个应用中最难的部分，做一个 Forge 概念验证。通常是一个在 Forge 中没有直接对应的模块，或者保存数据最多的那个模块。
4. 11 月：开发，并在测试站点上多次运行数据迁移。
5. 12 月上旬：把 Forge 应用与 Connect 应用并排安装，迁移一份数据副本，让每天使用它的人检查。
6. 2027 年 1 月：最终迁移，把用户切换过去，并且只在新应用平稳运行一段时间之后才移除 Connect 应用。

一个只读取 Jira 数据、什么都不保存的面板，是个小活。一个有自己的数据库、工作流规则以及与其他系统链接的应用，这几周每一周都用得上。

如果您错过了这个日期，Atlassian 公布的任何内容都没有说应用会在那一天停止运行。但那时您就是在一个所有者已经不再修复的平台上运行业务流程。把那段时间当作借来的时间，并把迁移做完。

当原开发者已经不在时

Atlassian 直接谈到了这种情况。如果您无法确定或联系到应用的原所有者，或者已经没有开发能力，它建议聘请一家 Solution Partner。它同样明确地指出，如果没有源代码，“可能需要在 Forge 上从头重建”。

即使没有源代码，您也不是两眼一抹黑。描述符列出了应用接入的所有东西，它的行为可以在测试站点上观察，而如果服务器费用由贵公司支付，您可以看到实际部署的是什么。用这些碎片重建，比移植要慢，但它是一个可以估量的工作。

从哪里获得帮助

我们接手当前团队里没人写过的代码，弄清它到底在做什么，然后把它迁移出去：对于一个 Connect 应用，这意味着阅读描述符和服务器代码、构建 Forge 应用，以及编写和演练数据迁移。这项工作通常从我们的遗留系统维护开始；如果您有开发人员但人手不够，人员增补可以在项目期间为您的团队补充人员。告诉我们这个应用做什么、运行在哪里：请写信到 office@c9group.dev。