Key takeaways: what we learned migrating our app portfolio from Connect to Forge
Over the past several months, our engineering team at Ricksoft migrated our full portfolio of Jira and Confluence apps from Connect to Forge. Sharing the honest takeaways for other Marketplace Partners still working through this.
1. Sequence by risk, not by size.
We migrated one of our smaller, lower-traffic apps first rather than our largest. It gave us a safer environment to validate our whole approach before applying it to bigger apps with more customers on the line. Every constraint we hit early got solved once, then reused across the rest of the portfolio.
2. Not every Connect module has a 1:1 Forge equivalent: budget time for UX redesign.
A few of our apps used editor toolbar buttons, footer panels, and full-screen editors with no direct Forge counterpart. We ended up redesigning some of these into different UI patterns (a content-actions menu, a modal view) rather than a straight port. If your app leans on similar modules, loop in design early as these gaps can add real time to your estimate.
3. Plan around Forge's runtime limits, not against them.
Forge functions and triggers have real execution ceilings (seconds, not minutes, for most invocation types) plus per-user and per-install rate limits. One of our apps has a long-running background job that simply doesn't fit inside those limits, so instead of forcing it, we kept the heavy processing on infrastructure we manage, with Forge handling auth and events. Forge Remote made that hybrid approach possible without giving up the migration.
4. You can't fully remove your Connect code until every customer has migrated.
This one surprised us: several "cleanup" tickets to strip legacy Connect code had to be deferred, because doing it too early would break the app for any customer still running the old version. Plan for an extended dual-runtime period, and build a proper abstraction layer that routes based on runtime detection rather than assuming everyone's moved over.
5. Watch your versioning strategy on the first Marketplace submission.
We hit a version-numbering issue on one app's first Forge release that could have confused customers with a large, unexplained version jump. Worth sorting out your versioning approach before you submit, not after.
6. Auth migration is more than swapping JWT for OAuth.
It touches your token handling (Forge doesn't carry refresh tokens the way you might expect), any Connect-specific migration APIs you relied on, and often your tenant identifier itself. Map every authentication call site early. It's infrastructure work, not just a header change.
7. QA is not an afterthought.
Regression testing on a Forge migration surfaces more than you'd expect, even on a mature, well-tested app. Budget real time for it, including permissions and security testing, not just functional regression.
8. Customer communication is part of the migration, not an add-on.
We built a structured playbook for pre-, during-, and post-migration communication. One nuance worth knowing: eligible Connect-to-Forge updates can now roll out without admin approval, but some installations or changes may still require customer action. Don't assume it's uniform. Be explicit about what customers need to do, rather than assuming the migration automatically reaches everyone in the same way.
Where we landed.
Our full portfolio is now on Forge, ahead of Atlassian's Connect end-of-support deadline. If you're earlier in your own migration and want to compare notes, happy to talk, drop a comment below.
PS: Ricksoft team will also be at Team '26 Europe in Amsterdam 🇳🇱! If you're going and want to swap notes on Forge migration in person, let's meet up!
Was this helpful?
Thanks!
Raziman Dom - Ricksoft
1 comment