Multi-App Compatibility Eligibility: Hybrid Forge + Connect App — Which Connect Modules Block Us and What Are Their Forge Equivalents?

Forge Adopting Forge from Connect
1

Hi Community,

We’re trying to determine our eligibility for Multi-App Compatibility and need clarity on which parts of our current setup are blocking us, and what the migration path looks like for each.

OUR CURRENT SETUP:

We are in a hybrid Forge + Connect state:

  • All UI modules are on Forge Custom UI

  • Forge resolver handles frontend requests, but proxies calls to a Connect remote backend

  • We still have the following connectModules actively declared in our manifest:

    • jira:lifecycle — installed / uninstalled / enabled hooks
    • jira:webItems — 5 dialog-based web items (Give Feedback, Edit Feedback, Respond Feedback, Request Feedback, Delete)
    • jira:webSections — 1 admin menu section
    • jira:webhooks — 8 webhooks (user_deleted, user_updated, issue_created, issue_updated, issue_deleted, worklog_created, worklog_updated, worklog_deleted)
    • jira:jiraIssueContexts — 1 issue glance panel
    • jira:jiraEntityProperties — 1 entity property indexing configuration
    • jira:translations — i18n files (de-DE, fr-FR, ru-RU, es-ES)
    • jira:cloudAppMigration — migration webhook

WHAT WE UNDERSTAND:

The docs at https://developer.atlassian.com/platform/forge/migrating-a-forge-app-to-support-multiple-atlassian-apps/ clearly state:

“The app must be a Forge app. Connect apps, including apps with a Forge manifest that still use Connect modules, are not eligible.”

So we know we are NOT eligible yet due to the remaining connectModules and our Connect remote backend.

OUR QUESTIONS:

  1. Is there a supported Forge equivalent for each of these Connect module types? Especially:

    • jira:lifecycle → Forge lifecycle events?
    • jira:webhooks → Forge triggers (avi:jira:* events)?
    • jira:webItems (dialog-based) → Any Forge equivalent?
    • jira:jiraIssueContexts (issue glance) → jira:issueContext?
    • jira:jiraEntityProperties → Forge entity properties support?
    • jira:translations → Forge i18n?
    • jira:cloudAppMigration → Forge equivalent?

  2. If all connectModules are removed and we still use Connect remote, do we become eligible with this combination? or it is also not allowed.

  3. Once all connectModules are removed and Connect remote is replaced with Forge Functions or Forge Remote, do we automatically become eligible? Or is there an additional review/approval step?

  4. Has anyone successfully completed this kind of full Connect → Forge migration for a complex app with webhooks, lifecycle hooks, and entity properties? Would love to hear about the approach.

Thanks!

2

Yes — Forge has supported equivalents for most of the Connect capabilities you listed, but some are not exact 1:1 replacements.

  • jira:lifecycle → Forge app events such as avi:forge:installed:app and avi:forge:upgraded:app

  • jira:webhooks → Forge trigger with Jira product events like avi:jira:*

  • jira:webItems used for dialogs → usually a location-specific Forge module plus a Forge Modal (UI Kit or Custom UI), not a single universal replacement

  • jira:jiraIssueContexts → jira:issueContext

  • jira:jiraEntityProperties → jira:entityProperty

  • jira:translations → Forge internationalisation

  • jira:cloudAppMigration → Forge App Migration Platform, though there are still some architecture-specific details to follow in the migration docs

The biggest caveats are:

  • some webhook events still do not have Forge equivalents

  • dialog/web item migration is location-dependent

  • app migration and remote-backend migration need to be planned explicitly

On eligibility: removing all connectModules is a major milestone, but it is not the only factor. If you still use a remote backend, that can still be a valid Forge Remote architecture, but it would not make the app Runs on Atlassian. Once you replace Connect modules and move execution to Forge Functions or Forge Remote, you are on the supported target architecture, but rollout may still involve Marketplace versioning and admin approval depending on scope/permission changes.

For a complex app, the recommended approach is staged migration rather than a big-bang rewrite: first adopt Forge, then replace webhooks and UI modules incrementally, then move or formalize the backend using Forge Functions or Forge Remote.

Is there any part of that you want to dig into deeper.

(P.S. many partners have done this already but you would have to look around for public blog posts on the moves and their learnings)

3

Hi @rmassaioli, thanks for the detailed response! I have a few follow-up questions based on your reply:

1. Is “Runs on Atlassian” mandatory for Multi-App Compatibility eligibility? You mentioned that using Forge Remote is a valid target architecture but would not make the app “Runs on Atlassian”. However, the Multi-App Compatibility docs only state that the app must be a pure Forge app with no Connect modules. Can you confirm — is “Runs on Atlassian” certification a hard requirement for enabling Multi-App Compatibility, or are these two completely independent programs?

2. Forge Remote as a valid target architecture If Forge Remote (external backend, no Connect dependency) is a supported target architecture for Multi-App Compatibility, does that mean once we:

  • Remove all connectModules from our manifest

…we would be eligible to enable Multi-App Compatibility, even if our backend is still externally hosted?

3. Staged Migration — recommended order for our specific case Based on our current setup (Forge Custom UI + Forge resolver proxying to remote backend + remaining connectModules), you recommended a staged migration approach. Could you help us prioritize the order? Specifically:

  • Should we first remove connectModules and replace with Forge equivalents, then formalize the backend as Forge Remote?

  • Or should we first formalize the backend as Forge Remote (remove associateConnect = true), then tackle connectModules?

  • Which sequence unblocks Multi-App Compatibility the fastest?