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.