Atlassian Forge Migration Accelerates with AI

The Connect-to-Forge migration story has been running for years. Atlassian announced the deprecation direction, vendors dragged their feet, deadlines shifted, and most admins quietly stopped tracking it. Now Atlassian is pushing AI-assisted tooling to help vendors move faster. That's worth unpacking — not from a vendor-cheerleading angle, but from the ground: what does this actually mean for the apps sitting in your Jira instance today?

Why Connect-to-Forge Still Matters for Admins

Connect is the older Atlassian app framework. Apps built on it run on the vendor's own infrastructure, communicate with Jira via webhooks and REST, and declare permissions through a JSON descriptor that Jira enforces at install time. It works, but the trust model puts a lot of faith in the vendor's server security. Your Jira data flows out to someone else's endpoint.

Forge is Atlassian's hosted runtime — apps execute inside Atlassian's own infrastructure, in sandboxed functions, with tighter permission scopes and no vendor-owned server in the request path for most operations. For admins, that difference is material: fewer external egress points, Atlassian-managed execution environment, permissions that are harder for a vendor to silently expand.

From a security posture standpoint, a Forge app is easier to trust than a Connect app. That's not an opinion; it's the architecture. Atlassian's Cloud Fortified program already weights Forge migration as a factor in vendor assessments.

What Atlassian Is Actually Proposing

Atlassian published guidance this week on using AI tooling to speed up the Connect-to-Forge migration process. The pitch is straightforward: the mechanical parts of migration — translating API calls, rewriting module declarations, adapting authentication flows — are repetitive enough that LLM-assisted code transformation can handle a meaningful chunk of them.

This is not a magic button. It won't port a deeply stateful Connect app with a bespoke data model to Forge in an afternoon. But for apps with a reasonably clean separation between business logic and Atlassian integration code, AI-assisted refactoring reduces the time cost enough that vendors who've been deferring migration have less excuse.

The practical implication: the pace of Forge adoption in the Marketplace vendor ecosystem is likely to accelerate over the next 12–18 months. Apps that were stranded on Connect due to rewrite cost will start moving.

How to Evaluate the Apps in Your Instance Right Now

If you're a Jira admin with a mature install — 10+ Marketplace apps, some of them years old — it's worth running a quick audit:

• Check the framework for each app. The Atlassian Marketplace listing doesn't always surface this prominently, but the app's security tab and permission descriptions give signals. Apps with broad network egress permissions and listed external domains are almost certainly Connect-based.
• Cross-reference vendor activity. A Connect app from a vendor that hasn't shipped a release in 18 months is unlikely to migrate on its own. The migration effort requires active engineering investment, even with AI assistance.
• Ask vendors directly. If an app is material to your workflows, raise a support ticket asking about their Forge migration roadmap. The quality and specificity of the answer tells you a lot about whether there's a real maintainer behind it.

The risk isn't that Connect apps stop working tomorrow. Atlassian hasn't published a hard shutdown date. The risk is accumulating a portfolio of apps that are locked to an older trust model, maintained by vendors who've implicitly abandoned the migration work, and therefore unlikely to ever gain the security posture improvements that Forge enables.

La Forge's Position on This

Both of La Forge's apps — Multiple Assignees and Merge Assistant — are built on Forge. That wasn't an accident or a late retrofit; it was a deliberate call made at the outset, before the migration tooling existed, because the security architecture was the right one for apps that touch issue data in a production Jira instance.

Building on Forge natively is harder than starting on Connect. The execution model is different, local development is more constrained, and some Jira APIs that have been available to Connect apps for years are still being ported to Forge-native equivalents. We've hit those gaps. We've worked around them or waited for Atlassian to close them. The tradeoff is worth it because the result is an app that doesn't require an admin to route Jira data through an external server to function.

The AI-assisted migration tooling Atlassian is now promoting doesn't change our situation — we're already there. But it does matter to admins evaluating the Connect apps currently in their environment.

What to Watch For

A few signals worth tracking as this plays out:

• Cloud Fortified badge tightening. Atlassian has periodically raised the bar for what Cloud Fortified requires. A stronger push toward Forge could eventually make Connect-only apps ineligible. Watch the Cloud Fortified requirements page for updates.
• Marketplace search ranking. Atlassian has levers to surface Forge-native apps in search results. They haven't used them aggressively yet, but the direction is clear.
• Vendor migration announcements. If a large vendor moves a high-profile Connect app to Forge, that signals the tooling is viable and sets a precedent that smaller vendors will feel pressure to follow.

The Connect-to-Forge migration isn't a crisis — it's a slow structural shift. But slow structural shifts are exactly the kind of thing that bites an enterprise Jira deployment when no one's been watching. Now is a reasonable time to look at your Marketplace app inventory with this lens and decide which vendors you're going to follow up with.