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 - ELFAPP]

@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 - ELFAPP

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 - ELFAPP]

@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.

[James Rickards _SN_]

Thanks for clarifying @Prince Nyeche - ELFAPP . Makes sense to me now.

The text that caused me to believe you were talking about the REST API is as follows: "It allows developers to host their apps externally and connect to Atlassian via APIs."

[Yatish Madhav]

Thanks for this article @Prince Nyeche - ELFAPP 

We have a private connect app, hosted on our custom internal system, intranet if you will, that we built in 2020, we primarily used it for +- 30/40 custom single/multi select fields and then populate them from via REST API (that also hosts the atlassian_connect JSON file) and no other modules.

How do you advise we move it over to Forge?

I think the biggest struggle I have is understanding a few things:

- having to learn and understand what needs to change from PHP to Node JS (and learning it)

- if Forge app is initially deved on my laptop and deployed/installed, how to other devs contribute to it?

- can we have a Forge app that is private like our connect app (we used it only ever on a single instance and another for testing)?

Thank you

Yatish

[Prince Nyeche - ELFAPP]

Hey @Yatish Madhav 

Thanks for sharing.

At its core, programming concepts remain the same across languages. PHP, as you know, is largely functional in style, and many of those principles translate well to Forge, which runs on Node.js (JavaScript). That said, it is a different language, so there’s naturally a learning curve.

I come from a heavily Python-based background almost all of my apps (custom and otherwise) were written primarily in Python, with some Java and Groovy, but mostly Python. I’d always known JavaScript, but I didn’t really use it for backend development until about two years ago when I started building apps and scripts more seriously. For example, I built a sentiment analysis app for Jira completely from scratch with zero external dependencies.

My point is: you already have solid experience in PHP. The key is to adapt or convert that knowledge into Node.js. The core programming concepts are the same. JavaScript has its own rules and quirks, but so does PHP. The gap isn’t as big as it might seem.

A practical approach would be to give yourself a project and build it entirely in JavaScript. See it through from start to finish. By the end of it, you’ll likely feel just as comfortable in JavaScript as you do in PHP. And then I think you will be ready to move your current app to Forge.

Regarding your other questions: you’ll need to host your code in a repository like Bitbucket or GitHub if you want others to collaborate. From there, you deploy it to Forge. It’s no different from standard software development if collaboration is the goal, you use a platform that supports version control and teamwork.

Also, Forge apps can be private if that fits your use case. One major advantage of Forge is that you don’t have to handle authentication and authorization yourself. That removes an entire layer of complexity from development, which is a big win.