Connect vs Forge - What’s Really Going On?

[#1]

If you’re new to the Atlassian ecosystem, terms like Connect and Forge can sound confusing.

Simply put, both are frameworks for building apps within Atlassian products.

• Connect is the older framework. It allows developers to host their apps externally and connect to Atlassian via APIs.

• Forge is the newer framework. It allows developers to build apps that run natively on Atlassian’s infrastructure.

Connect helped power the Marketplace for years. It worked well. So why phase it out?

In my opinion, it comes down to regulation, security, and control.

Atlassian has been steadily moving toward tighter security, compliance, and enterprise-grade governance. We saw this with the shift away from Server, and now with Data Center’s announced end-of-life in 2029. Enterprise customers especially those in regulated industries demand stronger security guarantees before committing fully to cloud environments. Forge is Atlassian’s answer to that demand.

Migration Is Never “Just a Move”

Migration is not like relocating from one country to another. Even that requires planning: where you’ll live, what the environment is like, what changes to expect.

Now imagine migrating a software platform serving 10,000+ users.

It requires:

• Architectural planning

• Data validation

• Testing

• Permission mapping

• Performance considerations

• Security reviews

There is nothing straightforward about migrating an Atlassian product.

Where Should You Start?

If you’re thinking about migration, you’ve already accepted the reality that change is coming even if you’re frustrated by it.

The good news: there are solution experts and partners who specialize in this work. Just like not everyone builds roads or skyscrapers, not everyone needs to manage a complex migration alone.

The real challenge is not “how do we migrate?”
It’s: what should we change while we migrate?

Migration is also an opportunity to clean up architecture, remove technical debt, and rethink workflows. The rest can be solved through structured testing and iteration.

Why Forge Exists

Back to Connect and Forge.

Atlassian’s timing around deprecations can sometimes feel abrupt. But the long-term strategy is clear: focus on security, reliability, scalability, and trust.

Enterprise and regulated customers require:

• Stronger compliance guarantees

• Controlled execution environments

• Native integration within the Atlassian suite

Connect apps run externally. That flexibility was powerful but it also limited Atlassian’s control over security and infrastructure consistency.

Forge changes that.

With Forge:

• Apps run on Atlassian infrastructure

• Authentication is handled for you

• Security boundaries are enforced

• Permissions are centralized

Forge makes apps feel native to the Atlassian ecosystem.

My Experience: Migrating 3 Apps to Forge

I migrated three Connect apps (with Python backends) to Forge (Node.js) within one month. The motivation? A deadline from Atlassian indicating my apps risked disconnection from the Marketplace if not migrated.

That puts things into perspective very quickly. Six months may sound like enough time, but depending on app complexity, it can be tight. Regardless, the expectation is clear: migration must happen. So I dove deep into Forge.

The Forge Framework - Credit Where It’s Due

Forge is surprisingly good. Atlassian truly delivered on:

• Enterprise-grade security

• Authentication infrastructure

• Compliance foundations

Since it’s JavaScript-based, learning the modules was quick. The bigger learning curve involved:

• Understanding authentication flows

• Learning FIT tokens

• Working within Forge limitations

• Managing scopes and impersonation

But once that clicked, things moved fast.

The biggest benefit?
Atlassian handles authentication and infrastructure security.

That alone removes a massive development burden.

What to Watch Out For

Here are practical lessons from migrating:

1. UI Kit vs Custom UI

If your Connect app used Custom UI, stick with Custom UI in Forge.

UI Kit is limited and not very customizable. Trying to force complex UI into UI Kit can waste weeks.

2. asUser() vs asApp() vs Impersonation

• asApp() runs as the app itself.

• asUser() runs as the currently logged-in user.

• asUser(accountId) allows impersonation.

If you need impersonation, you must declare: allowImpersonation: true in your permission scopes. 

Some actions (especially around installation timing or restricted endpoints) won’t work with asApp() alone.

3. Custom UI Rendering Gotcha

For Jira modules like jira:globalPage, if you're using Custom UI:

Your render key should be: render: default Anything else can cause the app not to load correctly.

4. Schedules, Queues, and Consumers

Forge allows you to:

• Use schedules to trigger queues

• Use queues to trigger consumers

• Chain execution flows

This is powerful when building background processing systems.

5. Avoid Forge tunnels

If you can, please avoid Forge tunnels, instead use the console.log and view it from your Atlassian developer console. There are so many problems that could be happening within the app such as prolong caching after you've updated your app which don't reflect immediately, to errors occurring on something random and you don't know why. 

The Bigger Picture

I rebuilt everything:

• Queues

• Notifications

• Templates

• Storage

• Caches

• Schedulers

• Authentication flows

All in Node.js.

Moving from multiple languages to one simplified the architecture significantly.

Was it stressful? Yes.
Was it worth it? Also yes.

Forge removes the hardest part of building secure SaaS apps:
Authentication and infrastructure security.

You still manage permissions and validations but the foundation is handled for you.

And that changes everything.

Final Thoughts

Migration to Forge may feel like a burden at first. But once you understand the framework, you realize: You can build almost anything securely, natively, and at scale.

If this helps any developer in the ecosystem, great. And if you’re migrating from Connect to Forge and have questions reach out.

[Prasanna Ravichandran]

Thanks for sharing! As I am new to this community, this update is really helpful.

[James Rickards _SN_]

Is there an announcement that I missed that the Rest API's are going to be deprecated?  I use them extensively for data exports for data achieve and backup. Backups/Archive is all about getting data outside of the Atlassian ecosystem.  I don't see Forge being appropriate for that purpose.

[Prince Nyeche]

@James Rickards _SN_ Forge is the new power house for everything apps related. Older APIs will be gone to make way for the newer technologies which will be embedded into the Atlassian API framework where applicable. In regards, to the backup API, yes that is deprecated as well and won't work. Atlassian have newer backup APIs with broader controls and features. It is a good or bad thing, only time will tell.

[James Rickards _SN_]

@Prince Nyeche

Whilst I understand Connect for apps is deprecated, there are still strong use-cases for the REST API's to exist for getting data for use outside of Atlassian's User Interface using whatever programming language you want. This is useful for quick once analysis/large scale updates where building a forge application would be a huge overkill.

Can you reference the Atlassian authored articles stating this deprecation of the entire V2 and V3 REST APIs?  I'd like to see some hard dates for our planning.  I'd also suggest you add links to your article.

Normally if an API is being deprecated it is captured in their documentation, so I'd expect to have seen this by now.  We've seen this with the recent end of support for the issue search API's, where there was significant communication prior to the fact. I have not been able to find anything stating dates as to when that they will sunset the entire V2 & V3 REST APIs.  Which makes this article seem to be misinformation or just misrepresenting the situation.

Some examples...

deprecated notes = https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-get

no deprecated notes = https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-jql-get 

I'm hesitant to believe Atlassian would end the REST APIs from being called by external services (e.g. via PowerShell scripts, used for integrations with ServiceNow).  These REST API is one of the foundational features making the product so useful to businesses. Removing it and limiting interaction to a walled garden will harm their value proposition significantly.

[Prince Nyeche]

@James Rickards _SN_ 

I think you've probably misread this article. I never stated in my article that the REST API is being deprecated. I made two clear and factual points:

1. Atlassian is encouraging vendors to move from Connect to Forge.

2. For organizations prioritizing stronger security and long-term alignment with the Atlassian ecosystem, Forge is the logical step forward.

The Atlassian REST APIs remain available and fully supported. Historically, when Atlassian plans to deprecate anything, they communicate it clearly (to some degree) and provide a defined transition period (typically around six months or more). That was not the subject of my article.

The article specifically discusses the two development frameworks, one of which, Atlassian is promoting for building apps within their infrastructure. It does not reference, imply, or suggest any deprecation of the REST API. I hope this clarifies what this article is about.